IdentityServer4: what is breaking changes from version 2 and/or 3 to version 4?

I made a migration from 2.2 to 4.1.2 version two years ago and I remember I found some breaking changes. Others were imposed by the upgrade of framework I made (net core 2.1 to 3.1). These are some of the changes related only to IdentityServer4:

1. Database scheme. If you have data in production you'll need to maintain this data in the migration. Automatic migrations will delete and recreate tables mercilessly. There are table and column renames, new columns, deleted columns, changes in the indexes...
2. Client Cors Origins validation. There is a new validation to force all Url configured in ClientCorsOrigins to complain with an Origin format. If only one of them does not comply with the format, an exception is thrown. You should review your production values to avoid fails.

    // format:
    ://:

    // good examples:
    http://localhost:5000
    http://example.com
    https://anotherdomain.com
    http://example.com:1234

    // bad examples
    http://example.com/
    https://example.com/mypath
    example.com:1234

3. Some code changes:

• AuthorizationRequest.ClientId -> AuthorizationRequest.Client.ClientId.
• ResourceValidationResult groups ApiResources and IdentityResources properties in a common property called Resources.
• ValidatedTokenRequest changes his property Scopes to RequestedScopes.
• GetAllUserConsentsAsync -> GetAllUserGrantsAsync.
• In your UI some ModelViews will need to be updated to the new scheme. If you stared with the QuickStart.UI you can compare with the new version to add the new features.
• If you have an admin you'll have to adapt it to the new scheme.

I created the migrations automatically and then I edited the migration to reorder and to add manual scripts to save the data (For example, create a table before deleting the old one and move the data).

These are the scripts I had to insert manually for the Up migration.

• Reorder the code to create ApiResourceScopes table before deleting column ApiResourceId from ApiScopes table.

  Insert Into [ApiResourceScopes] ([ApiResourceId], [Scope]) Select [ApiResourceId], [Name] From [ApiScopes]
  

• As ApiScopes has a new field called Enabled and by default takes 0, you'll want to enable for all of them. Run this script just before create the Enabled column:

  Update [ApiScopes] set [Enabled] = 1
  

• ApiSecrets must be moved to the new table ApiResourceSecrets. So you should run this script before delete ApiSecrets:

  Insert Into [ApiResourceSecrets] ([Description], [Value], [Expiration], [Type], [ApiResourceId], [Created]) Select [Description], [Value], [Expiration], [Type], [ApiResourceId], GetDate() From [ApiSecrets]
  

• The table IdentityClaims is renamed to IdentityResourceClaims. So you'll need to run this script after crate IdentityResourceClaims and before delete IdentityClaims.

  Insert Into [IdentityResourceClaims] ([Type], [IdentityResourceId]) Select [Type], [IdentityResourceId] From [IdentityClaims]
  

For the Down migration you need to do exactly the reverse:

• Restore ApiScopes. Move the data from ApiResourceScopes.ApiResourceId by using in the join the Scope and the Name fields respectively.

  Update [ApiScopes] Set [ApiScopes].[ApiResourceId] = apir.[ApiResourceId] from [ApiScopes] apis Inner Join [ApiResourceScopes] apir On apis.[Name] = apir.[Scope]
  

• Restore ApiSecrets. Move the data after create ApiSecrets table and before delete ApiResourceSecrets:

  Insert Into [ApiSecrets] ([Description], [Value], [Expiration], [Type], [ApiResourceId]) Select [Description], [Value], [Expiration], [Type], [ApiResourceId] From [ApiResourceSecrets]
  

• Restore IdentityClaims. Move the data after create IdentityClaims and before delete IdentityResourceClaims:

  Insert Into [IdentityClaims] ([Type], [IdentityResourceId]) Select [Type], [IdentityResourceId] From [IdentityResourceClaims]