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: Dynamics 365 (Customer Engagement, Business Central or Finance and Operations), Power Platform, or a custom-built CRM. One team for CRM, ERP and the integration between them. 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.

What are your options after Dynamics AX end of support?

Dynamics AX is the ERP side of the same end of life question, and its clock has already run out. Dynamics AX 2012 R3 mainstream support ended on 12 October 2021 and extended support ended on 10 January 2023. Dynamics AX 2009 support ended on 12 April 2022. As with an on-premises CRM, nothing switched off on those dates: the system still posts invoices and runs the warehouse, but Microsoft fixes and support cases have stopped, and the servers and SQL Server versions underneath it keep ageing on their own clock.

The options are the same three shapes as above, applied to an ERP. Upgrade: finance and operations apps provide a documented upgrade path for Dynamics AX 2012 R2 and R3 data and code, run in Analyze, Execute and Validate phases, which brings your history and the customizations worth keeping into Dynamics 365 Finance and Supply Chain Management. Reimplement: start clean on Finance and Operations and migrate master data and open balances, which is the usual answer for AX 2009, since it uses a separate data migration tool rather than the upgrade path, and for AX 2012 RTM, which the upgrade path does not support. Or harden and buy time with a written exit date, exactly as for the CRM. Where Finance and Operations is more platform than a smaller AX estate needs, Business Central deserves a look as the destination. Solzet runs the assessment, the code analysis and the upgrade itself as our Dynamics AX to Finance and Operations upgrade service.

• Write down the same two clocks as for the CRM: the AX lifecycle position above, and the earliest date among servers, SQL Server, hardware warranty and hosting contract.
• Inventory the X++ customizations and integrations before anyone quotes, because on an AX estate they decide the upgrade effort just as unsupported code does on a CRM.
• Decide upgrade or reimplement per area, not for the whole system at once: the general ledger history may be worth carrying forward while a heavily modified warehouse process is not.
• If the CRM is moving in the same period, plan both together, so the CRM is not re-pointed at an ERP that is about to change underneath it. Dual-write connects Customer Engagement and Finance and Operations through Dataverse once both are online.

What about Dynamics NAV and Dynamics GP on-premises?

The same logic applies, with later dates. Dynamics NAV 2018 mainstream support ended on 10 January 2023 and its extended support ends on 11 January 2028. Microsoft ends Dynamics GP support for enhancements, tax updates and technical support on 31 December 2029, with security updates until 30 April 2031. Both have a direct destination in Dynamics 365 Business Central. Dynamics NAV upgrades to Business Central on-premises first and then switches to Business Central online with the cloud migration tool. Dynamics GP data from GP 2015 onwards moves to Business Central online with the built-in cloud migration tool.

A deadline a few years out is the comfortable kind, as long as the inventory, the extension plan for the old customizations and the data clean-up start well before it. Our migration to Business Central service covers both routes, from the first inventory to the cutover.

How does Solzet deliver this?

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 works on both sides of the Microsoft business stack, with senior consultants and full-stack developers working remotely from Yerevan, Armenia: Dynamics 365 Customer Engagement, including on-premises 9.x estates and their move online, Power Platform and custom CRM, and on the ERP side Business Central and Finance and Operations, including the upgrade from Dynamics AX and the migration from Dynamics NAV and Dynamics GP. Where the CRM and the ERP reach end of life in the same period, one team plans both moves and the integration between them.