AX 2012 or NAV on VMware? Replace It, Don't Rehost It

The short answer

An AX 2012 or NAV system that runs on VMware should not move to Azure VMware Solution (AVS) or Azure VMs as its long-term home. Every AX 2012 release is already out of Microsoft extended support, NAV 2016 left it in April 2026, and NAV 2017 and NAV 2018 follow in January 2027 and January 2028. Replace AX with Dynamics 365 Finance & Operations and NAV with Dynamics 365 Business Central, and rehost only as a short, dated bridge when the VMware renewal leaves no other option.

This post is part of our guide to leaving VMware after Broadcom. The guide covers the whole estate. This post covers the one workload that most often gets the wrong treatment: the old Dynamics ERP sitting on a VMware cluster, usually with its own SQL Server beside it.

Where do AX 2012 and NAV stand in Microsoft's lifecycle?

Microsoft publishes fixed support dates for each release on its Lifecycle site. The table below uses those dates, as of October 2026.

Microsoft had already pushed the AX 2012 and AX 2012 R2 extended support date back once, from 12 October 2021 to 12 April 2022. Nobody should plan on another extension. This table does not cover NAV 2015 and earlier, so check Microsoft's Lifecycle site for those releases.

The NAV 2018 date matters for VMware planning in a specific way. NAV 2018 keeps extended support until 11 January 2028, three months after vSphere 8 reaches end of general support on 11 October 2027. A NAV 2018 estate on vSphere 8 therefore loses VMware support first. Rebuilding the VMware layer to buy those last three months makes little sense.

What about the SQL Server and Windows Server underneath?

The ERP application is only one layer. Each AX or NAV system also needs a database server and an operating system, and those have their own clocks. ERP servers built in the AX 2012 and NAV era often run on one of the platform versions below. This post does not say which versions any particular AX or NAV release supports or runs on, so check your own inventory first.

Two points in that table catch people out.

First, the old rule that "Azure gives you free ESUs" no longer holds as a general rule. Microsoft announced on 27 March 2026 that new ESU offerings from 1 April 2026 carry the same pricing inside and outside Azure. Microsoft has not published a page that names Windows Server 2016 and states whether its ESUs are free on Azure VMs or AVS. Budget for them as a cost until Microsoft says otherwise.

Second, NAV 2017 extended support ends on 11 January 2027, one day before Windows Server 2016 extended support ends on 12 January 2027. A NAV 2017 system on Windows Server 2016 loses support at both layers in the same week.

Why does rehosting only move the problem?

Rehosting means moving the ERP virtual machines as they are, either to AVS (VMware in Azure) or to Azure VMs. It is the right answer for plenty of workloads, and our route guide explains where. It changes the address and little else for an out-of-support ERP.

1. The application stays unsupported. AX 2012 on an Azure VM is still AX 2012. Its support status does not change with the hosting, and neither do its customisations or integrations.
2. The platform clocks keep running. SQL Server 2014 ESUs stay free on Azure only until 8 July 2027. SQL Server 2016 ESUs now cost money in Azure. Windows Server 2012 R2 has no more ESUs at all. A rehost buys months, not years.
3. AVS brings Broadcom back into the contract. New AVS deployments since 1 November 2025 must use portable VCF, which you buy directly from Broadcom. The subscription must cover every physical core: an AV36 host counts as 36 cores and an AV64 host as 64, so three AV64 hosts need 192 cores. AVS clusters need at least three hosts. Putting one old ERP on AVS means licensing a whole cluster.
4. You pay for the move twice. A rehost still needs discovery, a migration plan, testing and a cutover weekend. You then repeat most of that effort when the replacement goes live, and the second time you also migrate data into a new system.

Azure VMs are the cheaper of the two rehost targets for a single ERP, because they avoid VMware licensing entirely. That makes them a reasonable bridge. They are still a poor destination.

What does replacing look like?

Replacing means moving the business onto a current Dynamics 365 product and switching off the old ERP servers along with the VMware hosts under them. The target depends on where you start.

AX 2012 to Dynamics 365 Finance & Operations

Finance & Operations is Microsoft's enterprise ERP for finance, supply chain, manufacturing and HR. AX 2012 customers have two broad paths. A technical upgrade carries the AX data and configuration forward. A fresh implementation starts from standard processes and migrates only the data you need.

We pick between them on one test: do the current AX processes still match how the business works? If they do, an upgrade is faster and less disruptive. Our AX 2012 to D365 Finance upgrade case study shows that path. Years of customisation that built workarounds into AX usually make a fresh implementation cheaper over the life of the system. We explain the risk of carrying old processes forward in Stop mapping your old process onto a new system.

NAV to Business Central

Business Central is Microsoft's cloud ERP for growing businesses, and it is the natural successor for NAV users. The work covers master data and open balances, plus a review of each customisation against what Business Central now does as standard. Integrations that used to talk to an on-premises NAV server also need re-pointing. Our migration packs cover NAV to Business Central as a fixed-scope project.

The steps we follow

1. Inventory the ERP estate: application servers, database servers, file shares, scheduled jobs, integrations and reports. Agentless dependency analysis in Azure Migrate covers up to 3,000 servers per appliance and shows which other servers talk to the ERP.
2. Classify every customisation. Each one is retired, replaced by standard functionality, or rebuilt as an extension.
3. Agree the data scope: which master data and open transactions move, and how much history comes with them. History that stays behind needs an archive the auditors can still read.
4. Record a test baseline on the old system before anything changes. The baseline lists the business processes that must give the same result after go-live, such as a sales order to invoice or a month-end close.
5. Build the solution and migrate the data, then re-test against that baseline before cutover.
6. Decommission the ERP virtual machines and the SQL Server instances that served them. This step removes cores from the VMware renewal, which is where the saving shows up.

Step 4 is where we use AI testing. Agents capture how the business processes behave before the change and re-run the same checks afterwards, through the user interface. We already run this for a client whose every release is AI-tested, including UI testing and Azure DevOps bug verification (read the case study). That is release testing, not an ERP migration, but the same approach applies to proving an ERP cutover. More detail is on our agentic software delivery page and in Proving every app still works after a VMware migration.

A real example

We recently took an oil and gas company based in Scotland off its own VMware infrastructure. The client is anonymised. We used three routes in the same estate: containerised applications moved from VMware to SUSE Rancher, the ERP was replaced with Dynamics 365 Finance & Operations rather than rehosted, and other workloads moved to Azure services, including the SQL Server estate. Those workloads went to platform services, not only to virtual machines. The oil and gas VMware exit case study describes the project.

That project follows the pattern this post recommends. The ERP left VMware once, as a replacement, while the other workloads took the routes that suited them.

How do you sequence the ERP replacement with the rest of the VMware exit?

An ERP replacement usually takes longer than moving the rest of the estate, and it needs the business, not just IT. We run it as its own track and start it first. The infrastructure track then works around it.

1. Find the deadline that actually binds. That might be the VMware subscription renewal, the end of support (SnS) on a perpetual licence, an AVS date, the 11 October 2027 vSphere 8 date, a hardware refresh or a data centre exit. Perpetual licence holders keep the right to use the software, but get support only until their existing SnS contract ends, because Broadcom stopped selling new SnS renewals for perpetual licences in December 2023.
2. Separate the ERP servers and their dependencies in the inventory. The database server and any integration middleware usually move with the ERP decision, not with the general estate.
3. Start the ERP replacement project.
4. Move the rest of the estate by route in parallel: Azure VMs, Azure platform services, containers, or AVS as a bridge. Our cost model guide shows how to price each choice against the Broadcom renewal.
5. Leave the ERP on its current VMware platform until cutover, if that platform stays supported and licensed long enough. Shrinking the VMware estate around it reduces the core count you need to renew.
6. Cut over to Dynamics 365 and decommission the last ERP hosts.

When is a short rehost the right bridge?

The VMware platform sometimes will not last until the ERP replacement goes live. The support contract may end first, or the data centre lease may expire. A short rehost is then a sensible bridge, provided you treat it as temporary from day one.

• Write the end date down. Tie the bridge to the replacement go-live date and put both in the same plan.
• Prefer Azure VMs to AVS for a single ERP. AVS needs a portable VCF subscription for every core in a cluster of at least three hosts, which is a lot of Broadcom licensing for one system.
• Check the ESU position of the bridge platform. SQL Server 2014 ESUs stay free on Azure VMs until 8 July 2027. SQL Server 2016 ESUs are billed. Windows Server 2012 R2 has no ESUs left to buy.
• Avoid long commitments. Azure savings plans run for one or three years and cannot be cancelled or refunded, and unused hourly commitment does not roll over. A bridge that ends inside a year should not carry a three-year commitment.
• Test before and after the bridge move, using the same baseline you will use for the replacement. You then test the ERP against one set of expectations three times, rather than writing three test plans.

What if the ERP is already on AVS?

Some organisations moved AX or NAV to AVS before Broadcom changed the licensing. Two Microsoft deadlines now apply to them. Licence-included pay-as-you-go AVS deployments must move to portable VCF by 31 October 2026 to stay compliant. Customers with licence-included reserved instances must exchange them for VCF BYOL reservations, or move off AVS, by 30 August 2027, and a reservation that expires earlier loses the licence-included benefit when it expires. Microsoft also reports BYOL registrations to Broadcom monthly, and it may suspend over-deployed or unregistered private clouds.

Each of those dates forces a licensing decision. We recommend making the ERP replacement decision at the same time, so that you do not buy a VCF subscription to keep an old ERP running on AVS.

Is there Microsoft funding for this?

Microsoft's migration funding now sits under Azure Accelerate, which Microsoft's page calls Frontier Accelerate for Azure for its FY27 (1 July 2026 to 30 June 2027). The page lists Azure credits, partner engagement funding, funded assessments and Cloud Accelerate Factory, and it names VMware to AVS as a supported scenario. Microsoft partners with the relevant specializations can access these programmes for their customers. Ask your partner which ones apply to your project before you sign a migration budget.

How we help

Our VMware exit service starts with an assessment that places every workload on a route, the ERP included, and builds a cost model against your Broadcom renewal. That assessment also produces the replacement plan for AX and NAV estates and, where needed, a dated bridge. The main guide covers the rest of the estate.