If you're still on Dynamics CRM 2016 or any on-premise build of Dynamics 365, the clock is ticking. Mainstream support is gone, security patches are expensive, and your customizations are slowly drifting from the cloud's capabilities. This playbook walks through how we move clients to the cloud cleanly.
Why now (and not "next year")
The longer you wait, the harder it gets:
- Customization debt grows — every JS web resource, plug-in and unsupported feature you add ties you tighter to the legacy platform.
- The cloud product evolves twice a year. Your gap widens.
- Talent for on-prem CRM is scarce and expensive.
- Microsoft licensing increasingly favors cloud SKUs.
The right answer for almost everyone is: migrate this year.
Phase 0 — Solution audit (1–2 weeks)
Before any migration, you need a complete inventory:
- Customizations: entities, fields, forms, views, business rules, processes.
- JavaScript web resources, plug-ins and custom workflow assemblies.
- Reports (SSRS) and dashboards.
- Integrations and the systems on the other end.
- Data volume per entity and total Dataverse footprint estimate.
- Active users, security roles and team structure.
The output is a single inventory document with a "Lift / Refactor / Retire" decision for each item. Many on-prem customizations are no longer needed because the cloud does it natively (kanban views, business process flows, modern advanced find).
Phase 1 — Target architecture (2 weeks)
Don't lift-and-shift to the cloud. Use the migration as the moment to re-architect:
- Environment strategy — Dev / Test / UAT / Prod, plus a "sandbox" for citizen experiments.
- Solution layering — managed solutions only in upper environments. ALM with Power Platform Pipelines or Azure DevOps.
- Security model — review business units, security roles and team-based access. The cloud has stronger column-level security; use it.
- Identity — Entra ID / Azure AD with Conditional Access. SSO from day one.
- Integrations — replace SOAP/SDK calls with Dataverse Web API, Power Automate or Logic Apps.
Phase 2 — Data migration design (3–4 weeks parallel)
Three patterns we use:
| Pattern | When | Tool |
|---|---|---|
| Configuration Migration | Reference data, security, options | Microsoft CMT |
| Bulk historical | Accounts, contacts, opportunities, cases | Azure Data Factory + Dataverse connector |
| Cutover delta | Final-day movements | KingswaySoft or custom Power Automate |
Plan for two full mock cutovers before go-live. The first finds the hard problems. The second proves you've fixed them.
Phase 3 — Customization rebuild (4–8 weeks)
This is where teams underestimate effort. For each "Refactor" item from Phase 0:
- Replace plug-ins with Power Automate flows, Dataverse low-code plug-ins, or Azure Functions.
- Re-write JavaScript using modern Dataverse Client API (legacy 2011 endpoints are gone).
- Convert SSRS reports to Power BI paginated where possible.
- Rebuild workflows as cloud flows.
Aim to delete 30–50% of legacy customizations during this phase. They were workarounds for capabilities the cloud now ships natively.
Phase 4 — Integration migration (parallel, 4–8 weeks)
Most painful step in any cloud move. The pattern:
- For each integration, decide: rebuild on Power Automate, rebuild on Logic Apps / Functions, or keep the existing system and switch endpoints.
- Use Dataverse plug-in registration tool for service endpoints.
- For high-volume systems (>100K transactions/day), Logic Apps with Service Bus is the right pattern, not Power Automate.
Phase 5 — UAT and adoption (3–4 weeks)
- Two rounds of UAT minimum. First catches bugs. Second validates business processes end-to-end.
- Train Champions before training general users.
- Update SOPs, knowledge articles and ticket templates with the new screens.
Phase 6 — Cutover (1 weekend)
- Freeze on-prem on Friday evening.
- Run delta data migration overnight.
- Smoke test Saturday morning with a small power-user group.
- Open to all users Monday morning with hyper-care support.
Keep on-prem read-only for 90 days as your fallback reference. Do not delete it for 12 months.
Realistic timelines
- Small (<50 users, simple): 4–6 months
- Mid (50–500 users, moderate customization): 6–10 months
- Large (>500 users, heavy customization, multiple integrations): 10–18 months
Half of that timeline is integration work. Plan accordingly.
Common pitfalls
- Skipping the solution audit. You'll find the problems mid-migration when they're 5x more expensive.
- Treating it as IT's project. Business owners must own UAT and adoption.
- Carrying forward all historical data "just in case." Decide retention rules. Most clients keep 3–5 years live, archive older to Azure Blob.
- Re-creating the on-prem UX in the cloud. Embrace the new modern app experience.
FAQs
Will our existing customizations work in the cloud? Some yes, many no. Anything using deprecated APIs (2011 SOAP endpoint, on-prem-only plug-in registrations, custom STS) won't work. Plan to refactor.
What about our SSRS reports? Cloud Dynamics 365 supports paginated reports via Power BI Premium / Fabric. SSRS-style RDLs convert with some rework.
Can we keep the same URL? You'll get a new tenant URL. Use a custom DNS CNAME and redirect old URLs server-side. Update bookmarks during training.
How risky is the data migration? Low if you do two mock cutovers. High if you skip them. The risk is almost entirely process, not technology.
We've migrated 60+ on-prem CRM tenants to the cloud. If you want a no-pressure review of your migration plan, book a session with one of our Microsoft MVP consultants.