Migrating On-Premises Dynamics CRM to the Cloud: A Checklist

Still running Dynamics CRM on your own servers? You are far from alone — but the case for staying gets weaker every year. On-premises deployments mean hardware costs, patching, security exposure, and a growing gap between what your team uses and what Microsoft ships in the cloud.

Migrating to Dynamics 365 online fixes all of that — but only when the migration is planned properly. A rushed lift-and-shift simply carries old problems into the new platform. This checklist walks through what a smooth on-premises to cloud migration actually looks like, phase by phase, so you land in the cloud clean, modern, and ready to grow.

Why move off on-premises CRM

The costs of staying on-premises go beyond the visible ones. Yes, you pay for server hardware, maintenance, and eventually painful version upgrades. But you also pay in missed capability: every new feature Microsoft ships — AI-driven insights, modern integrations, mobile experiences — lands in the cloud first, and often only in the cloud.

• No more server hardware, patching, and maintenance overhead
• Automatic updates with the latest features, without upgrade projects
• Stronger security and compliance than most businesses can maintain themselves
• Access anywhere, on any device, for hybrid and field teams
• Native integration with Microsoft 365, Teams, and the Power Platform

Phase 1: Audit what you have

A successful migration starts with an honest inventory of your current system: every customisation, integration, workflow, report, and third-party add-on. For each, ask a simple question — does this still earn its place?

Years of on-premises operation accumulate customisations built for problems that no longer exist, workarounds for limitations the cloud has since solved, and integrations to systems you have already replaced. The audit tells you what to carry forward, what to rebuild better, and what to leave behind. Skipping it means paying to migrate junk.

Phase 2: Clean your data on the way

Migration is the single best data-cleaning opportunity you will ever get. Before anything moves, deduplicate accounts and contacts, fix formatting inconsistencies, standardise picklists, and archive records with no operational or legal value.

There is a practical payoff beyond hygiene: cloud storage is metered, so migrating years of dead records costs real money every month. More importantly, a clean system earns user trust from day one — and trust drives the adoption that makes the whole project worthwhile.

Phase 3: Rebuild customisations the modern way

Old on-premises customisations — heavy JavaScript, unsupported database tweaks, legacy plugins — often cannot move as-is, and mostly should not. The cloud platform offers better tools for the same jobs.

The modern approach rebuilds what the audit kept using upgrade-safe methods: Power Automate for workflows, Power Apps for custom interfaces, supported plugin patterns for server logic. It is more work than a lift-and-shift — and it is the difference between a system that survives every future update and one that breaks twice a year.

Phase 4: Plan the integrations

Every system connected to your on-premises CRM — ERP, email, telephony, websites, data warehouses — needs a plan for the cloud world. Some integrations get dramatically easier (Microsoft 365 and Teams become native), some need rebuilding on modern APIs, and some third-party tools may need upgrades or replacement.

Map every integration during the audit, decide its future early, and test each one thoroughly before cutover. Broken integrations are the most common source of post-migration pain — and the most preventable.

Phase 5: Test, train, and go live

The final phase decides how the migration feels to your business. Validate the migrated data against the source. Test every workflow, report, and integration in a sandbox with real users and real scenarios — not just the IT team clicking around.

Train users on what changed, and be honest that some things will look different. Then cut over in a controlled window with a rollback plan you will probably never need. A phased go-live — core teams first, wider rollout after stabilisation — keeps risk contained and support manageable.

How long does it take?

A focused migration typically runs from a few weeks for a lightly-customised system with clean data, to several months for heavily-customised environments with complex integrations. The biggest variables are customisation depth, data volume and quality, and integration count.

Beware of anyone quoting a timeline before auditing your system — they are guessing. The audit phase itself usually takes days, and it converts the rest of the plan from estimates into commitments.

Lift-and-shift vs transform: choosing your approach

Two migration philosophies compete for your budget. Lift-and-shift moves everything as-is: faster and cheaper up front, but it imports your technical debt and often collides with cloud platform differences anyway. Transform — the audit-clean-rebuild approach in this checklist — costs more initially but delivers a system that is faster, cleaner, and cheaper to run for years.

For lightly-customised systems the two approaches converge and lift-and-shift is fine. The more customised and cluttered your on-premises environment, the stronger the case for transforming on the way — because the cloud rewards clean, supported patterns and quietly punishes legacy shortcuts at every update.

Why move from on-premise Dynamics CRM to the cloud

On-premise Dynamics CRM served many organisations well for years, but the case for moving to the cloud has become hard to ignore. On-premise means you carry the full weight of servers, upgrades, backups, security patching and disaster recovery yourself — work that grows more expensive and more risky as the hardware ages and the version falls further behind. Dynamics 365 in the cloud shifts that burden to Microsoft: continuous updates, enterprise-grade security, elastic scale and predictable subscription costs replace ageing infrastructure and painful, all-or-nothing upgrade projects. Just as importantly, the cloud unlocks the modern capabilities — Copilot AI, the Power Platform, native Teams and Outlook integration, and a steady stream of new features — that on-premise simply cannot receive.

What the migration actually involves

A move from on-premise to Dynamics 365 online is a structured project, not a switch you flip. The main workstreams are:

• Assessment — catalogue your current entities, customisations, plug-ins, integrations and reports, and decide what to keep, rebuild or retire. Years of on-premise tailoring almost always include things no one uses any more.
• Solution and customisation review — some legacy customisations map cleanly to the cloud; others (particularly unsupported code or direct database work) must be re-implemented the supported way using the Power Platform.
• Data migration — clean, de-duplicate and map your data, then move master records and the history you genuinely need, archiving the rest.
• Integration rebuild — reconnect the systems your CRM talks to using modern APIs and connectors.
• Testing and cutover — validate against real scenarios, run a parallel period where practical, then cut over with a clear rollback plan.

Common challenges and how to handle them

The biggest risks are rarely the data itself — they are the customisations. On-premise systems often rely on unsupported code or direct SQL access that has no equivalent in the cloud, so those areas need re-design rather than lift-and-shift. Version gaps are the second challenge: migrating from a very old on-premise version may need an intermediate step. And integrations that assumed a server on your own network must be re-thought for a cloud endpoint. None of these are blockers, but they are exactly why an assessment phase pays for itself — it surfaces the surprises while they are still cheap to solve.

Getting the timing and approach right

Where possible, treat the migration as an opportunity to simplify rather than a straight copy. Retiring unused customisations, cleaning data and adopting standard functionality where you had drifted into bespoke logic all make the new system faster, cheaper and easier to maintain. Phasing helps too: move a core group first, prove the cloud works for them, then bring the rest across. That approach spreads risk and lets your team adapt gradually instead of facing a single dramatic switch-over.

Turning a migration into an upgrade

The smartest teams treat a move from on-premise to the cloud as a chance to improve, not merely to relocate. Instead of copying every legacy customisation, they retire the ones no one uses, replace unsupported code with clean Power Platform solutions, and adopt standard functionality wherever they had drifted into bespoke logic. The result is a system that is not just newer but genuinely better — faster, cheaper to run, easier to maintain and ready to receive every future Microsoft update automatically. Combined with a phased rollout that moves a core group first and proves the cloud before scaling, this approach removes most of the risk from what can otherwise feel like a daunting project. Handled well, the migration pays for itself not only in reduced infrastructure cost but in the modern capabilities — AI, automation and analytics — that on-premise could never deliver.

It is worth remembering that a cloud migration is as much an organisational change as a technical one. People who have used the same on-premise system for years will have habits, shortcuts and expectations built around it, so clear communication and focused training matter just as much as the data move itself. Explain what is changing and why, involve key users early, and give them time to adjust. When the team understands that the new system removes upgrade pain and unlocks modern tools rather than simply moving their work around, resistance turns into enthusiasm.

Finally, plan for the period immediately after cutover. Keep a close eye on performance, integrations and data accuracy in the first weeks, maintain a fast channel for reporting issues, and work through any fixes quickly. That early responsiveness reassures users and cements confidence in the new platform, turning what could feel like a risky leap into a smooth, well-supported step forward.

Frequently asked questions

Will we lose our customisations? Supported customisations carry across or are rebuilt the supported way; unsupported ones are re-implemented using the Power Platform, which usually makes them more robust.

How long does it take? It depends on the age of the system and the depth of customisation, which is why the assessment comes first — it turns “it depends” into a concrete plan.

Can we keep some history? Yes — you choose what to migrate and what to archive, keeping the new system clean. See our on-premise to Dynamics 365 online migration services.

Frequently asked questions

Can I migrate on-premises Dynamics CRM to Dynamics 365 online?

Yes. On-premises Dynamics CRM can be migrated to Dynamics 365 online, including data, customisations, and integrations — with the right planning. The audit-clean-rebuild approach delivers far better results than a lift-and-shift.

Will I lose my customisations in the migration?

Not if it is planned well. Customisations are audited, and the ones worth keeping are rebuilt using modern, upgrade-safe methods like the Power Platform — so they keep working and survive future updates.

How long does a CRM cloud migration take?

From a few weeks for simple systems to several months for heavily-customised environments with many integrations. Data quality, customisation depth, and integration count are the main drivers.

Is Dynamics 365 online secure?

Yes. Microsoft’s cloud provides enterprise-grade security, compliance certifications, and continuous patching that exceed what most organisations can maintain on their own servers.

Ready to move your CRM to the cloud?

We audit, clean, rebuild, and migrate on-premises Dynamics CRM to Dynamics 365 online — without disrupting your business. See our cloud migration services