This topic came up no long ago in a customer, the upgrade to 2013 automatically merges the tables, which would be fine if it did not take so long.
You might not notice the issue when upgrading DEV or UAT environments, but it’s when you try the PRD database where the fun really starts.
In our case it was taking +24h for the upgrade alone. And some times one cannot afford to wait that long.
Consider that on top of those +24h you have to do configuration changes in CRM (specially if it’s a side-by-side upgrade), and smoke test core functionalities (e.g.: integration points) before considering the deployment complete and “we’re live” can be announced.
If its an in-place upgrade, CRM wont be operational or running very slow, and lets face it, users should not use a system during a deployment.
If its a side-by-side upgrade, usage of the old system while you upgrade will for sure be requested, and that means to migrate deltas after go live, and migrating deltas has to be carefully planned, topics such as the following should be considered:
- How can you identify the deltas? Is createdon and modifiedon enough?
- What will users do while the deltas are not migrated? (they probably will manually re-create some data, and we can see where this is headed…)
- How will you migrate the data? Will the lovely MSCRM Toolkit do the job?
The above are not really good options, but there is a third one.
Can I leave merging for later?
You sure can. This registry change does the trick, but it has to be done before running the migration in CRM Deployment Manager:
- Location: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSCRM\ MergeBaseAndExtensionTables
- Type: DWORD (32-bit)
- Value: 0
as per Microsoft’s article Run the base and extension table merge as a separate operation
This can allow a go-live during a weekend, and leave the merger for another time.
Why run it at all?
The reason for Microsoft to merge the tables is to “reduce SQL deadlocks and performance related issues”.
So…it will run better, but will it run worse than the previous versions if not merged? So far there have been no indications that it does, and so far new Update Rollups can be deployed without having the tables merged as a requirement.
Despite the above, merging is the default action, and the recommended one. Not doing it will only postpone the issue.
Consider, time and budget availability, if it is not considered as critical as other initiatives, you could pull it off for a while…
How long can I get away with it?
Andy Zhang has a good post that helps address this topic, in short you cannot disable merging for a 2015 upgrade, so that’s how far you can go, or until Microsoft releases a UR with merging as a requirement, ;).
Check out Andy Zhang’s post CRM 2015 Upgrade: A Few Things You Can Prepare Ahead of Time, very useful.
Daily Dynamics 