On-Premises Dynamics CRM to Cloud Migration in 2026
Dynamics CRM on-premise to cloud migration in 2026 has stopped being a technology decision and has become a risk decision. Mainstream support for Dynamics CRM 2015–2017 has ended, the NIS2 Directive and the DORA Regulation raise the bar for systems processing customer data, and the cost of maintaining your own infrastructure is growing faster than the cloud subscription. The question we hear during audits is no longer „should we migrate" but „when do we start so we don't start too late". In this article we show why postponing this decision today costs more than the migration project itself, what regulatory, financial and operational risks accumulate, and how to begin the Dynamics CRM on-premise to cloud migration in a way that can be defended in front of the board.
Table of contents
- 1.Why keeping Dynamics CRM on-premise in 2026 has become a risk decision
- 2.What you gain after migrating to Dynamics 365 Cloud that on-premise will never deliver
- 3.The cost of delaying migration over a 3-year window, what you actually pay
- 4.What is technically happening to Dynamics CRM on-premise in 2026
- 5.How to plan your Dynamics CRM migration to the cloud, the first step
Why keeping Dynamics CRM on-premise in 2026 has become a risk decision
Two years ago keeping Dynamics CRM 2015–2017 on-premise was still a reasonable compromise. The system worked, the team knew it, and the investment in infrastructure and licences had already been amortised. Yet our consultants running migration audits in 2025 and 2026 observe a change that can no longer be ignored. Three signals that used to appear sporadically now show up simultaneously in almost every mid-sized and large B2B organisation running on a legacy CRM. This is not about technology, it is about a change in the regulatory, market and cost environment in which the system operates.
The security audit nobody postpones anymore
The first signal that appears in conversations with IT directors is a question from the compliance team: is your CRM compliant with NIS2 and DORA? The NIS2 Directive (Network and Information Security Directive 2) has applied in Poland since October 2024 and covers medium and large companies in sectors classified as essential or important to the economy. The DORA Regulation (Digital Operational Resilience Act) introduced additional requirements from January 2025 for the financial sector and its ICT service providers. Both acts require documented risk assessment for systems processing customer data and vulnerability management throughout the vendor life-cycle.
Dynamics CRM 2015 and 2016 have been out of Microsoft mainstream support for several years now, and Dynamics CRM 2017 (the first version of Dynamics 365 Customer Engagement on-premise) is approaching the end of extended support. In practice this means that new security vulnerabilities published in CVE databases are not patched for these versions. The compliance auditor does not ask whether the system works. They ask when the last security patch was installed and who is responsible for vulnerability management. On on-premise Dynamics CRM 2016 the answer to the second question is: nobody, because the vendor no longer does this.
In practice every compliance audit that touches a CRM system processing personal customer data ends with the same conclusion: no current security patches = a required decision on risk compensation. Compensation can mean network isolation, additional cyber insurance, or a migration plan with a fixed deadline.
Each of these scenarios generates a cost that was not in the original CRM maintenance budget. Without a migration plan, handling audits becomes a standing operational item rather than an incidental one.
Sales asks for the Copilot you cannot give them
The second signal comes from a place IT usually does not expect: the sales team. Sellers in your company observe on LinkedIn and at industry conferences that the competition uses Microsoft Copilot to generate meeting summaries, draft proposals, and predict sales opportunities. The question that reaches the sales director, and from there the IT director, is simple: why don't we have this?
The technical answer is straightforward: Microsoft Copilot for Sales and the Copilot embedded in Dynamics 365 do not work on on-premise. This is not a product decision you can work around, it is a consequence of architecture. Copilot requires Dataverse (the Microsoft Cloud data layer), language models hosted in Azure, and integration with Microsoft Graph. None of these components is available in the on-premise CRM version. We frequently identify the situation where the IT director hears about this limitation for the first time precisely when the board has already approved a budget for „AI deployment in sales".
For the sales team, no Copilot means hours per week on tasks the competition has handed over to AI. Drafting follow-up emails after meetings, summarising phone calls, scoring pipeline opportunities, all done manually. This is not just a productivity cost, it is a difference in speed of response to inbound proposals.
In recent projects we see that companies using Copilot report 20–25% more seller time spent with customers because CRM administration happens in the background. For on-premise CRM this growth path is closed.
Infrastructure that gets more expensive faster than a cloud subscription
The third signal is the most financial in nature and is often the one that convinces the CFO faster than the other two. Servers running Dynamics CRM deployed in 2017 or 2018 are now past their depreciation cycle and are entering a period where replacement or leasing the next generation is a capital expense comparable to 2–3 years of cloud subscription. On top of that comes the cost of Windows Server and SQL Server licences, backup, monitoring and, more and more often, third-party support that replaces the missing Microsoft support.
On implementation projects we have learned that the cost of maintaining on-premise CRM grows non-linearly. In the third and fourth year after the end of mainstream support, line items appear that were not there before: hourly rates of external support firms grow 15–20% per year, and the internal team spends more and more time handling integrations that previously worked without supervision. Some organisations decide at this point to pursue an audit and recovery of their existing Dynamics 365 implementation. When they attempt that modernisation, however, it often turns out that this path helps only when the organisation is already in the cloud. For on-premise CRM, the ARP Ideas diagnosis most often ends with the recommendation: migration is cheaper than continuing to maintain.
The most underestimated item is IT team time. Every hour spent maintaining the legacy CRM is an hour not spent on development projects. In organisations that fully calculated this cost during a Migration Readiness Assessment, it turned out that the total TCO of on-premise over a 3-year window was 25–35% higher than cloud TCO.
More importantly, this difference grows year over year because the cloud subscription is predictable, while on-premise costs start to escalate particularly in the third year after the end of support.
What you gain after migrating to Dynamics 365 Cloud that on-premise will never deliver
The three signals described earlier show why continuing on-premise CRM accumulates risk. The other side of the same decision is the question of what actually appears in the organisation after migrating to Dynamics 365 Cloud that was not there before. Our consultants frequently point to one important distinction: the cloud is not „a better version of the same CRM". It is a different category of tool because it operates within an ecosystem that on-premise simply cannot access. Three areas of that difference matter most for the decision-maker building a business case for the board.
Microsoft Copilot and native AI in sales and service processes
The first area is the native integration with Microsoft Copilot, described earlier from the perspective of absence. The way to unlock these features is described step by step in our guide to a Dynamics 365 Sales implementation step by step. After migrating, the seller gets Copilot as part of the standard interface for working with an opportunity. The system independently summarises the history of the customer relationship before a meeting, email drafts are generated from previous correspondence and notes, and after a phone call recorded in Teams, Copilot generates a list of next steps and an opportunity status update in the pipeline.
In Dynamics 365 Customer Service Copilot works analogously on the post-sales support side. The agent receives suggested case responses, automatically generated case summaries at escalation, and conclusions extracted from the knowledge base. In recent projects we see that organisations that launched Copilot in Customer Service report a 25–30% reduction in average handle time without changing team size. For on-premise CRM there is no path that would replicate this result, and there will not be one because Microsoft no longer builds AI features for the on-premise version.
The most measurable benefit of Copilot shows up in the first 90 days after launch. Sellers recover time previously spent on CRM administration, and customer service closes cases faster because knowledge-base answers are suggested as the agent types.
Over a year this translates into a 20–25% productivity difference for the sales team and a comparable one in post-sales support, without the need to hire new people.
Integration with Microsoft 365 and Power Platform without custom code
The second area concerns integration with the rest of the Microsoft ecosystem. On on-premise every integration with Outlook, Teams, SharePoint, or a cloud ERP system requires dedicated code, a connector built on the CRM Web API, and maintenance of the environment on your own infrastructure. In Dynamics 365 Cloud the same integrations are natively available through Dataverse — the data layer that simultaneously serves CRM, Power Apps, Power Automate and Power BI.
In practice this means that an automation which required 4–6 weeks of developer work on-premise takes 2–3 days of configuration in Power Automate. Preview of CRM data in an Outlook contact card, automatic saving of customer emails in opportunity history, a Power BI report combining CRM data with a financial system. All of this works after migration without building custom connectors. Our system architects emphasise that for the IT department this is not just savings on developer hours, but also a shift of competencies from code maintenance to business process development.
The difference between on-premise and cloud becomes particularly visible in automation projects that cross system boundaries. CRM integration with an invoicing system, a complaint handling system, or an external marketing automation tool becomes a question of hours in the cloud, not months.
Power Platform also provides a tool for building your own applications without a developer. Offer approval workflow, customer-facing ticket registration screen, custom seller dashboard, all of this runs on the same data layer as CRM.
Security at Azure standard and regulatory compliance
The third area is security and compliance. In the cloud, responsibility for the infrastructure underneath the CRM passes to Microsoft as the responsible entity under NIS2 and DORA. Your organisation still owns access configuration, identity management, and data classification, but the infrastructure, OS-layer patching, business continuity, and physical data centre security are part of the service.
Dynamics 365 Cloud runs in the Azure environment, which maintains ISO 27001, ISO 27018, SOC 1, SOC 2, and SOC 3 certifications and GDPR compliance. For the compliance auditor this is not a marketing argument but a concrete set of reports available in the Microsoft Service Trust Portal that become attachments to NIS2 and DORA documentation. Security patches are deployed by Microsoft on a continuous cycle, without planned maintenance windows on the customer side.
For the IT director responsible for compliance, the most important change is the shared responsibility model. Microsoft owns the infrastructure, hypervisor, operating systems, and the Dynamics 365 application layer. The customer owns role configuration, data, and integrations.
This split narrows the audit scope on the customer side and shifts the conversation from „do we have the patches" to „do we have permissions configured correctly". The second conversation is easier to win than the first.
The cost of delaying migration over a 3-year window, what you actually pay
Viewing migration solely through the lens of project cost is a common strategic mistake we encounter in organisations building a business case for the board. The full picture requires comparing two financial paths over a 3-year window: the path of keeping on-premise and the path of migrating to Dynamics 365 Cloud. During consultations we often point out that the first path contains cost categories absent from the standard IT spreadsheet, while the second has a measurable return visible from the thirteenth month after go-live. Three elements of this calculation decide whether the migration project gets approved on the first attempt.
Four cost categories that don't show up in the IT spreadsheet
A standard CRM maintenance spreadsheet usually lists hardware and licence items. It omits four categories that become the dominant share of on-premise TCO by year three. The first is third-party support, whose hourly rates from firms specialising in legacy CRM grow 15–20% per year, and three-year contracts contain escalation clauses that are not visible in year one. The second is hours of the IT team spent on maintaining integrations and plug-ins that nobody updates because „it works". The third is lost productivity of sellers and service agents who do not have access to AI tools available in the cloud. The fourth is the cost of delaying development projects that do not start because the team is busy keeping the CRM running.
The second way of counting costs, the 3-year TCO comparison of third-party support versus migration to the cloud, requires a separate accounting of these categories because each has a different growth dynamic. Without including them, the conversation with the CFO ends as a debate about the cloud subscription price rather than the real total cost. In migration audits run for mid-sized organisations, the average gap between the client's own estimate and the actual on-premise TCO was 35–45%, always in the direction of underestimation.
The hardest item to estimate is lost productivity because it is in no spreadsheet. It is calculated comparatively: how long handling a typical process takes on-premise versus how long it would take with Copilot and Power Automate. The difference, multiplied by the number of sellers and the hourly cost, often exceeds all other items combined.
The second item often missing is the cost of delayed development projects. Each new business project that could start in the cloud within weeks requires months on on-premise. That time is also money.
Regulatory risk as a line item in the business case
The second element of the calculation is regulatory risk, which until 2024 was treated in business cases as a qualitative item. Since NIS2 and DORA came into force it has become a monetary one. The maximum administrative fine under NIS2 for essential entities is 10 million euros or 2% of annual global turnover, with the higher of the two values applied. For important entities it is 7 million euros or 1.4% of turnover respectively. DORA provides for analogous fines for the financial sector and its ICT service providers, with the additional possibility of corrective measures imposed by the competent supervisory authority.
The real cost, however, does not end with the potential fine. The business case also has to include the cost of a post-incident audit, customer notification, reputational management, and, more and more often, an increase in the cyber insurance premium for organisations running systems without current patches. Since 2025, insurers have been pricing legacy CRM as a risk factor and can raise the premium by 30–50% or refuse coverage for a specific component.
Important: Migrating to Dynamics 365 Cloud does not release your organisation from NIS2 and DORA obligations, but it does shift part of the responsibility to Microsoft as the infrastructure provider. A full comparison of the scope of responsibility and the cost of compliance in both models requires individual analysis. We deliver that analysis during a free Migration Readiness Assessment, which results in a business report containing the project estimate, comparative TCO, and a regulatory risk map.
Regulatory risk has another dimension that is not visible in the spreadsheet: auditor response time. NIS2 requires reporting a significant incident within 24 hours of detection. An organisation running on on-premise CRM without current patches is not able to document that the incident was not caused by a known vulnerability.
In Dynamics 365 Cloud, the incident reporting cycle is part of the Microsoft agreement. For the auditor this is the difference between a 30-day post-incident report and a report on demand.
Why the third year of delay is the most expensive
The third element of the calculation is dynamic in nature and concerns the pace at which costs grow over time. In the first year after the end of mainstream support, the costs of maintaining on-premise grow relatively slowly because the infrastructure still works, third-party support is fresh, and the team knows the system. In the second year problems start to appear: the first unpatched vulnerabilities, the first integrations that stop working after an external system upgrade, the first questions from compliance.
The third year is the most expensive because three factors accumulate at the same time. Hardware from 2017 enters a period of failure and requires replacement. Third-party support escalates rates by another double-digit percentage because fewer and fewer firms are willing to support legacy CRM. The IT team starts losing competence on the old system because new hires learn the cloud and old ones leave or move to other projects. Our consultants often identify this moment as the point at which the annual cost of maintaining on-premise exceeds the annual cost of the Dynamics 365 Cloud subscription, and does so by a factor of two.
The on-premise maintenance cost curve is exponential, not linear. Each year brings line items that cannot be recovered because they stem from departing competencies, accumulating technical debt, and structural shifts in the support market. By year three the CFO starts seeing forecast items that nobody planned in year one.
A migration decision in year one after the end of support is the cheapest. In year two it is more expensive but still rational. In year three it becomes reactive because it is forced by a security incident, a compliance audit, or an infrastructure failure.
What is technically happening to Dynamics CRM on-premise in 2026
The regulatory and financial arguments laid out in earlier sections are what usually reaches the board. The system architect, however, needs a deeper understanding of what is technically happening to Dynamics CRM on-premise in 2026, in order to assess the scale of technical debt and prepare an environment inventory before the migration project. Our system architects emphasise that a sound technical assessment is what decides whether the project closes within the planned budget and schedule. Three aspects matter most here.
The end of security patches and accumulating technical debt
Microsoft Dynamics CRM 2015 ended mainstream support in January 2021 and extended support in January 2026. Dynamics CRM 2016 has extended support through July 2026. Dynamics 365 Customer Engagement on-premise (the 2017 version) is covered by the Modern Lifecycle Policy, which does not guarantee fixed dates but does require keeping the current version in place, which most organisations do not do because on-premise does not update automatically. In practice, each of these versions is today outside the period of regular security updates.
Technical debt does not stop at CRM itself. Around it runs Windows Server (often 2012 R2 or 2016, both out of support), SQL Server (2014, 2016, sometimes older), and Internet Information Services in a version incompatible with modern TLS standards. Each of these components has its own CVE list that has to be reported separately to the auditor. Some organisations that had previously lived without an incident reached similar conclusions during an audit of their existing Dynamics 365 deployment. When they attempted modernisation, it turned out that the technology stack supporting the CRM was so outdated that further work on on-premise no longer made business sense.
The most underestimated aspect is accumulation. Each component on its own does not look alarming, but together they form an environment that cannot be defended in front of a security auditor. CRM 2016 + Windows Server 2012 R2 + SQL Server 2014 are three unsupported systems running in the same physical environment, processing customer data.
Migrating the CRM to the cloud automatically eliminates the first two debt items because the infrastructure moves to Microsoft. SQL Server remains if it stays on-premise as the backend for the ERP, and that item has to be planned separately.
Disconnection from the Power Platform, Dataverse and AI ecosystem
The second technical aspect is data layer architecture. On-premise Dynamics CRM stores data in a SQL Server database accessed via the CRM Web API and directly via SQL (with licensing limits). Dynamics 365 Cloud is based on Dataverse — the data layer shared by CRM, Power Apps, Power Automate, Power BI, and Microsoft Copilot Studio. This is an architectural difference that cannot be worked around on the on-premise side.
The consequences are practical. Every new Microsoft feature developed inside Power Platform bypasses on-premise. Copilot AI models, cross-system process automation in Power Automate, dashboards combining CRM data with any other source in Power BI. All of this requires Dataverse. An organisation on on-premise not only lacks these features today. It will not have them in the future because Microsoft no longer builds for this platform. Strategically this means that every investment decision in on-premise CRM after 2024 is a decision to deepen isolation from the rest of the Microsoft ecosystem.
For the system architect, the most important realisation is that Dataverse is not „just another database". It is an abstraction layer that handles permissions, integrations, audit, and metadata uniformly for all Microsoft applications. On-premise CRM has its own permission logic, its own audit, and its own API that do not share with the rest of the stack.
After migrating to Dataverse, a multiplier effect emerges: every new application built in Power Apps uses the same data layer, the same permissions, and the same audit history. On on-premise, every such application requires building its own integration layer.
Environment inventory as a prerequisite for migration
The third technical aspect is preparing for the migration project. The most common cause of budget and schedule overruns in a CRM migration is the lack of a thorough environment inventory before kick-off. In migration audits run by ARP Ideas we see that organisations regularly underestimate the number of active customisations. A client declares „we probably have 10 plug-ins and a dozen workflows", and after inventory it turns out there are 47 .NET plug-ins, 130 classic workflows, 22 custom entities, and 18 integrations with external systems.
The inventory answers three questions that drive the migration estimate and schedule: what moves directly to the cloud (typically 60–80% of components), what requires refactoring to Power Platform (15–25%), and what has to be rewritten or replaced with another solution (5–15%). Preserving customisations, plug-ins and workflows during migration to Dynamics 365 Cloud is a separate technical topic that requires a distinct architectural decision for each component category. Without that decision, the migration estimate rests on assumptions rather than data.
Inventory is not a formality you can defer to the project phase. It is the first stage on which the realism of the entire business case depends. Each plug-in, workflow, and integration has three parameters: whether it is active, whether it serves a critical business process, and whether it has a native equivalent in the cloud.
Only these three parameters, combined with a data inventory, form the basis for the estimate. ARP Ideas performs this inventory in 10 working days as part of the Readiness Assessment. The result is a document that becomes an attachment to the migration proposal and the basis of the board decision.
How to plan your Dynamics CRM migration to the cloud, the first step
The regulatory, financial, and technical arguments lead to a single operational question: what is the first concrete step your organisation should take in the coming weeks. Our consultants, in meetings with IT directors and project sponsors, regularly point to the same pattern: a Dynamics CRM on-premise to cloud migration rarely starts with the project. It starts with the decision to run a Readiness Assessment — a document that allows the board's questions to be answered with data rather than declarations.
Five signals that the organisation is ready to start migration
The decision to start a migration project does not require all conditions to be met at once. Three out of the five signals below are enough for the Readiness Assessment to make business sense and for the project to be defensible in front of the board.
1
CRM version out of support
If you are running Dynamics CRM 2015, 2016, or an early Dynamics 365 Customer Engagement on-premise, you are outside the period of regular security updates, and the growing technical debt will generate rising maintenance costs in every subsequent quarter.
2
Compliance questions are starting to surface
If the security department, an internal auditor, or the cyber insurer has begun asking about the patch cycle or vulnerability management in the CRM, you are in a phase where „we are working on it" no longer suffices.
3
AI plan for sales or service
If the board has approved initiatives around Copilot or Power Platform, and your CRM is on-premise, that plan will not be delivered without prior migration.
4
Infrastructure budget on the plan
If your capital planning for the coming year contains items for server replacement, hardware leasing, or extending a third-party support contract, the same budget will typically cover 60–80% of the first year of cloud migration.
5
Team competencies are diverging
If legacy CRM specialists are leaving or moving to other projects while new hires are learning the cloud, the window for a reasonable migration with your own team is starting to close.
In organisations that come to us with three or four signals at once, the Readiness Assessment is usually the first conversation in which all these elements get counted together. Each signal on its own looks like a problem for one department. Together they become a strategic argument the board cannot ignore.
The threshold of three signals is not arbitrary. It is the line above which the cost of delaying the decision starts to exceed the cost of the project, and below which the migration conversation can still happen in planning mode rather than incident-response mode.
From Readiness Assessment to go-live, the role of the implementation partner
Migrating Dynamics CRM to the cloud in the ARP Ideas methodology consists of four sequential stages. The first is the Readiness Assessment — a five-day process whose output is a business report containing an environment inventory, a regulatory risk map, comparative TCO, and an initial project estimate. This document is the basis of the board decision and the starting material for every subsequent phase. The second stage is the technical inventory — a ten-day exercise in which the ARP Ideas architects catalogue plug-ins, workflows, custom entities, integrations, and data, classifying each component by migration path.
The third stage is the migration itself — data transfer, refactoring of the necessary components, configuration of Dataverse and Power Platform, regression testing, and parallel launch of the production environment. The concrete migration roadmap from audit to go-live in 12 weeks is a service product from ARP Ideas and the subject of a separate conversation during the Readiness Assessment, because schedule details depend on the scale of the environment and the number of components requiring refactoring. The fourth stage is Dynamics 365 optimisation after migration — the first 90 days after go-live, during which we tune the configuration, launch Copilot, and introduce Power Automate automation in processes that previously ran manually.
In this sequence the role of the implementation partner is most visible in the first and fourth stages. The Readiness Assessment requires experience in estimating migrations based on data from real projects, not on guesses. Optimisation after go-live requires familiarity with platform features that were not yet available on on-premise and are only now entering the daily work of the teams. The second and third stages are more technical, but their success depends on the quality of the first.
Recommendation
Dynamics CRM on-premise to cloud migration in 2026 is not a technology project, it is a decision to reduce regulatory, financial, and operational risk. The first concrete step your organisation can take in the next 14 days is to schedule a Migration Readiness Assessment with an experienced implementation partner for migration to Dynamics 365 Cloud. The output is a business report that answers all the board's questions, namely comparative TCO, risk map, schedule, and project estimate, in a single document. That is the basis for a decision that can be defended.
Each of the four stages has its own deliverables, measurable milestones, and a decision point at the end. After the Readiness Assessment the decision is „go-into-project or not", with no financial commitment. After the technical inventory we approve the final estimate and schedule. After migration there is go-live, the date of which is fixed before the project starts, not after.
This sequence reduces client-side risk. Every subsequent phase is a decision based on the results of the previous one, not a commitment taken at the very beginning.
Frequently asked questions about Dynamics CRM cloud migration
Six questions that come up most often in consultations with IT directors and project sponsors considering a Dynamics CRM on-premise to Dynamics 365 Cloud migration, with answers based on migration audits and projects delivered by ARP Ideas.
Free consultation
Considering a Dynamics CRM migration but need arguments for the board?
In a 30-minute conversation with an ARP Ideas migration architect we will review the state of your on-premise environment, identify the areas of greatest risk, and walk you through the scope of the Migration Readiness Assessment — a business report we deliver in 5 working days as the basis for a board decision.
✓ Migration Readiness Assessment in 5 working days
✓ Business report with measurable TCO and risk map
Talk to a migration architect
Needs analysis and initial readiness review in a 30-minute call
