The Practical Guide to Moving from On-Prem Dynamics to Dynamics 365 Online

I want you to picture your current On-Premise Dynamics setup like an old, beloved family house. It's got character, you know exactly which floorboards creak, and you have the keys to every single room (including the basement where the boiler, your SQL server, lives).

But let's be real. The roof is leaking (security patches are lagging), the plumbing is ancient (no modern integrations), and the electric bill is astronomical (server maintenance costs).

Moving to Dynamics 365 Online is like moving into a smart penthouse. The view is better, the maintenance is handled by someone else, and the lights turn on with voice commands. But moving day? That's the stressful part. That's where things get broken, lost, or stuck in the hallway.

I'm going to walk you through exactly how to move without losing your mind, or your data.

Why Move? (Is the move actually worth the cost?)

You aren't doing this just to be trendy. You're doing it for the bottom line.

When we analyze the Dynamics CRM to Dynamics 365 migration ROI, the numbers don't lie. A Forrester study commissioned by Microsoft found that organizations can see an ROI of anywhere between 215% to 265% over three years. Note that this study was funded by Microsoft; independent validation of these figures has not been published.

Why? Because you stop paying people to "keep the lights on" and start paying them to improve the business.

• The "Opportunity Cost" Secret: The biggest cost isn't the server; it's the fact that your competitors are using AI-driven sales insights (Copilot) and you are still manually running SQL reports.

But I know what you're asking: "What is the actual cost of upgrading Dynamics CRM on-premise to online?"

Yes, the monthly subscription cost of Online looks higher on paper than your existing license maintenance. But once you factor in the hardware refresh you're avoiding, the expensive Tier 2 support, the security patching labor, and the downtime you currently suffer, the "Total Cost of Ownership" usually flips in favor of the cloud. The timeline varies significantly based on your existing infrastructure, data volume, and customization depth.

Here is a hidden cost secret: On-prem storage is cheap. Cloud storage is premium. If you migrate 500GB of "junk" data, your monthly bill will explode. The secret to ROI is cleaning before you move.

Version-Specific Compatibility: What You're Actually Migrating From

Not all on-prem migrations are equal. The technical complexity you face depends heavily on which version of Dynamics CRM you're starting from. A practitioner migrating from CRM 2011 faces a fundamentally different problem set than one migrating from Dynamics 365 On-Premises 2019.

Source Version	Key Compatibility Risks	Estimated Complexity
CRM 2011	Xrm.Page everywhere, SOAP 2011 endpoints, synchronous JS, Full Trust plugins common	High
CRM 2013	Xrm.Page, some legacy process dialogs, limited Web API support	High
CRM 2015	Mix of Xrm.Page and early formContext, legacy workflows	Medium-High
CRM 2016	Closer to modern API patterns, but legacy customizations still common	Medium
D365 On-Prem 9.x / 2019	Mostly Web API-compatible, some Full Trust plugins may remain	Low-Medium

Use this table to scope your audit before you commit to a timeline or budget.

Technical challenges to be aware of

This is the part most blogs gloss over. I won't. If you just "lift and shift," your system will crash. Here is why.

1. The Javascript Trap

You might be wondering, "Can I migrate custom JavaScript from Dynamics CRM 2011 to Dynamics 365 Online?"

Short answer: Probably not directly.

If you have code written back in 2011 or 2013, it's likely using the old Xrm.Page object (now deprecated) or, worse, direct DOM manipulation (like document.getElementById). The new Unified Interface in Dynamics 365 Online doesn't play nice with that. It's faster and responsive, but it's strict.

• The "Async" Secret: Old code was often "synchronous" (it froze the screen while it thought). The new Unified Interface demands "asynchronous" code. If you don't rewrite this, your users will experience what looks like a browser crash.
• The Fix: You have to rewrite those scripts using the formContext model. It's not just a copy-paste job; it's a refactor.

2. The SQL View Problem

In the on-prem world, we loved writing direct SQL queries against the database views. It was fast and easy. But now you need to know: How do I handle SQL views when moving from on-prem to Dataverse?

You don't. Dataverse (the backend of D365 Online) blocks direct SQL access for security. This is often the biggest shock for IT teams.

• The Insight: Many companies built entire reporting empires on top of these views.
• The Fix: You have to migrate these logic layers to Virtual Tables, Power BI, or export the data to Azure Synapse Link if you need heavy analytics. If you relied on SQL views for complex filtering in the UI, you might need to rewrite that logic using Power Automate or standard FetchXML.

3. Plugin Paralysis

What happens to my On-Premise plugins when I move to Dynamics 365 Online?

On-prem, your plugins often ran in "Full Trust." They could read local files, check the registry, or call a local IP address.

In the cloud, plugins run in "Sandbox Mode" (Partial Trust).

• The "2-Minute" Limit: Synchronous plugins have a hard 2-minute execution ceiling in the cloud. Microsoft terminates them past that threshold. Asynchronous plugins are not subject to the same limit, but they still cannot access local resources. On-prem, you could get away with sloppy, slow code. Online, efficiency is mandatory.
• The Reality: If your plugin tries to write a file to the C: drive or hit a local SQL server, it will fail. You need to re-architect these integrations to use Azure Service Bus or Webhooks.

4. The Deprecation List

You need to know what's gone before you start packing. Here is a list of the deprecated features in Dynamics 365 Online compared to On-Premise:

• Web Client: The classic interface is dead. It's all Unified Interface now.
• Legacy Process Dialogs: Replaced by Canvas Apps or Business Process Flows.
• 2011 SOAP Endpoint: Gone. You must use the Web API (OData).
• Task Flows: Deprecated.
• Voice of the Customer: Replaced by Dynamics 365 Customer Voice.
• Mail Merge: Yes, the old Word Mail Merge is gone. You now use Server-Side Document Generation or Power Automate.

5. Customization vs. Modernization

This brings up a budget question: Is it cheaper to rewrite customizations or migrate them to Power Automate?

Almost always, it is cheaper (and smarter) to migrate to Power Automate. Old workflows are rigid. Power Automate connects to everything. Don't pay a developer 50 hours to fix a C# plugin that sends an email when a 30-minute Power Automate flow can do the same thing.

6. Solution Layer Migration

One of the most under-documented blockers in on-prem to online migrations is managed vs. unmanaged solution layering.

On-prem environments frequently accumulate unmanaged customizations applied directly on top of managed solutions from ISVs or Microsoft. When you try to export and import these into a clean cloud environment, you can hit dependency conflicts, overwrite issues, and missing components errors — especially if the ISV's cloud version of their solution has a different structure than the on-prem version.

Before migration, audit every solution in your environment:

1. Run a solution component report to identify all unmanaged customizations.
2. Determine which ISV solutions have a supported cloud/AppSource equivalent — and which do not. Solutions with no cloud equivalent are hard blockers that must be resolved before go-live.
3. Decide whether to consolidate customizations into a single managed solution before migrating, or re-apply them in the target environment post-migration.

Skipping this audit is one of the most common reasons on-prem migrations stall in the UAT phase.

7. Network and Firewall Changes

On-prem Dynamics environments frequently sit behind firewall rules tuned for internal traffic. Moving to cloud endpoints means your integrations, ETL processes, and any on-prem systems that need to call Dynamics must reach external Microsoft endpoints: api.crm.dynamics.com (or your regional equivalent), Azure Service Bus endpoints if you are migrating plugin integrations, and Power Automate / Logic App outbound IPs if you are using cloud flows to replace legacy workflows.

Before cutover, review your outbound firewall rules and proxy configurations. Any integration that previously hit a local IP or internal DNS name will need to be re-pointed and re-tested against the cloud endpoints.

Handling Data, Documents, and Users

Handling Large Attachments and Notes

Migrate notes and attachments to Dynamics 365 is usually the bottleneck that kills your timeline.

If you have 10 years of history, you likely have terabytes of email attachments (activitymimeattachment) and notes (annotation).

• The Challenge: Pushing this through the standard API is slow and expensive (storage costs in Dataverse are high).
• The Solution: We often recommend SharePoint integration migration to Dynamics 365. We move the bulky files to SharePoint (cheap storage) and just leave a link in Dynamics. This saves you thousands of dollars in storage fees annually.
• Handling large attachments Dynamics 365 migration requires chunking strategies. If you try to push a 50MB PDF in one API call, it will time out. Our scripts break these files down and reassemble them in the cloud automatically.
• The Secret "Mime Type" Trap: Sometimes, old attachments lose their file extension in the database. When you migrate them, they become unrecognizable "blobs." Analyzing the binary file header — the first few bytes — lets you restore the correct extension (PDF, JPG, DOCX) so your data remains usable.

Dataverse Storage: Plan Before You Migrate

Dataverse storage is billed differently from on-prem SQL storage, and the cost structure catches most teams off guard. Microsoft allocates a base amount of storage per tenant and per licensed user, then charges per GB beyond that.

Before migration, run a storage sizing exercise against your on-prem database:

• Query the size of your activitymimeattachment and annotation tables separately — these are almost always the largest consumers.
• Identify what percentage of those attachments can be offloaded to SharePoint (which has its own, lower-cost storage allocation).
• Factor in that Dataverse stores data with overhead; raw SQL row sizes do not map 1:1 to Dataverse storage consumption.

This exercise lets you estimate your post-migration storage bill before you commit, not after.

The Identity Crisis: Users

Dynamics 365 user mapping active directory is tricky.

On-prem uses Windows Authentication (Active Directory). Online uses Entra ID (Azure AD).

If John Doe in your local AD doesn't match John Doe in your Azure AD exactly (maybe his email is john.d@company.com locally but jdoe@company.com in 365), the migration fails.

The "Stub User" Technique: What do you do with records owned by employees who left 5 years ago? You don't want to pay for a license for them in the Cloud. The secret is creating a "Stub User" or a "System Team" in the new system and mapping all historical data to that entity. This keeps your active user list clean and your license costs low.

What are the risks?

If your boss asks you to write a risk assessment for moving legacy CRM data to the cloud, you can copy-paste this table into your project plan. We cover everything from data loss to Dynamics 365 on-premise to online security risks:

Risk Category	The Risk	The Mitigation
Data Integrity	Handling large attachments Dynamics 365 migration fails due to timeouts, leaving records incomplete.	Use batch processing and "chunking" for files over 10MB. Verify checksums post-migration.
Security	Dynamics 365 on-premise to online security risks include exposure of data during transit.	Encrypt all data in transit (TLS 1.2+). Use a secure staging environment. Ensure no "intermediate" CSV files are left on unsecure laptops.
Downtime	Business stops for 3 days because the migration is slower than expected.	Run a "Delta Migration." Move 90% of data while users are still working, then only move the changes (Deltas) over the weekend.
User Adoption	Users reject the Unified Interface because it "looks different."	Invest in training before go-live. Show them how much faster the Mobile App is.
API Throttling	Microsoft blocks your import because you are hitting the server too hard.	Use "Exponential Backoff" strategies. Automatically detect the "429 Too Many Requests" error and pause, preventing a ban.

Timelines and Checklists

How long does a typical Dynamics 365 migration take for X users?

If you look at the industry average, it can be discouraging:

• Industry Standard for Small Projects (<50 users): 4-8 weeks.
• Industry Standard for Medium Projects (<200 users): 3-5 months.

Timelines vary based on the amount of data, its complexity, the number of customizations requiring remediation, and the platforms involved. The version-specific complexity table earlier in this guide is the most reliable way to calibrate your estimate before scoping begins.

To get ready, you need a plan. What is a checklist for migrating On-Prem Dynamics CRM to Dynamics 365 Online? Use this:

Dynamics CRM On-Premises to Dynamics 365 Online Migration Checklist

• 1. The Code Audit: Run the "Dynamics 365 Custom Code Validation Tool." Identify every script that will break in the Unified Interface.
• 2. The Solution Layer Audit: Export a full solution component report. Identify unmanaged customizations, ISV dependencies, and any AppSource equivalents for on-prem ISV solutions. Flag hard blockers early.
• 3. The Data Purge: Query your database for "orphaned" records (contacts with no accounts, emails with no sender). Delete them. Do not pay cloud storage prices for digital trash.
• 4. The Mapping Matrix: Create a spreadsheet mapping your On-Prem System Users to your Azure AD Object IDs. Do the same for Currencies and OptionSets (dropdown values).
• 5. The Network Review: Audit outbound firewall rules. Ensure all integration endpoints can reach api.crm.dynamics.com and any required Azure endpoints.
• 6. The "Sandbox" Test: Perform a dry-run migration of 5-10% of your data to a Sandbox environment.
• 7. The Integration Re-Wire: Re-point your ERP, Website forms, and Marketing tools to the Sandbox API to ensure they can talk to the new system.
• 8. The "Delta" Strategy: Plan your cutover. Ensure you have a script ready to catch only the data created after you started the full load.
• 9. The Go-Live: Switch DNS, disable the On-Prem user access (set to Read-Only), and run the Delta load.

[Download This Checklist as a PDF] Grab our detailed, printable Pre-Migration Assessment Checklist to ensure you haven't missed a single step.

DIY vs. Done-For-You: The Cost Reality

You have three choices here: A tool, a massive IT firm, or a specialized Partner.

Option 1: The Tool Route (KingswaySoft)

KingswaySoft is a fantastic tool. It's the Swiss Army Knife of SSIS connectors. But when you compare the cost of KingswaySoft vs. ClonePartner, the difference isn't the license fee, it's the labor.

• KingswaySoft: You pay for the license (relatively cheap). BUT, you must hire or assign a developer to write the SSIS packages, handle the mappings, debug the errors, and manage the "chunking" for attachments. If that developer costs $80/hour and spends 300 hours on this, your "cheap" tool just cost you $24,000+ in labor.

Option 2: The Big IT Firm Route

Let's talk about the massive IT service companies. You know the ones, huge glass offices, expensive suits, and very long contracts.

When you hire a massive firm, they often hire multiple resources for your project for roughly $5,000 a month per resource. But they bill you five times that amount.

• The Reality: They are figuring it out as they go. They are manually validating things. They are holding "discovery meetings" that could have been an email.
• The Business Model: The process is inefficient by design because their business model relies on billable hours. The longer it takes, the more money they make.

Option 3: The ClonePartner Route

We provide Fixed price Dynamics 365 migration services. We are an engineer-led service. You don't buy a license, and you don't buy billable hours; you buy a result.

Dynamics 365 migration partner vs. migration tool comes down to this: Do you want to manage the migration, or do you want to finish it?

Why ClonePartner? We aren't just a "body shop." We are engineers who built a business on turning "impossible" migrations into "that was easy" moments.

• Zero Downtime: We specialize in Delta Migrations so your business keeps running. We sync your data in the background while your team keeps working.
• Custom Integrations: We handle custom integrations so your business never gets interrupted.
• 30-Day Support: Our partnership doesn't end the moment the data is moved. We include a 30-day post-migration support window with every project. If you find a bug a week later, we fix it. Free.
• We Preserve the "Soul" of your Data: We maintain the "Created On" dates and "Created By" users. This sounds minor, but if you migrate everything as "Created Today by Admin," your sales team loses all historical context on when a lead actually came in.

Conclusion

Moving to Dynamics 365 Online is the right move. The security, the AI capabilities, and the mobile access are game-changers. But the road there is paved with deprecated code and SQL errors.

At ClonePartner, we've done over 1,500 successful migrations. We know where the potholes are. We know how to handle that 10-year-old SQL view and that massive library of PDF attachments.

Make your move an anxiety-free transition.

[[Book a Free Consultation with ClonePartner Today]](https://cal.com/clonepartner/meet?utm_source=blog&utm_medium=button&utm_campaign=demo_bookings&utm_content=cta_click&utm_term=demo_button_click – Let's get you to the cloud without the storm.