Phased Migration from Dynamics CRM 2016 to Dynamics 365 Online for an Industrial Equipment Distributor

The first challenge was that the client was still on Dynamics CRM 2016 version 8.2, while Microsoft’s supported on-premises-to-online migration path starts from version 9.0 or later. At the same time, the team needed a clear view of everything in the CRM before deciding what could move.

So we started with a full migration-readiness assessment.

We started with the workflows the business depended on every day
On the sales side, that meant accounts, contacts, products, price lists, quotes, opportunities and follow-ups. On the service side, it meant cases, queues, returns and order-status inquiries. We then mapped the customizations, plug-ins, workflows, scripts and web resources behind them. In total, we reviewed 38 customizations, 12 plug-ins and custom workflow activities, and 21 web resources.

Next, we looked at what connected the CRM to the rest of the business
That included the quote-to-order hand-off, email flows, management reports, customer history and the user accounts that sales and service teams relied on.

We then checked what could block the cloud move
Direct database changes, undocumented APIs, unsupported scripts, website-directory files and plug-ins that would not run in sandbox isolation were all flagged for remediation. We also planned for the version gap from CRM 8.2 to the supported 9.0+ migration path before the first rehearsal.

Outcome: Finally, everything was grouped into three buckets: ready to move, needs rework, or needs to be retired. Of the 71 items, 46 were ready to move, 19 needed rework and 6 needed to be retired. From that, we created a prioritized remediation backlog based on what could delay the migration or interrupt quoting and case handling.

Once the environment was mapped, two things stood in the way of the cloud move. The environment had to be brought up to a supported version, and the components tied to the old on-premises setup had to be dealt with.

The Email Router, Reporting Extensions, older scripts and integrations could not simply be carried into Dynamics 365 online as they were. Sales and service teams used them every day, so each one had to be reworked before the migration.

• Upgraded the environment from version 8.2 to the supported 9.x baseline, the minimum for Microsoft’s on-premises-to-online migration path, and confirmed quoting, case handling and customer history worked as before.
• Retired the Email Router and moved email to server-side synchronization so customer emails could continue reaching the right sales and service records.
• Removed Reporting Extensions and reworked the open-quote, pipeline and case-backlog reports for Dynamics 365 online.
• Updated deprecated scripts, including those used on quote and case forms, to use the supported Client API.
• Updated plug-ins and custom workflow activities used for quote pricing, discount rules and case routing so they met sandbox isolation requirements.
• Reworked the quote-to-order integration so accepted quotes could continue flowing into the order-management system after the move.
• Reworked order-status integrations used by service agents so they could connect through supported web services instead of the on-premises servers.
• Packaged the remediated customizations as solutions so they could be redeployed into the online environment after the data moved.

Outcome: By the end of this phase, the environment was on the supported 9.x version and none of the legacy components identified in the assessment remained in the migration path. Email, reports, scripts, plug-ins and integrations had been reworked around supported Dynamics 365 online patterns, so the quote-to-order and case-handling workflows were ready to move without carrying unsupported components along.

Once the CRM was ready to move, the next risk was the migration itself. So instead of estimating how the final cutover might behave, we rehearsed it first.

• Confirmed the required Dynamics 365 online licenses and Copilot licenses were in place before migration began.
• Mapped every on-premises user to the correct Microsoft Entra ID, including sales reps, service agents, managers and administrators.
• Checked for duplicate or missing user mappings so people would arrive in the new environment with the right access.
• Ran 3 migration dry runs through Microsoft’s tooling, each including database backup upload to Azure storage, staging validation, version handling where required and migration into the online environment.
• Validated the results after each rehearsal against records the teams depended on, including open quotes and open cases.
• Timed and documented every rehearsal in a migration run-book. The first run took about 11 hours 30 minutes, the second about 9 hours 15 minutes and the third about 7 hours 20 minutes.
• Used staging validation to identify blockers early, before the production environment was affected.
• Used the recorded timings to set the final cutover window at 8 hours, the third run’s duration plus a buffer, instead of relying on an estimate.

Outcome: Three dry runs were completed. The first took about 11 hours 30 minutes and surfaced the blockers that staging validation exists to catch. Once those were fixed, the second took about 9 hours 15 minutes and the third about 7 hours 20 minutes, each checked against open quotes and open cases in the source. Every user was mapped to the right account with no duplicate or missing mappings, the required licenses were in place, and the cutover window was set at 8 hours from the recorded timings.

Moving everyone at once would have meant testing the new environment for the first time at the same moment the whole business started depending on it. So we began with a smaller group from both sales and service.

• Moved a pilot group of sales reps and service agents first onto a migrated copy of the CRM, so they could work with real data and reports before anything went live. They kept doing their live work in the existing CRM, so anything they created or changed in the copy was test activity only.
• Logged every issue found during the pilot and resolved it before the final cutover.
• Discarded the pilot copy once testing was done, so none of the test activity could reach the live system.
• Redeployed the remediated customizations into the migrated environment.
• Ran the final cutover once, in the window the rehearsals had set, outside business hours so quoting and case handling were not interrupted. It migrated a fresh copy of production data, so the teams’ live records came across exactly as they stood.
• Brought the remaining users onto Dynamics 365 online team by team after cutover, instead of asking everyone to change at once.
• Enabled Copilot for Sales and Customer Service for the first teams to move onto Dynamics 365 online, so sellers could prepare from summarized customer and opportunity history and agents could work cases with more context.
• Prepared training and guidance for each group, based on the workflows they actually used.

Outcome: Pilot issues were logged and closed before the final cutover. The pilot copy was discarded and a fresh copy of production data was migrated at cutover, so no test activity reached the live system. The pilot group had 15 users, about 10% of the user base. The cutover ran once, in an 8-hour window with about 4 hours of downtime, and the remaining teams moved over in stages. The full migration, from assessment to final cutover, took about 14 weeks.