Upgrade Dynamics AX 2012 and AX 2009 to Finance and Operations

What changes when you move from Dynamics AX to finance and operations apps?

The support 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. A system on either version still posts invoices, but it does so without Microsoft fixes, and every year the gap between it and current Windows, SQL Server and browser versions gets wider. The full picture of what end of life means across Dynamics products, and the options beside an upgrade, is on our page on Dynamics 365 and Dynamics on-premises end of life.

The destination is finance and operations apps, Microsoft's name for Dynamics 365 Finance, Dynamics 365 Supply Chain Management, Dynamics 365 Commerce and Human Resources capabilities within finance and operations apps. Functionally it will feel familiar to an AX team: legal entities, the general ledger, inventory, production and warehouse all have recognisable descendants. Technically it is a different world. Development is done in X++ with the Visual Studio extension, customisations live in extensions instead of modified standard code, and Power Platform developer tools sit alongside the finance and operations tools in one unified developer experience. That last point is why an upgrade is a project with a plan, not a weekend with a backup.

How does the upgrade run through Analyze, Execute and Validate?

Microsoft splits the AX 2012 upgrade into three phases, and we run the project the same way so the plan, the evidence and the Microsoft documentation all use the same vocabulary. The phases are sequential for the first pass and repeat for every rehearsal: nobody upgrades a production AX database for the first time on the go-live weekend.

Before the first phase we run a short discovery: which legal entities and modules are actually used, which reports the finance team cannot live without, which integrations run at night, and who owns each of them. The output of discovery is a scope everyone has signed, which is cheaper than finding the forgotten interface to the bank in week twenty.

• Analyze: inventory the AX code by layer and model, compare it with standard, measure the database and the history it carries, and decide per customisation and per data area what moves, what is replaced by standard features and what is retired.
• Execute: rebuild the kept customisations as X++ extensions, run the data upgrade in a sandbox environment, reconnect integrations and reporting, and repeat the upgrade until it runs cleanly and inside the cutover window.
• Validate: reconcile trial balances, open receivables and payables, stock quantities and values against AX, run user acceptance testing on real scenarios, rehearse cutover, and only then schedule go-live.
• Plan for a fresh start: if your plan is a new implementation rather than an upgrade, new cloud implementation projects for Finance, Supply Chain Management and Project Operations are created in the Power Platform admin center since 16 February 2026.

What happens to the customisations built up in AX?

In AX, customisation usually meant changing standard code in a higher layer. In finance and operations apps that code is rebuilt as extensions: event handlers, table and form extensions, and chain of command wrappers around standard methods. The practical consequence is that every overlayered change gets a decision instead of a copy. In an older system, a fair share of the customisations usually turn out to be covered by standard features, workarounds for problems that no longer exist, or reports nobody opens.

We classify each customisation into one of three buckets: rebuild as an X++ extension, replace with standard configuration, or retire with the business owner's sign-off. The rebuilds go into source control with a build pipeline from the first day, so the upgraded system starts life with the release discipline many AX environments never had. The example below shows the shape of a chain of command extension that replaces an overlayered validation on the sales order header.

[ExtensionOf(tableStr(SalesTable))]
  final class SalesTable_SZ_Extension
  {
      public boolean validateWrite()
      {
          // run the standard validation first
          boolean ret = next validateWrite();

          // former overlayer logic: a contract reference is required for key account orders
          if (ret && this.SZ_IsKeyAccount() && !this.SZ_ContractRef)
          {
              ret = checkFailed("Enter a contract reference for key account orders.");
          }

          return ret;
      }

      private boolean SZ_IsKeyAccount()
      {
          return CustTable::find(this.CustAccount).SZ_KeyAccount;
      }
  }

How is AX data upgraded or migrated without losing history?

For AX 2012 R2 and R3 the documented path upgrades the database itself, so open transactions and history come across in the same structure the business already reports on. The work is in preparation and rehearsal: cleaning data that the upgrade scripts trip over, deciding how much history the new system really needs, and running the upgrade enough times in a sandbox that the go-live run is boring. We measure every rehearsal, so the cutover window is a number from evidence rather than a hope.

AX 2009 moves by a separate route: Microsoft provides a data migration tool for it rather than the AX 2012 code upgrade. That makes an AX 2009 project closer to a new implementation with a well-understood source. We agree with finance which data is migrated as open items, which as summarised history and which stays in an archive that auditors can still read. In both cases the validation is the same: trial balances, open customer and vendor balances, fixed asset values and stock quantities reconcile to AX before anyone signs.

What about integrations, reporting and Customer Engagement after the upgrade?

AX systems tend to be surrounded by integrations that grew up over a decade: file exchanges with banks and logistics providers, a web shop, EDI with large customers, and a CRM that someone keeps in sync with a nightly job. Each one is listed in analysis, assigned an owner and rebuilt on supported integration patterns for finance and operations apps. Reports are triaged the same way as code: rebuilt, replaced by standard reporting, or retired.

The upgrade is also the moment to fix the CRM link properly. Dual-write is an out-of-box infrastructure that provides near-real-time, bidirectional integration between customer engagement apps and finance and operations apps through Dataverse, so customers, products and orders mean the same thing in Dynamics 365 Sales and in the ERP. Where a CRM user only needs to see ERP data, finance and operations apps also act as a virtual data source in Dataverse, exposing entities as virtual tables without copying the data. Solzet designs both sides, because we also build the Dynamics 365 Customer Engagement side. The detail is on our CRM and ERP integration page.

Who is this for, and who is it not for?

This service is for organizations on Dynamics AX 2012 or AX 2009 with several legal entities, real supply chain or production processes, or retail operations, that want to stay in the Microsoft ERP family and move to a supported cloud platform. It suits IT and finance leaders who need a plan they can defend to a board, and Microsoft partners who need X++ capacity for an upgrade they already own, which Solzet delivers white-label through our subcontracting service.

It is the wrong starting point if your AX use has shrunk to standard finance, purchasing and inventory in one or two companies. Business Central fits small and mid-sized companies that want finance, inventory, projects and light manufacturing in one cloud system, and moving there can be simpler than an upgrade. Solzet implements Dynamics 365 Business Central too, so the recommendation follows your processes, not our preference. The parent page on Finance and Operations compares the two in more depth.

How does Solzet work on an AX upgrade, and what do you receive?

One team owns the whole job: analysis, X++ development, data upgrade, integrations, testing, cutover and support after go-live. Senior consultants run the process and finance workstreams, developers rebuild code and integrations, and the same people stay for hypercare, so nobody has to re-explain the system to a support desk. If you have already started an upgrade with someone else and it has stalled, we can audit the existing project and give you a stabilisation plan through our Dynamics 365 health check and technical audit.

• An analysis report: AX code inventory by layer and model, each customisation classified as rebuild, replace with standard or retire, and the database and history assessment.
• A phased upgrade plan with rehearsal dates, a measured cutover window and named owners for every integration and report.
• X++ extensions in source control with a build pipeline, and documentation for every rebuilt customisation.
• A data upgrade or migration plan, with reconciliation reports for trial balances, open items, fixed assets and stock.
• Integrations rebuilt on supported patterns, including dual-write or virtual tables to Dynamics 365 Customer Engagement where you need them.
• A rehearsed cutover runbook, hypercare after go-live and an agreed support model afterwards.