Dynamics AX to Dynamics 365 Migration: A Practical Guide

Many mid-sized and large US companies still close their books, plan production and ship orders on Dynamics AX 2009 or AX 2012. The system is familiar and the custom code fits the business, so replacing it feels risky. Meanwhile Microsoft support has ended, the servers underneath are aging, and the people who understand the customizations get harder to find every year.

This guide covers why moving now makes sense, the two main migration paths and how to choose between them, and how to handle customizations, data, integrations and reports. It ends with a phased checklist and the mistakes that most often slow these projects down. It is written for finance, operations and IT leaders who want a clear picture before any partner conversation.

Why move off Dynamics AX now

Dynamics AX was Microsoft's ERP for larger and more complex organizations. Its successor is Dynamics 365 Finance and Operations apps, the family that includes Dynamics 365 Finance, Supply Chain Management, Commerce, Human Resources and Project Operations on one shared platform.

Support has ended

Every version of AX is now past the end of Microsoft extended support. AX 2012 R3, the last release, reached that point in January 2023. Microsoft no longer ships security fixes, bug fixes or regulatory updates for any of them. Microsoft's product lifecycle pages list the exact date for your release.

Infrastructure and security

AX was certified for particular Windows Server and SQL Server releases, and many of those are at or near the end of their own support. Moving AX onto newer infrastructure is often unsupported. Auditors and insurers now ask which systems are out of support, and an unpatched ERP holding your general ledger is a hard answer to give.

Integrations keep getting harder

Banks, EDI providers, e-commerce platforms and SaaS tools expect modern APIs. Many AX integrations rely on the Application Integration Framework, the .NET Business Connector, file drops or direct database access, and each new connection costs more and breaks more easily.

Cloud operations, updates and Copilot

Finance and Operations apps run as a Microsoft-managed cloud service with continuous updates, called One Version: several service updates a year, with some control over timing. Copilot features are also being added across the apps. Availability varies by app and region and changes often, so check Microsoft's current release plans.

Two main paths, plus a hybrid

Upgrade from AX 2012

Microsoft supports a code and data upgrade path from specific AX 2012 versions. The code upgrade moves your customizations into the new extension model. The data upgrade transforms your AX 2012 database into the Finance and Operations schema, so transaction history comes with it. Upgrade work has traditionally run through Lifecycle Services, and Microsoft has been moving environment management toward the Power Platform admin center. Prerequisites and tooling change, so confirm current requirements in Microsoft's upgrade documentation.

This path suits companies on a supported AX 2012 release whose processes still fit, whose customizations are reasonably well built, and who want full history in the new system.

Re-implementation with selected data

Here you configure Finance and Operations apps fresh, run a fit-gap against current standard features, and load master data, open balances and a chosen slice of history. AX 2009 and AX 4.0 customers generally take this path because no direct upgrade exists from those versions. It also suits AX 2012 companies with heavy customization, poor data quality or a business reshaped by acquisitions or new legal entities.

Hybrid approaches

Some companies upgrade first to get off unsupported infrastructure, then redesign processes in later phases. Others re-implement and move older history into a reporting store. For example, a manufacturer with two plants in different states might upgrade to keep production and cost history, then replace a set of custom planning modifications with standard features in a second release.

If other aging systems sit around AX, our guide to legacy system modernization covers the broader rewrite, refactor or replace choice.

Which Dynamics 365 product is the destination

Most AX customers move to Finance and Operations apps because they run many legal entities, multiple currencies, complex manufacturing or distribution, or high volumes. Some smaller AX customers may fit Business Central, Microsoft's ERP for small and mid-sized businesses. No fixed size threshold applies; fit depends on complexity. Note that the AX code and data upgrade path leads to Finance and Operations apps, so choosing Business Central generally means a re-implementation. Our comparison of Finance and Operations apps vs Business Central walks through the decision.

What to do with your customizations

AX 2012 let developers change Microsoft's standard code directly in layers, a practice called overlayering. Finance and Operations apps in the cloud do not support overlayering. Customizations are written in X++ and delivered as extensions that add to standard behavior without editing it.

Start with an inventory: every modified object by layer, what it does, who still uses it and whether documentation exists. Then sort each item into one of five outcomes:

• Retire it. Reports nobody runs should not be rebuilt.
• Replace it with standard. Microsoft has added a great deal since AX 2012, so test the current product before assuming a gap remains.
• Replace it with configuration or Power Platform. Approvals, simple data capture apps and many document formats can be handled with workflow, Power Apps, Power Automate or Electronic reporting.
• Rebuild it as an X++ extension. Keep custom code for logic that sets your business apart or that standard features cannot cover.
• Use an ISV solution. Ask each add-on vendor about its Dynamics 365 version, support terms and how it keeps pace with Microsoft's updates.

Every extension you keep must be tested against each service update, so fewer extensions means less regression work for years.

Data migration and history

Give data migration a named owner on the business side and a plan of its own. Data moves into Finance and Operations apps through data entities and the Data management framework, whichever path you choose.

Decide early what goes into the new system:

• Master data: customers, vendors, products, bills of materials, routes, warehouses and locations
• Open transactions: open receivables and payables, open sales and purchase orders, on-hand inventory
• Balances: general ledger balances by period for the years you need to compare
• Detailed history: usually a limited window, or none at all in a re-implementation

Then decide where everything else lives: a read-only archive database, a time-limited read-only AX environment isolated from the network, or a data warehouse that joins AX history with new data so reports work across the cutover date. Keeping AX running for years carries security and hosting cost, so set an end date. Ask your auditor and tax advisor how long records must be kept and in what form.

For example, a distributor with three warehouses might load its item master, on-hand quantities by location, open orders and two years of monthly ledger balances, while ten years of sales history goes to the warehouse for trend analysis.

Integrations and reports

List every integration with its direction, frequency, volume and technology. In Finance and Operations apps, integrations use data entities, OData and other APIs, or middleware. Direct writes to the production database are not part of the cloud model, so file drops and SQL-based links usually need redesign. If you run Dynamics 365 Sales or Customer Service, dual-write can keep shared data such as customers and products in sync with Dataverse in near real time.

AX environments often carry hundreds of SSRS reports and Excel extracts. Finance and Operations apps still use SSRS for many business documents, Electronic reporting covers many regulatory and document formats, and analytics typically move to Power BI. Review each report's usage and owner, then decide its future.

Testing and cutover

Test in layers. Developers test each extension. Process owners run end-to-end scenarios such as order to cash, procure to pay, plan to produce and record to report. Integrations are tested with realistic volumes, security roles with real job profiles, and staff who do the work daily run user acceptance testing.

Cutover needs rehearsal. A data upgrade or large migration load can take many hours, and you only learn how many by running it. Plan at least two timed mock cutovers, write an hour-by-hour runbook, and pick a go-live date near a period end, away from peak season. Staff hypercare through the first month-end close.

A phased migration checklist

The phases below follow Microsoft's Success by Design stages: Initiate, Implement, Prepare and Operate.

Initiate: assess and decide

• Confirm your AX version, release and update level
• List modified objects by layer, with owners and usage
• List ISV add-ons and check each vendor's Dynamics 365 plans
• Map every integration and the technology it uses
• Measure database size and years of history
• Choose upgrade, re-implementation or hybrid, and record why
• Confirm current licensing requirements and costs with Microsoft or a partner

Implement: design and build

• Run a fit-gap against current standard features
• Classify each customization: retire, standard, configuration, extension or ISV
• Redesign integrations on data entities and APIs
• Decide each report's future: SSRS, Electronic reporting, Power BI or retire
• Set history rules and the archive approach
• Run the first trial migration or data upgrade and reconcile it

Prepare: test, train and rehearse

• Complete end-to-end process tests and user acceptance testing
• Run performance tests with realistic data volumes
• Hold at least two timed mock cutovers
• Train users by role on their own data
• Agree go or no-go criteria

Operate: go live and stabilize

• Run the final migration and get finance sign-off on reconciliations
• Triage issues daily during hypercare
• Set a regression testing routine for service updates
• Retire AX or move it to a read-only archive on a fixed date

Common mistakes

• Treating it as a technical upgrade only. Even the upgrade path changes how code is maintained and how updates arrive.
• Converting every customization. Much AX custom code filled gaps that standard features now cover.
• Keeping AX alive indefinitely. An unsupported server holding financial data is a risk that grows each year.
• Skipping mock cutovers. Load times and reconciliation gaps surface either in rehearsal or at go-live.
• Ignoring the update cadence. Extensions and ISV solutions need testing with each service update.
• Losing the AX experts. Your long-time power users know why things work the way they do. Put them on the project team.

Next steps

Begin by documenting your AX environment: version and update level, customizations by layer, integrations, reports and data volume. With those facts on paper, the choice between upgrade and re-implementation usually becomes clearer, and partner proposals become easier to compare.

If you would like a second view on your options, talk to our team. We can review your inventory with you and help you plan the next step.