Dynamics CRM on-premises to Dynamics 365 online
Cohash moves on-premises Dynamics CRM and Customer Engagement organizations onto Dynamics 365 online. The first job is finding customizations that would block Microsoft's on-premises-to-online database migration. Then we rewrite SQL-based reports and Windows-authenticated integrations and map Active Directory users to Entra ID. We rehearse in a sandbox before production, and until users, data and integrations check out online, the old servers stay running.
- 01Version and customization audit
- 02Clean the source
- 03Identity and users
- 04Rehearsal migration
- 05Integrations
- 06Production cut-over and retirement
The story
Told without the client's name or anything that could identify them.
A membership organization's CRM team ran Dynamics CRM 2016 on its own servers, with SSRS reports only one DBA could change and AD FS kept mostly for claims-based sign-in. The CRM servers and their SQL Server instance were the last on-premises Dynamics workload anyone patched, and sales wanted Copilot features the on-premises org couldn't get. We audited customizations first, upgraded the org to 9.1 and removed unsupported SQL-level changes, then mapped every user to Entra ID. After a timed OP2OL rehearsal into a sandbox, production moved to Dynamics 365 online, integrations were re-pointed to the Dataverse Web API and the old servers were shut down after a read-only period.
why it was urgentMicrosoft Lifecycle has Customer Engagement 9.x on-premises leaving mainstream support on 12 January 2029. Extended support goes to 9 January 2031. The catch is the OP2OL tooling in Lifecycle Services, which won't accept anything older than 9.0. A CRM 2016 org has to be upgraded before it can move.
- openThe CRM servers and their SQL Server instance are the last on-premises Dynamics workload anyone still patches.
- recurringSales saw Copilot in a demo and keeps asking for it. The on-premises org can't have it.
- blockedReports are SQL-based SSRS files that only one DBA knows how to change.
- openAD FS exists mainly to sign people in to CRM with claims-based authentication.
The estate, before and after
Before: Dynamics CRM 2016 on-premises behind AD FS
Users signed in through AD FS using claims-based authentication against Active Directory. CRM sat on its own SQL Server, reports queried that database directly, and integrations hit the organization service with Windows credentials.
Read the diagram as text
- Sales and service users → AD FS: sign in
- Active Directory → AD FS: accounts
- AD FS → Dynamics CRM 2016: claims token
- Plugins and SQL changes → Dynamics CRM 2016: customizes
- Dynamics CRM 2016 → SQL Server: data
- SSRS reports → SQL Server: direct SQL
- Integrations → Dynamics CRM 2016: Windows credentials
- Dynamics CRM 2016 → Exchange on-premises: email sync
After: Dynamics 365 online on Dataverse with Entra ID
Sign-in moved to Entra ID, and the org itself now lives in Dynamics 365 online on Dataverse. The integrations we rewrote call the Dataverse Web API with app registrations and OAuth. Reports are FetchXML or Power BI, and Exchange Online handles server-side sync.
Read the diagram as text
- Sales and service users → Entra ID: sign in
- Entra ID → Dynamics 365 online: Entra ID token
- Plugins in sandbox isolation → Dynamics 365 online: registered in
- Integrations → Dynamics 365 online: Web API calls
- Dynamics 365 online → FetchXML and Power BI: FetchXML queries
- Dynamics 365 online → Exchange Online: server-side sync
How we run it, phase by phase.
6 phases take you from Dynamics CRM / Customer Engagement 9.x (on-premises) to Dynamics 365 online on Dataverse. Each one ends with something you can check before the next starts. As you scroll, the blocks show the estate moving across.
- phase 01
Version and customization audit
Check the version first. Then list the plugins, custom workflow activities, JavaScript, direct SQL changes, custom pages and SSRS reports, and put each one in a bucket: works online, needs a rewrite, or gets retired.
- phase 02
Clean the source
Upgrade CRM 2016 organizations to 9.1, remove unsupported SQL-level changes, register plugins in sandbox isolation and convert SQL reports to FetchXML. Trim audit and attachment data that would only inflate Dataverse storage.
- phase 03
Identity and users
Match every on-premises user to an Entra ID account, plan security roles and business units, and replace claims-based sign-in with Entra ID before the first test migration.
- phase 04
Rehearsal migration
Run Microsoft's OP2OL migration into a sandbox through Lifecycle Services. Test forms, plugins, reports and email sync, and time each step so the production downtime window is known.
- phase 05
Integrations
We repoint each integration that uses Windows credentials against the organization service, moving it to the Dataverse Web API with app registrations and OAuth. Server-side sync goes over to Exchange Online.
- phase 06
Production cut-over and retirement
Freeze changes, run the production migration, validate with key users, then keep the on-premises database read-only for an agreed period before the servers are shut down.
What the client got
What changed for the client once the work was done. Described, not scored: we don't publish client figures.
- result 01
Users sign in with Entra ID
Each on-premises user now has an Entra ID account. AD FS claims-based sign-in is gone, and security roles and business units were settled before the first test migration ran.
- result 02
Reports run on FetchXML or Power BI
SQL-based SSRS reports were converted to FetchXML or rebuilt in Power BI, so changing a report no longer needs a DBA with database access.
- result 03
Integrations authenticate with OAuth app registrations
We moved every integration off Windows credentials. They call the Dataverse Web API through app registrations and OAuth now.
- result 04
Email sync runs through Exchange Online
We moved server-side sync to Exchange Online and tested it during the sandbox rehearsal, together with forms, plugins and reports.
- result 05
No CRM servers left to patch
Key users signed off on the production migration, the agreed read-only period ran out, and then the on-premises CRM servers and their SQL Server instance were switched off.
Risks we plan for
-
Unsupported customizations block the database move
Microsoft's program puts fixing unsupported customizations and SQL-level changes on the customer or partner. Finding them late stalls the migration in Lifecycle Services.
-
Reports that can't run online
SQL-based SSRS reports don't run in Dynamics 365 online. Each one is rebuilt in FetchXML or moved to Power BI, which takes longer than teams expect when there are hundreds.
-
Integrations tied to Windows authentication
ETL jobs, portals and line-of-business apps that sign in with domain accounts stop working on cut-over day unless they're moved to OAuth first.
-
Storage capacity surprises
Years of audit history, email attachments and notes count against licensed Dataverse capacity. Data that nobody reads should be archived before the move, not after the bill.
Where AI helps, and where it needs guardrails
Online, Copilot in Dynamics 365 Sales summarizes records and drafts emails, using only data the signed-in user can see. Microsoft is shifting that to the Sales agent in Microsoft 365 Copilot. An agent or MCP server that reads or writes CRM data through Dataverse should run as its own application user, with a security role limited to the tables it needs. Audit its writes like any other integration's.
forward deployed engineers →What you're left with
We write these for your setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.
- inventory01
Customization inventory with a supported, rewrite or retire decision per item
yours to keep - inventory02
User mapping from Active Directory accounts to Entra ID
yours to keep - report03
FetchXML or Power BI replacements for SQL-based reports
yours to keep - tests04
Rehearsal migration log with timings and defects found
yours to keep - runbook05
Integration cut-over plan with new app registrations and OAuth settings
yours to keep - runbook06
Production runbook with go and no-go checkpoints
yours to keep
Platforms and services on this move
Certified engineers, wherever you need them.
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
Onsite
Engineers at your sites in the US
Nearshore
Overlapping hours with US teams
Offshore
Overnight progress on your backlog
All time zones
Coverage handed over across time zones
01We're on Dynamics CRM 2016. Can we go straight online?
Not through Microsoft's OP2OL tooling, which needs version 9.0 or later. The usual route is an in-place upgrade to 9.1 first, then the database migration. If the 2016 system is heavily customized, a fresh online build with a data migration can be cheaper, and we compare both.
02How long is the production downtime?
It depends on database size, attachment volume and how much post-migration checking the business wants before it opens the system. The rehearsal run in a sandbox gives a measured number, and we plan the weekend around that.
03Do our plugins work online?
Usually. Register them in sandbox isolation and make sure they don't reach into the file system, the registry or SQL directly. Plugins that call internal services are the tricky ones, since those services may have to go behind an API gateway or Azure Relay.
04Do you also move the reports to Power BI?
For the analysis reports, yes. The operational ones people print straight off a record tend to stay in Dynamics 365 as FetchXML SSRS reports.
Often on the same roadmap
On-premises Active Directory to cloud-first Microsoft Entra ID
We shrink on-premises Active Directory one application at a time, moving groups, users and app authentication to Microsoft Entra ID as each app is ready.
read the case studyAD FS federation to Entra ID authentication
Converting federated domains from AD FS to Entra ID cloud authentication, moving relying parties app by app and retiring the AD FS farm.
read the case studyAuth0 Rules and Hooks to Actions before end of life
Rewriting Auth0 Rules and Hooks as Actions before their 18 November 2026 end of life, with token claims compared before and after each change.
read the case studyda7d82a2 - 01Microsoft Lifecycle: Customer Engagement apps 9.x (on-premises)learn.microsoft.com ↗
- 02Microsoft Learn: Dynamics CRM on-premises to online migration (OP2OL) overviewlearn.microsoft.com ↗
- 03Microsoft Learn: Copilot in Dynamics 365 Sales overviewlearn.microsoft.com ↗
Planning this move?
A 30-minute working session with a senior engineer. No slides.
- The platform and the version you're on
- Where you need to get to, and by when
- What's custom: rules, plugins, integrations
- Any audit finding or deadline driving it