Dynamics CRM On-Premises to Online Migration: Version Paths, What Breaks and a Checklist (2026)

Last updated: November 9, 2026

By ZapAI Team

A Dynamics CRM on-premises to online migration moves a CRM 2011 to 2016 system, or a Dynamics 365 Customer Engagement (on-premises) organization, into Microsoft Dynamics 365 online, running on Dataverse. Microsoft’s own migration service only accepts version 9.0 or later databases. Older versions upgrade first or start clean. CRM 2016 left support in January 2026, and version 9.1 runs out in January 2031.

Plenty of CRM teams know they should move. What stops them is the unknown. Will the plug-ins survive? What happens to the SSRS reports somebody wrote in 2014? Who fixes Outlook? And is it cheaper to bring the old database along or start over?

This guide answers those questions per version and per customization level. Every product fact below comes from Microsoft Learn, Microsoft’s lifecycle pages, the August 2026 OP2OL whitepaper and Microsoft’s pricing pages, all checked on November 9, 2026, and where those Microsoft pages disagree with each other, we say so plainly. Project basics live in our Dynamics 365 CRM implementation checklist, so we won’t repeat them here.

Is Your Dynamics CRM Version Still Supported?

Only one on-premises CRM version still gets updates. Dynamics 365 Customer Engagement (on-premises) version 9.1 has mainstream support into January 2029 and extended support into January 2031. Every other version, including 9.0 and CRM 2016, is already out of support.

The 9.1 dates come from a note on Microsoft’s lifecycle page for version 9.x (on-premises), which extended support for Service Pack 1 only. That same page says 9.0 stopped getting security updates in July 2023, and 9.0 customers must move to 9.1 plus the latest cumulative update to stay supported for the next few years. Small wrinkle. The date table on that page shows end dates a day later than the note does, so plan around the month and the year rather than the exact day.

CRM 2016 is the biggest group still out there. Microsoft’s CRM 2016 lifecycle page lists the December 2016 Service Pack, version 8.2, as the last supported release, and it ended with the product in January 2026. No security patches since. For a system holding every customer email address and phone number you own, that’s real exposure. Not paperwork.

Short version? On anything except 9.1, you’re already unsupported. On 9.1, you have a deadline about four years out and a growing list of features you’ll never get.

Which Migration Path Fits Your CRM Version?

Version 9.0 and 9.1 customers can use Microsoft’s OP2OL service directly. CRM 2016 has to upgrade to 9.x on-premises first. CRM 2011, 2013 and 2015 face a chain of upgrades, so in our experience most are better off re-implementing online and migrating data.

Here’s why. Microsoft’s upgrade an organization page for version 9.x says only organizations on the December 2016 update (8.2) or later can be imported. Older Microsoft upgrade guides describe the earlier jumps one major version at a time, 2011 to 2013, 2013 to 2015, then 2015 to 2016. Each hop wants its own supported Windows Server and SQL Server combination, which is a lot of throwaway infrastructure for a database you plan to leave within the year anyway.

These are ZapAI defaults. Not Microsoft rules. The call really turns on two things, how much custom code you carry and whether anyone still understands it.

A lab upgrade is cheap insurance. Restore a copy of production onto a temporary 9.1 server, run the import, and read the log line by line. If it fails on unsupported SQL objects or ancient plug-in assemblies, you’ve learned in a few days what the OP2OL validation would have told you weeks later, with a production date already booked. If it passes, you have a 9.1 database ready for the next step.

How Does Microsoft’s On-Premises to Online Migration Work?

You nominate the project, Microsoft’s Migration Factory team opens a Lifecycle Services project, you upload a SQL backup, and Microsoft upgrades and migrates the database into a sandbox in your tenant. It costs nothing. You own remediation and validation.

Microsoft’s OP2OL process overview, updated July 2026, sets the eligibility. The source must be Dynamics CRM 9.0 or Dynamics 365 9.0 or 9.1, on a SQL Server version that release supports. Online licenses must be bought before the migration starts, and the customer or partner has to fix any unsupported customizations or SQL-level changes that would block the move before the first backup is uploaded.

Details live in Microsoft’s 28-page OP2OL whitepaper, dated August 2026. It describes three phases inside Lifecycle Services.

1. Customer information gathering. You enter organization details, then upload a compressed SQL backup to Azure storage with Azure Storage Explorer.
2. Provision and upgrade. Microsoft imports and upgrades the organization, then generates a user mapping file you fill in with Entra ID user principal names.
3. Migrate to online. The database lands in your tenant as a sandbox, user mapping runs, and an admin validates it before converting it to production.

One line in the whitepaper deserves a highlighter. Microsoft says it isn’t liable for costs or losses from delays or missed go-live dates, and validating the migrated instance is explicitly the customer’s job, not the Migration Factory team’s. Free tooling. Your risk.

Prerequisites the database has to pass

The checklist is long. These are the items that trip teams up, in our experience.

• Custom SQL-based reports must be converted to FetchXML. Unconverted reports get removed during migration.
• Plug-ins registered outside the sandbox are switched to sandbox mode, and no plug-ins may be registered on the System User entity.
• Database collation must match the default for its language, and the backup set can have only one log file.
• TDE and any third-party encryption must be off, with data decrypted before upload.
• Full-text search off, extra file groups removed, disabled constraints dropped
• A clean DBCC CHECKDB run, with zero allocation and consistency errors
• Every user needs an Entra ID account and an assigned license in the target tenant.

Size matters too. For databases of 2 TB or more, Microsoft asks you to prove the timeline in a dry run first. It also recommends trimming the biggest tables, like AsyncOperationBase and any audit history you don’t need.

Dry runs, a mock and the real cutover

Budget your attempts. The whitepaper allows at most two successful dry runs, one production mock, and then a production migration scheduled within one to two weeks of the mock. Dry runs get slower support, because production blockers jump the queue.

After cutover, Microsoft recommends a labeled manual backup and finishing data validation within three days, since sandbox backups are kept for seven. Then you import your managed packages, reconnect integrations, and switch on auditing before anyone starts correcting data.

What Changes When Dynamics CRM Runs Online?

Your code and integrations lose server-level access. Plug-ins run sandboxed, nobody touches SQL directly, reports must use FetchXML, email goes through server-side synchronization, sign-in moves to Entra ID, and API calls and storage are metered.

Start with code. Microsoft’s supported customizations page for Dataverse says plug-ins and custom workflow activities can only be registered and run in the sandbox, and assemblies must target .NET Framework 4.6.2 through 4.8. Anything reading the file system, the registry or a local network share needs a rewrite. So does code that references CRM assemblies outside Microsoft’s documented list.

Next, SQL. There’s no back door online. Microsoft’s TDS endpoint documentation describes a read-only SQL connection that follows Dataverse security, accepts only Entra ID sign-in, and times out at five minutes. Fine for ad hoc queries. Useless for the nightly SQL job that rewrites account ratings. That job becomes a plug-in, a flow or an Azure function.

Email is easier. Microsoft’s email integration page says the Email Router was deprecated in July 2018 and stopped working in April 2021, and all routing should move to server-side synchronization. Server-side sync connects to Exchange Online, Exchange Server on-premises or POP3 servers, so a hybrid Exchange shop can move CRM first and leave mailbox migration for a later, separate project.

Then come the meters. Every Dynamics 365 Sales, Customer Service or Field Service base license carries 40,000 Power Platform requests per 24 hours, per Microsoft’s request limits page, while integration identities share a tenant pool of 500,000 base requests plus 5,000 per license, capped at 10 million. Attach licenses add nothing. An old integration that polls CRM every minute for every record needs a redesign, not hope.

Storage works the same way. Online capacity splits into database, file and log, with a tenant default plus accrual for each user license. Attachments and notes land in file storage. Audit history and plug-in trace logs count against log. Ten years of email attachments that cost nothing on your own SAN now show up on a monthly bill, so archive before you move, not after the first overage notice.

Which Legacy Features Don’t Make the Trip?

Dialogs, the legacy web client, the Outlook COM add-in and the Email Router are all gone online. Some of them still work on 9.1 on-premises. That’s why teams get surprised after cutover.

• Process dialogs. Microsoft’s dialog replacement guide says dialogs are deprecated and should become business process flows or canvas apps. No automated conversion exists.
• The legacy web client. Online environments moved to Unified Interface in December 2020, and forms with unsupported JavaScript or old ribbon tricks break here first.
• Dynamics 365 for Outlook, the COM add-in. The whitepaper says it isn’t supported in the cloud. Dynamics 365 App for Outlook replaces it.
• Email Router. Replaced by server-side synchronization.
• Legacy Advanced Find. It went with the legacy web client.

Dialogs take the most work. Business process flows suit multi-person processes like quote review and approval routing, while canvas apps suit scripted, single-person tasks, like a cold-call script a rep follows on every new lead. Count your active dialogs early. Each one is a small build.

Should You Lift and Shift or Re-Implement?

Lift and shift through OP2OL when you’re on 9.x, customizations are mostly configuration, and history matters. Re-implement when you’re on CRM 2011 to 2015, carry heavy unsupported code, or no longer like how the system works.

History favors lift and shift. Your data arrives as it was, with ownership, activities, notes and record relationships intact, because Microsoft moves the database rather than re-importing records one table at a time through an import tool. Re-implementing means rebuilding those links with a data tool. Original created-on dates, owners and activity parties all take extra mapping work.

Re-implementing has its own upside. You get a clean data model, current Sales or Customer Service apps instead of years of layered changes, and a chance to drop the dead fields everyone scrolls past every day. Our Dynamics 365 CRM customization best practices explain how to keep the new build from piling up the same debt. And our list of CRM implementation mistakes to avoid covers the urge to rebuild every old workflow field by field.

For a re-implementation, the data move is its own workstream. Microsoft’s Configuration Migration tool handles configuration and reference data, not customer records. Accounts, contacts, opportunities, cases and activities go through a data integration tool or Azure Data Factory, built to respect the request limits above.

What Will Dynamics 365 Online Cost to License?

At US list, billed yearly, Sales runs $65, $105 or $150 per user per month, Customer Service $50, $105 or $195, and Field Service $105. Each user’s first app is a base license at the highest price. Extra apps come at attach prices.

Prices come from Microsoft’s Dynamics 365 Sales pricing page and its Customer Service and Field Service pricing pages, checked November 9, 2026. Sales Premium includes 1,000 Copilot Credits. Customer Service Premium includes base Copilot Credit capacity for its agents.

Base and attach is the rule that moves budgets. Microsoft’s Dynamics 365 licensing guidance says each full user’s first Dynamics 365 app must be a base license, always the highest-priced option, and attach licenses go only to users with a qualifying base. Attach licenses carry no extra platform entitlements. So a service manager who also works opportunities might hold Customer Service Enterprise as the base and Sales Enterprise as the attach. Microsoft’s public pages don’t list every attach price. Get them from your reseller in writing.

One more detail from that guidance. Dual use rights let properly licensed Dynamics 365 users run equivalent on-premises workloads, with downgrade rights back to CRM 2016, and those rights expire the day the cloud subscription does. Handy if you want the old server running read-only for a few months after cutover. Confirm that scenario with your reseller first.

Plan the seat mix by role, not by habit. Our Dynamics 365 Sales pricing breakdown compares Professional, Enterprise and Premium seat by seat, and our Dynamics 365 Customer Service guide covers the service tiers and their agents.

Which Copilot and Agent Features Need Online?

In practice, every one we’ve checked. Copilot in Dynamics 365 Sales, the Sales agent, Copilot Service workspace and the Customer Service agents run on Dynamics 365 online. Microsoft documents no route for them on Customer Engagement (on-premises).

Microsoft says so twice. Its Sales agent FAQ says the Sales agent isn’t available for Dynamics 365 or Microsoft Exchange on premises, and meeting recap and preparation need Exchange Online. The Copilot Service workspace requirements say it isn’t supported on Dynamics 365 Customer Engagement (on-premises), and each user needs Customer Service Enterprise.

Inside the Sales app, Copilot summarizes leads and opportunities, prepares meeting briefs, drafts emails and pulls answers from SharePoint, per Microsoft’s Copilot in Dynamics 365 Sales overview. Agents bill in Copilot Credits on top of seats. Our roundup of Copilot use cases in Dynamics 365 covers which ones pay off. The migration angle is simpler. Copilot answers only from records the user can see and fields someone actually filled in, so the cleanup you do before migrating doubles as your Copilot readiness work for next year.

How Long Does It Take, and What Drives the Cost?

Path matters more than seats. In ZapAI practice, a clean 9.1 lift and shift is mostly testing and validation, while a re-implementation from CRM 2011 to 2015 is a multi-month project. Customizations, integrations, reports and data volume drive both.

Cost follows the same list. Licenses are predictable. Services aren’t. The swing factors are report conversions, integration rewrites and how much nobody-knows-why code turns up during assessment. For services ranges across Dynamics 365 projects, see our Dynamics 365 implementation cost guide.

Our scoping rule, offered as practice and not a benchmark. Count plug-in assemblies, SQL-based reports, integrations and dialogs before anyone quotes a fixed fee. Those four numbers predict remediation effort better than seats do.

Where Do On-Premises to Online Migrations Fail?

Unsupported SQL changes found late, user mapping errors, integrations nobody listed, and validation squeezed into the cutover weekend. Most failures we’ve reviewed trace back to an assessment that was too short.

• Database surprises. Disabled constraints, encryption, an extra log file or a failed CHECKDB stop the upload or the upgrade. Run every whitepaper check on a restored copy first.
• User mapping. Duplicate target user names, blank rows, or workflow owners mapped to people who left. Microsoft says workflow and plug-in owners need correct target users.
• Service accounts. Integration accounts belong as application users, unless they also act like people, such as owning workflows, in which case they need a license.
• Reports that vanish. Unconverted SQL-based reports get removed.
• Integrations. Every connector that used Windows authentication, a direct SQL connection or an on-premises URL needs rework against Entra ID.
• Validation time. Business users get a weekend instead of a test script. Microsoft recommends finishing validation within three days.

Outlook causes a softer failure a month later. Users who lived in the Outlook COM add-in find the App for Outlook works differently, and their tracking habits break. Train people before cutover. If the partner who built your system is gone or stalled, our guide to switching Dynamics 365 partners covers getting documentation and admin access back first.

What Belongs on Your Migration Checklist?

Assess, prepare, rehearse, cut over, validate. Below is ZapAI practice, built around Microsoft’s OP2OL requirements.

Assess

• Confirm your exact version and cumulative update.
• Inventory plug-ins, JavaScript, SSRS reports, dialogs, workflows and integrations.
• Run the Power Apps checker against exported packages.
• Measure database size and the biggest tables.
• Choose lift and shift or re-implement. In writing.

Prepare

• Buy online licenses and create the target sandbox.
• Create Entra ID accounts and a security group.
• Convert SQL reports to FetchXML or Power BI.
• Move plug-ins to sandbox and test them.
• Replace dialogs and the Email Router.
• Clean AsyncOperationBase, audit history and stale attachments.

Rehearse and cut over

• Run a lab upgrade if you’re below 9.0.
• Dry run. Fix. Dry run again.
• Book the production mock about a week before go-live.
• Write a runbook with owners and times.
• Validate within three days, then turn on auditing.

For the platform side after go-live, our Power Platform ALM guide covers environments, pipelines and managed packages, and our Dataverse services team handles capacity, security and integration design.

What Could Change After Ignite 2026?

Probably licensing and Copilot details, not the migration rules. Ignite runs November 17 to 20, 2026, in San Francisco. We’ll refresh this post’s pricing and Copilot sections afterward.

Lifecycle dates and OP2OL eligibility rarely move at a conference. Prices, credit bundles and agent availability can, so treat the licensing and Copilot sections above as a snapshot dated November 9 and check Microsoft’s pricing pages again before you sign anything after the event.

Wrapping Up

Version decides the path. On 9.x, Microsoft’s free OP2OL service moves the database and keeps your history, provided you clean up first. On CRM 2016, a lab upgrade to 9.1 comes first. On anything older, re-implementing online is usually the shorter road.

ZapAI is a Microsoft Dynamics 365, Power Platform, Fabric and AI consulting firm in Irving, Texas, working with businesses across Dallas-Fort Worth and nationwide. Our Dynamics 365 Sales consultants and Customer Service team run on-premises assessments, lab upgrades, OP2OL projects and re-implementations. Talk to us about an on-premises CRM assessment, and we’ll inventory your customizations and tell you which path fits before you buy a single license.

Questions Teams Ask Before Leaving On-Premises CRM

Can we move Dynamics CRM 2016 straight to online with Microsoft’s tool?

Does Microsoft charge for the on-premises to online migration service?

Will our plug-ins work in Dynamics 365 online?

What happens to our SSRS reports?

Can we still query CRM data with SQL after moving online?

How long is Dynamics 365 Customer Engagement 9.1 supported?

Do Copilot features work on Dynamics 365 on-premises?