Problem upgrading organization from 8.1 to 9.1 on OnPremise Dynamics CRM

Hello,

We have a technical problem to upgrade our onPremise Dynamics CRM

We have an organization on Dynamics CRM 2016 (version 8.1.1.1005) that we want to migrate to a Dynamics CRM 365 (version 9.1.13.12).

• This organization runs on 3 environments (Dev / Preprod / Prod) and has exactly the same structure (same solutions / customizations / etc.) on all environments.
  The only 2 differences between these environments are:
• Dev and Preprod versions have very little data compared to the prod which is very large (almost 500 million audit lines / 32 million activities / ...)
  Prod version runs on an “Enterprise” version of SQL Server

To import the organizations, we make a backup of the database of the organization to be migrated and we restore it on a new SQL server.
Then we import it into Dynamics CRM 365 which we have just installed on a new server
The import of the organization on Dynamics 365 went very well on the Dev and the Preprod and they are now functional.

On the other hand, we have an error with each attempt to import the production organization and it is impossible for us to import it so far.
The error is the same on each attempt. About 30 minutes after starting the import, we arrive at the "PackageDeployer: Starting SolutionHistoryAPIs install." step, and at this point, the import remains blocked for 1 hour precisely and then displays a timeout before failing:

2023-01-09 10:34:20.296| Info| PackageDeployer: Starting SolutionHistoryAPIs install.
2023-01-09 10:34:20.296| Info| PackageDeployer: Starting SolutionHistoryAPIs install with RuntimeSettings: GeoName=ONP|OperationType=Upgrade|OrgSchemaType=CRM|OriginalDBVersion=8.1.1.1005|CurrentDBVersion=9.1.13.12|IsUpgrade=True|ExternalStorageFcb=False|FileTypeFcb=True
2023-01-09 11:34:23.214| Info| Failed to install package SolutionHistoryAPIs on attempt 1.
2023-01-09 11:34:23.214| Info| Failed to install SolutionHistoryAPIsException: Microsoft.Crm.PackageDeployment.PackageDeployerException: Package SolutionHistoryAPIs failed to install on attempt 0.
System.AggregateException: One or more errors occurred. ---> Microsoft.Crm.MultiTenantPackageDeployment.PackageDeployerException: MTPD: Import operation timed out.
at Microsoft.Crm.MultiTenantPackageDeployment.PdExecutor.Process(PackageDeploymentInputArgs input, JobOutput`1 output, CancellationToken ct)
at System.Threading.Tasks.Task.Execute()
--- End of inner exception stack trace ---
---> (Inner Exception #0) Microsoft.Crm.MultiTenantPackageDeployment.PackageDeployerException: MTPD: Import operation timed out.
at Microsoft.Crm.MultiTenantPackageDeployment.PdExecutor.Process(PackageDeploymentInputArgs input, JobOutput`1 output, CancellationToken ct)
at System.Threading.Tasks.Task.Execute()<---

During this hour when the import remains blocked, I took the opportunity to look at what was happening on the database.
A query (executed by the MSCRMMicrosoft.Crm.MultiTenantPackageDeploymentExecutor application) remains locked (LCK_M_SCH_S):

IF EXISTS (SELECT * FROM sys.tables WHERE NAME = N'MetadataTimestamp' and type = N'U')
BEGIN
SELECT 1 as DoesExist
END
ELSE
BEGIN
SELECT 0 as DoesExist
END

With a "Wait Resource" that has this value:

metadatalock subresource=ALL_AUDIT_SPECIFICATIONS_AND_ACTIONS classid=database_id = 15 dbid= 15 lock Partition=0 id=lock 1e776796c00 mode=Sch-M

If I kill the locked query, it always returns directly to lock.
In normal times (Not during an import), I tried to execute this query "by hand" and it executes without problem instantly.

I tried various things before retrying the import:

• Added RAM on the SQL Server (There is now 128GB)
• Downgrade the CRM version from 9.1.14 to 9.1.13 (Because it is on this version 9.1.13 that the preprod and dev organizations had been successfully imported)
• Creation of registry keys at CRM level (OLEDBTimeout and ExtendedTimeout) to increase SQL timeouts (learn.microsoft.com/.../a-time-out-occurs-when-importing-large-customization-files)
• Optimization of the database before the backup/restore with a rebuild of all the indexes of the large tables.

Despite all this, we still have this same error when importing the organization.

Do you have any ideas to solve this problem?

Thanks for your help.