Dynamics 365 On-Premises at End of Life: Stabilise, Migrate or Rebuild

What actually stops working when Dynamics 365 on-premises reaches end of support?

Less than people fear on the day, and more than they expect over the following year. Microsoft does not turn off an on-premises server at the end of its support lifecycle. The application keeps running, users keep logging in, and that is exactly why end of life gets deferred. What ends is the supply of fixes and the ability to get help, and the risk then grows every month as the rest of the stack moves on without it.

The dates themselves differ by version and by update level. Dynamics CRM 2011, 2013 and 2015 are out of support; for Dynamics CRM 2016 and Dynamics 365 Customer Engagement (on-premises) 9.0 and 9.1, check the Microsoft Lifecycle policy page for your exact version and update rather than relying on a date quoted secondhand.

What is genuinely cloud-only, and what can the on-premises version still do?

The honest split is not "online has everything, on-premises has nothing". Dynamics 365 Customer Engagement (on-premises) 9.x runs the core Sales and Customer Service model with the Unified Interface. What it does not get is the stream of capability Microsoft has added to the online service since, and that stream is now where nearly all new investment goes. The reverse is also true: a few things are possible on-premises that the online service does not allow, and those are exactly the customizations that block a move.

Treat the table as a starting list for your own check, not as a feature matrix. Microsoft documents availability per feature, and it changes.

What do the hardware and support clocks mean for a frozen budget?

There are always two clocks, and they rarely agree. The first is Microsoft's lifecycle for your Dynamics version. The second is your own infrastructure: the Windows Server and SQL Server versions underneath, the hardware warranty, the data centre or hosting contract, and the backup product. Whichever runs out first sets the real deadline, and it is often the hardware or the hosting contract, not the Dynamics version.

A frozen budget does not remove the decision, it changes its order. The cheapest thing to fund is information: an inventory of what you run, what it depends on and what breaks if it moves. The second cheapest is reducing the risk of standing still, such as proving you can restore the system and closing the worst exposures. Migration or rebuild spend can then be planned against a date you have chosen rather than one an outage chose for you. Licensing questions, including what your current agreement entitles you to if you move, belong in our Dynamics 365 licensing and renewal guide.

• Write down both clocks: the Microsoft lifecycle date for your exact version, and the earliest date among servers, SQL Server, hardware warranty and hosting contract.
• Record what is already past its date, and who signed off that risk, if anyone.
• Identify the cost of standing still for another year: extended hardware support, hosting renewal, security exceptions, and the integrations you are not able to build.
• Separate the spend that reduces risk now from the spend that changes platform, so a frozen budget can still release the first.

When does data residency mean moving online is not permitted?

Dynamics 365 online stores data in the Microsoft cloud region chosen when the environment is created, and Microsoft operates separate government and sovereign cloud offerings in some countries. For most organizations in the UK, Germany, the Netherlands and the US a suitable region exists and residency is a configuration decision, not a blocker. It becomes a blocker in a narrower set of cases, and those cases should be settled with your legal and security teams before any architecture work starts.

Where online is genuinely not permitted, the realistic options are to keep running on-premises and harden it for a defined period, or to rebuild on a stack you host yourself. The second is what our custom CRM development is for: React, Node.js, PostgreSQL and .NET, deployed on your own servers or in a data centre you choose.

• Legislation or a regulator requires the data to stay in a country where no suitable Microsoft cloud region is available.
• Government, defence or public-sector security policy requires the system to run on infrastructure the organization or the state controls.
• A contract with your own customers forbids processing their data in a public cloud service.
• The data includes categories your policy allows only on isolated networks.

Why assess the unsupported customizations from the original partner first?

Because they dominate every estimate, whichever path you choose. An on-premises system built years ago by a partner that has since gone is almost certain to contain things the online service does not allow, things the Unified Interface does not support, and business rules that exist only in code. Until they are inventoried, any quote for migration or rebuild is a guess, and the guess is usually low.

Run it as its own workstream with its own deliverable: a list of every customization, the pattern it uses, whether it would survive a move to online, and what the business still needs it to do. The classification into must-fix, replace with configuration and delete, and the remediation in reversible slices, is described on our upgrade remediation service for unsupported customizations; the client script mechanics are on common Dynamics 365 customization mistakes. Where nobody can say what the code does at all, the forensic method in legacy migration with no original developers, starting with proving you can restore the system, applies directly.

When does hardening on-premises and buying time make sense?

Hardening is a legitimate path, not a failure to decide, as long as it has an exit date. It fits when the budget is frozen for a defined period, when data residency rules out online and a rebuild cannot start yet, or when a larger business change, such as a merger or a restructuring, will change the requirements in the next year or so. It does not fit as an open-ended plan: every month on an unsupported version increases the cost of the eventual move.

• Trigger: a hard budget freeze with a known end, a residency constraint with no compliant cloud option yet, or requirements about to change for business reasons.
• Prove restore of the whole system into an isolated environment, and write the runbook down.
• Apply the latest update available for your version, and move the operating system and SQL Server to supported releases where your Dynamics version supports them.
• Close the worst exposures: remove unused accounts and administrator rights, restrict network access to the servers, and review the integration service accounts.
• Freeze new customization, so the estimate for the later move stops growing.
• Start the customization inventory now; it is needed on every path and it is affordable within most frozen budgets.
• Agree the exit date in writing, and the review point at which the path is chosen.

When is a staged migration to Dynamics 365 online the right path?

When the Microsoft platform still fits the business, residency allows it, and the customization inventory shows the code can be brought to supported patterns at a cost the business accepts. Staged means the risky parts move before the database does, so cutover day is small. Microsoft has offered an assisted route for moving an on-premises organization database to online, and it has expected the source to be on a recent supported version, so older estates may need an upgrade on the way; check the current Microsoft Learn guidance and eligibility for your version. The alternative is a clean implementation on Dataverse with a data migration, which is often better when the old data model carries years of workarounds. The load mechanics, reconciliation and cutover for that route are covered in our data migration guide.

• Trigger: the business wants to stay on Dynamics 365, residency allows a cloud region, and the inventory shows no blocker that costs more than a rebuild.
• Stage 1, remediate on-premises: fix the full-trust plugins, direct SQL reports and legacy scripts while still on-premises, so the same code runs in both places.
• Stage 2, move the integrations to modern patterns: the Web API and OAuth where the version allows, and middleware that can be re-pointed rather than rewritten.
• Stage 3, rehearse: a trial migration into a sandbox, tested against the processes that must not break, repeated until it is uneventful.
• Stage 4, cut over with the on-premises system kept read only and restorable as the fallback and the audit source.
• Stage 5, adopt cloud-only capability in waves once the core is stable, rather than on cutover day.

When is a rebuild on Dataverse or a custom stack the honest answer?

When most of the customization exists to make an old version do something the current platform now does differently, or does not want to do at all. At that point migrating the code means paying to move workarounds. A rebuild on Dataverse keeps the Microsoft ecosystem and starts from a clean model, and treats the old system as a source of requirements and data. A rebuild on a custom stack is right when residency rules out the cloud, when per-user licensing no longer fits how many people use the system, or when the system is really a line-of-business application wearing CRM clothes.

We recommend the right solution - whether that's Microsoft Dynamics 365, Power Platform, or a custom-built CRM. Some businesses need the Microsoft ecosystem. Others need full control without licensing. We deliver both. For the custom route we build on React, Node.js, PostgreSQL and .NET, described on our custom CRM development page, and the customization inventory becomes its requirements baseline rather than wasted work.

• Trigger for Dataverse: the business wants Dynamics 365 or Power Platform, but the inventory shows the old model and code are mostly workarounds.
• Trigger for a custom stack: residency forbids a public cloud, licensing does not fit the user base, or the core of the system is custom logic the platform would fight.
• Either way: keep the old system restorable and read only until reconciliation proves the new one, and rebuild the business rules from evidence, not from memory.

How do the three paths compare side by side?

None of these paths is the right answer in general. The table is the summary to take into the room where the decision is made.

How does Solzet deliver this, and what does it not do?

We start with a fixed-scope assessment that produces the decision inputs on this page for your estate: both clocks, the version and update level, the infrastructure, the customization inventory, the integrations, the residency position and a recommended path with its triggers. The written output stands on its own, so you can take it to any partner. Delivery of the chosen path then runs in phases with a decision point at the end of each. Where the previous partner has disappeared and the project is effectively abandoned, the first weeks follow our project rescue and takeover service.

Solzet has 8+ years of Dynamics 365 Customer Engagement and Power Platform delivery, including on-premises 9.x estates, with senior consultants and full-stack developers working remotely from Yerevan, Armenia. We do not upgrade or migrate Dynamics 365 Finance, Business Central, Dynamics NAV, Dynamics AX or any other ERP; where one sits next to the CRM, we work with the team that owns it.