Dynamics AX to Dynamics 365 Upgrade: Paths, Tools and Upgrade vs Reimplement (2026)

Last updated: November 9, 2026

By ZapAI Team

A Dynamics AX to Dynamics 365 upgrade moves an AX 2012 R2 or R3 system, code and full history included, onto Microsoft Dynamics 365 Finance and Supply Chain Management in the cloud. AX 2009 and AX 2012 RTM have no direct upgrade. Every AX version is now out of Microsoft support, AX 2012 R3 since January 10, 2023.

Most AX customers we talk to know they have to move. The open question is how. Upgrade or start over? Finance or Business Central? Now or next year?

Those questions set the budget long before anyone writes a line of X++, so this guide covers Microsoft’s supported paths by AX version, what the tools actually do, the shift from Lifecycle Services to the Power Platform admin center, licensing, reporting, and the decision rules we use with CFOs and IT leads at mid-market manufacturers, distributors and services firms. Facts were checked against Microsoft Learn and Microsoft pricing pages in November 2026.

Is Dynamics AX Still Supported in 2026?

No. Every AX release is past the end of extended support. AX 2009, AX 2012 and AX 2012 R2 lost support in April 2022, and AX 2012 R3 lost it on January 10, 2023. No security fixes, no regulatory updates, no hotfixes.

Dates come from Microsoft’s lifecycle pages for Dynamics AX 2012 R3 and Dynamics AX 2009, which note that both end dates were pushed out once. Ignore any partner blog that says AX support ends in 2026. We found one. Microsoft’s own page says otherwise.

Why care if it still posts invoices? Three reasons. The Windows Server and SQL Server versions AX 2012 was certified on are aging out too. Tax updates stopped. And the consultants who know AX 2012 well are drifting into retirement or into Dynamics 365 work, which raises your support costs every single year you wait and makes every emergency fix slower to staff.

Which AX Versions Can Upgrade to Dynamics 365 Finance?

Only AX 2012 R2 and R3. Microsoft supports a code and data upgrade from those two releases to the cloud, after you apply the latest cumulative update. AX 2012 RTM can’t upgrade to the cloud, and AX 2009 is limited to a data migration tool.

The AX 2012 upgrade overview on Microsoft Learn, revised in March 2026, spells out the limits. R2 and R3 only. Systems running certain deprecated features can’t be upgraded at all, and the two examples Microsoft names are virtual companies and data partitions. Not sure? Run the analyzer. Microsoft also warns that the tools are a framework rather than a finished product, and that some data cleanup, tuning and customization work should always be expected.

AX 2009 is a different conversation. Microsoft’s page on the AX 2009 data migration tool calls it the only supported upgrade path from AX 2009. It maps AX 2009 tables to Dynamics 365 data entities and lets you pick legal entities, dimensions and a chart of accounts per company. Data only. No code. Some partners suggest a stop at AX 2012 R3 first. That’s two projects on a dead platform. We’d rarely recommend it.

Which leaves RTM. The cloud path doesn’t take it. Treat it as a reimplementation.

How Does an AX 2012 Upgrade Actually Work?

In three phases Microsoft calls Analyze, Execute and Validate. You estimate code and data effort with Microsoft’s tools, refactor overlayered code into extensions, upgrade the database in a development environment and then a sandbox, rehearse cutover, and copy the upgraded sandbox database to production.

Analyze

Analyze can happen before you buy anything. Two tools do the heavy lifting.

• The upgrade analysis report, a SQL script you run against the AX 2012 business database. It flags deprecated features, settings to fix, SQL tuning, and data you can clean up to shrink the database.
• The code upgrade service in Lifecycle Services, which takes a model store export and converts it.
• A demo environment with standard data, for a quick fit gap on processes that changed.
• The preupgrade checklist, installed in AX 2012.

Size matters twice. Microsoft notes that part of your subscription cost is based on database size, so purging old data before the upgrade cuts both the go-live window and the monthly bill you’ll be paying for as long as you run Dynamics 365.

Code upgrade and the end of overlayering

This part sets the budget. AX 2012 customizations were mostly overlayering. A partner edited Microsoft’s own objects in a higher layer. Dynamics 365 forbids it. Microsoft’s guide to the Lifecycle Services code upgrade service says version 8.0 and newer doesn’t allow overlayering of Microsoft models, so every customization has to be refactored into an extension.

That service reads your AX 2012 R3 model store, writes upgraded code into a new branch of an Azure DevOps TFVC repository, and reports the conflicts a developer must resolve. Check Estimation Only and you get just the report. Do that first. It’s your most objective estimate.

Developers can relax the overlayering rule while they work, but the guide to refactoring overlayering into extensions says that only works in development and demo environments. Never in a sandbox. Never in production. Some customizations can’t become extensions at all. Those go to an extensibility request, a redesign, or the bin.

Data upgrade

Data goes through twice. First, a backup of the AX 2012 database is restored into a development environment and upgraded there, because a developer can debug, fix code and rerun in minutes. Then a sandbox. Microsoft’s guide to data upgrade in self-service environments covers the sandbox step, where a Data Migration Toolkit replicates AX 2012 into Azure SQL using SQL Server transactional replication and then triggers the upgrade.

A few rules from that page catch teams out.

• The data upgrade runs only in a sandbox, Tier 2 or higher. Never directly in production.
• Unified developer environments aren’t supported for the upgrade. Use a cloud-hosted environment or a local VHD.
• Replication needs SQL Server and Windows authentication mode, a sysadmin SQL login, and SQL Server Agent running on the source.
• Snapshot and distribution paths need free disk at least the size of the source database, more if you compressed it.
• Don’t deploy the linked Power Platform environment until the data upgrade is done.

Go-live then follows the AX 2012 cutover process. Replication starts the weekend before. AX goes off. Replication finishes, the upgrade runs in the sandbox, and a database refresh copies the result into production. Smoke tests. Then users. Production deployment takes roughly 24 hours after you request it, and the request needs the subscription estimator and the methodology’s test phase completed first. Plan that day in.

Then attachments. AX 2012 kept documents in file shares, the database or SharePoint, and they only come across if they’re moved into the AX database before the upgrade. Slow step. Test it.

Is Lifecycle Services Going Away for AX Upgrades?

Not for AX upgrades, yet. Microsoft froze new Lifecycle Services implementation projects for new Finance, Supply Chain Management and Project Operations customers on February 16, 2026, but AX 2012 upgrade projects are explicitly exempt. The Power Platform admin center is where everything else is heading.

The Lifecycle Services project creation freeze page, updated in September 2026, lists who isn’t affected. Existing customers. Commerce. On-premises. Tenant-to-tenant moves. And AX 2012 upgrade projects. Every AX upgrade step on Learn still runs through Lifecycle Services, from the code upgrade tile to the toolkit download.

Odd split. New customers provision Finance environments in the Power Platform admin center, where environments are capacity-based instead of slot-based and the old all-in-one developer VMs are gone. AX upgrades still start in Lifecycle Services. Existing Lifecycle Services customers can move eligible environments to the admin center through a self-service migration, in public preview since September 2026. One way. Per environment. Third-party roadmap trackers point to general availability in December 2026, but we haven’t seen that date on Microsoft Learn.

Our advice is simple. Upgrade in Lifecycle Services because that’s where the tooling lives, go live, stabilize, and then plan the move to the admin center as its own small project a few months later. Don’t stack both changes on cutover weekend.

Should You Upgrade or Reimplement?

Upgrade when you’re on AX 2012 R2 or R3, the business still runs roughly the way AX was configured, and the code upgrade report shows a manageable conflict list. Reimplement when you’re on AX 2009 or RTM, when customizations are heavy and mostly obsolete, or when the chart of accounts and processes need a redesign anyway.

Microsoft’s AIM assessment, a partner-delivered review for qualifying on-premises customers, frames the choice as lift and shift, hybrid, or reimplementation. Right three options. Here’s how we pick, labeled as ZapAI practice rather than Microsoft guidance.

Three tests settle most close calls. First, read the Estimation Only report and count conflicts in core posting and inventory classes, not cosmetic ones. Second, ask whether finance would design the chart of accounts and dimensions the same way today. Third, ask how much transaction history auditors and analysts truly need inside the live ERP, versus in a read-only archive or a Fabric lakehouse.

History is the upgrade’s best argument. The data upgrade can bring your full transactional history forward. A reimplementation won’t. But if the honest answer to question two is “no, we’d change everything,” then keeping 15 years of history inside a chart of accounts and dimension structure you’re about to abandon buys very little, and an archive does the job for less.

Is Business Central a Better Fit for Smaller AX Shops?

Sometimes. A small AX customer with one or two companies, simple manufacturing or distribution, and fewer than 20 people who need full finance access can be a good fit for Business Central. But no Microsoft tool moves AX to Business Central, so it’s always a reimplementation.

Learn’s page on migrating on-premises data to Business Central online lists the supported sources. Business Central on-premises, Dynamics NAV through Business Central on-premises, Dynamics GP 2015 and later, Dynamics SL 2015 and later, and any other SQL source using custom migrations. AX isn’t listed. Custom migration it is.

Why 20 seats? Microsoft’s October 2026 Licensing Deck sets a 20-seat minimum for Finance, as our Dynamics 365 Finance licensing guide details. A 12-user AX shop moving to Finance still pays for 20. That’s usually the moment the CFO asks about Business Central.

Signals that point to Business Central.

• One country, a handful of legal entities
• Discrete manufacturing without advanced planning or process batches
• Warehousing that doesn’t need wave picking or mobile warehouse flows at scale
• An AX system that was always more ERP than you used

Signals that point to Finance and Supply Chain Management.

• Several countries, currencies and consolidation layers
• Process or mixed-mode manufacturing, or advanced warehouse management
• Intercompany trade at volume
• AX customizations that encode real competitive process

Our Business Central vs Dynamics 365 Finance comparison walks through the full trade-off, and the guide to Dynamics 365 for manufacturing compares Business Central Premium with Supply Chain Management for plants. Read it if you make things. Moving down a tier and discovering in month four that Business Central can’t handle your formula batches, your co-products or your quality orders is the expensive version of this decision, and it’s hard to undo.

What Does Dynamics 365 Finance Licensing Cost After AX?

Dynamics 365 Finance lists at $210 per user per month and Finance Premium at $300, billed annually. Supply Chain Management is the same, $210 and $300. A second app attaches to a Finance base for $30, and Finance carries a 20-seat minimum.

Prices come from Microsoft’s Dynamics 365 Finance pricing page and the matching Supply Chain Management page, both checked in November 2026. Premium editions include 1,000 Copilot Credits per user per month. The attach price and the minimums of 20 seats for Finance and 10 for Finance Premium come from Microsoft’s October 2026 Licensing Deck.

Price isn’t the real shift. The model is. AX was a perpetual license plus an annual enhancement plan. Dynamics 365 is a subscription, and the license each user needs is set by the security roles they hold, which Microsoft now enforces. Upgraded AX roles can quietly push approvers and warehouse staff into full licenses. Map roles before you sign.

Capacity counts too. Finance includes one production and one Tier 2 sandbox, but an AX upgrade wants more, one for the upgrade itself and one for testing. Price them early.

What Happens to Integrations, ISVs and Dataverse?

All three need their own workstream. Integrations get rebuilt against Dynamics 365 interfaces, ISV products need a Dynamics 365 version from the vendor, and dual-write or virtual tables to Dataverse come after the data upgrade, never during it.

Start with ISVs. An AX 2012 install at a mid-market manufacturer usually carries a few third-party products for EDI, sales tax, quality, shop floor or document capture, and each vendor either ships a Dynamics 365 version, has been acquired by someone who does, or has quietly stopped. The code upgrade tool converts your code, not theirs. Get written answers in month one.

Integrations next. We see AX 2012 sites with years of custom services, file drops and direct SQL reads feeding warehouse systems, e-commerce and BI. Production has no direct SQL. Each integration gets redesigned around data entities, business events or Dataverse.

Then Dataverse. Dual-write gives tightly coupled, bidirectional sync between Finance and Dataverse, which matters if you run Dynamics 365 Sales or Field Service. Virtual tables let Power Apps read Finance data without copying it. Our dual-write vs virtual tables guide covers which to pick. The timing rule from Microsoft is the part people miss. The linked Power Platform environment stays off until the AX data upgrade finishes, so design for Dataverse, but switch it on after cutover.

What About SSRS Reports, Management Reporter and Power BI?

SSRS survives. Finance still runs SSRS-based document reports for invoices, checks and packing slips, so AX report layouts can be upgraded. Management Reporter statements move to Financial reporting. Analytics moves to Power BI and Microsoft Fabric.

Document Reporting Services, per Microsoft, are based on SQL Server Reporting Services and hosted in Azure, with no report server to administer. Custom AX reports come across through the code upgrade. Each still needs a test. Statements built in Management Reporter get rebuilt in Financial reporting, whose Report Designer uses row, column and reporting tree building blocks that MR users will recognize.

Analytics is where the upgrade pays off. Old AX sites fed warehouses through nightly SQL jobs. Not anymore. Microsoft’s guide to linking Dataverse to Microsoft Fabric says Link to Fabric covers all Dynamics 365 apps, finance and operations included, without your own storage or ETL. Azure Synapse Link is the alternative if you want data in your own lake, and Microsoft points Export to Data Lake users there. Our Dataverse Link to Fabric guide compares the routes. Plan it early. Archived AX history can live there too.

How Long Does an AX Upgrade Take, and What Drives Cost?

It depends on code more than anything else. In our practice, a clean AX 2012 R3 technical upgrade is the shortest route, a hybrid adds months of refactoring and testing, and a reimplementation runs like a new Finance project. We don’t quote durations without seeing the code upgrade report.

Deliberately. Published AX timelines vary wildly and rarely state their assumptions. Here are the drivers instead.

• Conflicts in the code upgrade report, weighted by where they sit
• Number of ISV products and their Dynamics 365 readiness
• Integration count, especially anything reading AX SQL directly
• Database size and how much cleanup finance will approve
• Attachment volume and location
• Reports and statements to rebuild or retest
• Downtime the business will accept at cutover
• Legal entities, countries and intercompany setup

Downtime deserves a word. The cutover window is the time between turning off AX and letting users into Dynamics 365, and replication, upgrade scripts and the production copy all have to fit inside it, together with functional setup tasks someone must perform and verify. A distributor might accept a weekend. A three-shift plant might not. That limit drives cleanup and tuning.

For budget ranges by project size, our Dynamics 365 implementation cost guide breaks out services, licenses and the contingency we’d hold back. Ask whether an AIM assessment or migration offer applies before signing.

Where Do AX Upgrades Go Wrong?

Mostly in five places. Treating the upgrade as purely technical, skipping database cleanup, finding ISV gaps late, rebuilding integrations last, and running too few mock cutovers. Each one shows up on cutover weekend.

Technical-only thinking is the big one. An upgrade can carry every process forward unchanged, workarounds included. New screens, old pain. Spend a few workshops on the processes that hurt most, and change those on purpose.

Skipped cleanup costs twice. Bigger databases replicate and upgrade slower, so cutover stretches, and the subscription grows with size. Purge what the analyzer flags.

Late ISV answers stall testing. So does the undocumented integration, like the nightly job that sends shipments to a 3PL or prices to the web store and that nobody remembers until orders stop flowing on the Monday after go-live. Inventory every interface before code work starts.

Mock cutovers are cheap insurance. Microsoft requires at least one successful run. We plan for more. The first always finds something.

Finally, partner fit. AX upgrade skills get rarer every year. If your current partner has stalled on the analysis phase, our guide to switching your Dynamics 365 partner covers how to change without losing momentum.

What Should Be on Your AX Upgrade Checklist?

Decide the path, prove it with Microsoft’s tools, then execute with repeated rehearsals. Here’s the short version we hand a CFO and an IT lead on day one.

Decide

• Confirm the exact AX version and cumulative update.
• Run the upgrade analysis report.
• Run the code upgrade service with Estimation Only.
• Check for virtual companies and data partitions.
• List every ISV product with a vendor answer.
• Choose upgrade, hybrid or reimplementation in writing.
• Count full finance users against the 20-seat minimum.

Prepare

• Apply the latest AX 2012 cumulative update.
• Clean and compress the database.
• Move attachments into the database.
• Collect Microsoft Entra sign-ins for every AX user.
• Map AX security roles to Dynamics 365 licenses.
• Freeze AX code changes once code upgrade starts.

Execute and validate

• Data upgrade in development, then a Tier 2 or higher sandbox
• Full functional test pass, repeated after fixes
• Integrations and reports retested against upgraded data
• Mock cutover timed against the downtime limit
• Configuration freeze one week before go-live
• Dual-write or Link to Fabric switched on after cutover

After go-live, Finance takes four service updates a year and you must take at least two, which our guide to Dynamics 365 release wave changes explains. New rhythm for AX teams. Budget regression testing from week one.

What Could Change After Ignite 2026?

Maybe the tooling. Ignite runs November 17 to 20, 2026, in San Francisco. We’ll watch for general availability of the Lifecycle Services to admin center migration, any change to AX upgrade support in unified environments, and licensing moves. Expect a refresh by late November.

Wrapping Up

AX is out of support across the board. AX 2012 R2 and R3 customers have a real upgrade path with code conversion and full history, as long as they refactor overlayering into extensions and rehearse cutover. AX 2009 and RTM customers reimplement. Smaller shops should price Business Central first. In every case the decision comes down to what your code upgrade report says, how much history you truly need, and which processes are worth carrying into a system you’ll run for the next decade.

ZapAI is a Microsoft Dynamics 365, Power Platform, Fabric and AI consulting firm in Irving, Texas, working with businesses across Dallas-Fort Worth and nationwide. Our Dynamics 365 Finance consultants run AX upgrade assessments, code refactoring, data upgrades and cutover planning, and our Dynamics 365 consulting team covers Business Central and Dataverse when the right answer is a different product. If you’re a plant, our manufacturing practice knows the shop floor side. Talk to us about your AX upgrade, and we’ll read your analyzer and code upgrade reports with you before you pick a path.

Questions Teams Ask About Leaving AX

When did Dynamics AX 2012 R3 support end?

Can AX 2009 upgrade directly to Dynamics 365 Finance?

Do we keep our transaction history in an AX 2012 upgrade?

Will our AX customizations work in Dynamics 365?

Do AX upgrades still use Lifecycle Services?

Can we move from AX to Business Central instead?

Do SSRS reports from AX carry over?