techone --guide=ax-to-fo
From Dynamics AX to Dynamics 365 Finance and Supply Chain Management
A supported cloud path exists for Dynamics AX 2012 R2 and R3, but Microsoft tooling provides a framework rather than a finished upgrade. The target apps, unsupported features, X++ customizations, data, integrations, and downtime requirements must be assessed first.
TL;DR
- The main decision
- Whether to use the supported database and code upgrade, or implement target processes again and move a selected scope of data.
- Supported versions
- Microsoft supports the direct cloud upgrade from Dynamics AX 2012 R2 and R3 after each source is updated to the latest available cumulative update.
- Target apps
- Finance typically moves to Dynamics 365 Finance, while manufacturing, warehousing, and logistics use Dynamics 365 Supply Chain Management. Other processes may require additional apps.
- Code and data
- The upgrade can bring forward transactional history and part of the X++ code. Overlayering, conflicts, unsupported features, and custom integrations require separate work and testing.
- What to prepare
- The exact release and cumulative update, model store, database size, companies, functions, customizations, integrations, reports, and downtime requirements.
Define the Target Apps and Scope First
Finance & Operations is still commonly used as a name for the target platform. Microsoft now uses finance and operations apps as the umbrella term for several separately licensed applications. Dynamics 365 Finance covers financial processes. Dynamics 365 Supply Chain Management covers manufacturing, planning, warehousing, and logistics.
Depending on the operation, the target solution may also include Dynamics 365 Commerce, Project Operations, or other apps and services. Scope therefore follows the processes, companies, countries, integration boundaries, and responsibilities that the new environment must support, rather than the historical Dynamics AX product name.
The ability to upgrade a database and code is a separate decision from target operations. Even on a supported path, each process must be assessed for retention, current standard functionality, or redesign. For an older or unsupported source release, a new implementation with controlled data migration can be more suitable than several technical steps.
Which Versions Have a Supported Cloud Path
Current Microsoft documentation supports the direct cloud upgrade only from Dynamics AX 2012 R2 and R3. Both sources must be on the latest available cumulative update. The exact release, build, and functions in use therefore need validation before estimating the project.
Dynamics AX 2012 R2
It is a supported cloud-upgrade source after applying the latest available cumulative update. Assessment still covers the database, code, functions in use, and required target apps.
Dynamics AX 2012 R3
It is the second supported source. Extended support ended on January 10, 2023, while the technical upgrade path remains documented by Microsoft.
Dynamics AX 2012 RTM and AX 2009
They are not sources for the same direct cloud upgrade. The project needs an earlier technical step or a new implementation with a separately designed data migration.
Support status
Extended support for Dynamics AX 2009 SP1, Dynamics AX 2012, and R2 ended on April 12, 2022. Dynamics AX 2012 R3 ended on January 10, 2023.
End of support increases dependency on the specific installation and partner. It does not by itself determine whether the route should be an upgrade, an earlier technical step, or a new implementation.
What the Technical Upgrade Retains and What Must Change
The upgrade tooling provides a framework for moving the database and application. It cannot automatically handle every variation accumulated in code, data, and processes. The result depends on preparing the source environment and deciding what should continue in the target solution.
Database and transactional history
The supported data upgrade can bring forward full transactional history. Database size, data quality, and attachment volume affect repeat runs, performance, cutover duration, and target-environment cost.
X++ code and extensions
Code Upgrade Service converts part of the code and creates work items for unresolved conflicts. Overlayering of Microsoft models must be refactored into extensions, and a developer must compile, adjust, and test the result.
Unsupported features
Virtual companies or data partitions can block the standard cloud path. Upgrade Analyzer should reveal these dependencies before a committed plan and budget are prepared.
Integrations, reports, and identities
Interfaces, batch jobs, SSRS reports, attachments, document outputs, and user accounts must be validated against the target architecture, Microsoft Entra ID, and available integration services.
A technically convertible function is not automatically right for target operations. Every material customization needs a decision: convert it, replace it with standard functionality, extend the platform, or change the process.
How Code, Data, and Testing Are Prepared
Analysis must produce concrete outputs for developers, consultants, and process owners. A module list is not sufficient. The project needs identified code conflicts, database condition, missing functions, integration dependencies, and scenarios that users will use to approve operations.
Upgrade Analyzer
It checks source settings, data size and cleanup opportunities, database configuration, and use of deprecated features. Findings become tasks, owners, and a sequence of preparation work.
Code Upgrade Service
It processes the model-store export, converts supported code, and creates conflicts in Azure DevOps. A developer uses the output to estimate work and then prepares functional code based on extensions.
Repeated data upgrade
The first run uses a development environment where issues can be corrected and the upgrade rerun. The same application release, code, and data package are then validated in a sandbox.
Functional and integration tests
Testing covers retained and new processes, financial balances, document relationships, batch jobs, reports, and integrations. Critical cases should include transactions that began before the upgrade.
Readiness is not established by one successful tooling run. It requires a repeatable upgrade, a complete functional test pass, and resolved deviations.
How the Project Runs
Microsoft describes Analyze, Execute, and Validate phases. For delivery management, we organize them into four steps with verifiable outputs.
Validate support and target scope
Confirm the exact release and cumulative update, functions in use, companies, countries, target apps, and operational dates. Define a new-implementation option for comparison.
Assess code, data, and integrations
Run Upgrade Analyzer, prepare the model store for Code Upgrade Service, and map the database, attachments, reports, interfaces, and conflicts that affect scope.
Prepare the solution and repeat upgrades
Refactor X++ into extensions, configure target processes, and repeat data upgrade in development and sandbox environments. Each run updates rules, code, and test evidence.
Validate mock cutover and go live
Users complete a full functional test pass, and the team approves reconciliations, performance, and integrations before a mock cutover. The final plan defines downtime, final transfer, ownership, and post-launch support.
Target Platform and Rollout Experience
For Tesil Fibres, we delivered the Czech workstream of a group Dynamics 365 Finance rollout during a move from Oracle E-Business Suite. The work covered Czech finance and VAT, migration data preparation, training, end-to-end testing, launch and hypercare.
We coordinated the Czech scope with the local and group implementation teams. A move from Dynamics AX requires the same discipline around data, localization, acceptance and ownership. The ERP process analysis prepares the decision brief, while our ERP integration service covers connected systems.
Frequently Asked Questions
Which Dynamics AX versions have a supported cloud upgrade?
Microsoft currently supports the cloud upgrade from Dynamics AX 2012 R2 and R3. Both sources must be on the latest available cumulative update. Dynamics AX 2012 RTM and Dynamics AX 2009 are not sources for the same direct cloud path.
What is the difference between technical upgrade and new implementation?
Technical upgrade brings forward the database, transactional history, and part of the custom code through supported tooling. A new implementation builds target processes and configuration again and moves data through separately designed mappings. The choice follows the source release, customizations, functions in use, data quality, and willingness to change processes.
What happens to our X++ customizations?
Code Upgrade Service converts supported parts and reports conflicts. A developer must remove overlayering dependencies, prepare extensions, resolve unsupported code, compile the result, and complete functional testing. Current standard functionality is assessed at the same time.
Does the complete data history migrate?
The supported data upgrade from Dynamics AX 2012 R2 or R3 can bring forward full transactional history. Practical scope is affected by database size and quality, attachments, performance, cutover duration, and audit requirements. A new implementation needs a separately designed live-history and archive scope.
What determines project scope, schedule, and cost?
The exact release and cumulative update, target apps, companies and countries, X++ conflicts, database size, unsupported features, integrations, test scenarios, and available cutover window. An estimate follows the first assessment of these areas.
Related Topics
Process Analysis Before ERP Implementation
How to turn current processes, data, roles, and exceptions into a target design and implementation brief.
ERP in Manufacturing
How to define manufacturing, planning, warehousing, data, and integrations in the target ERP.
ERP Integration
Connect ERP with CRM, WMS, e-commerce, banks, EDI, and other operational systems.
Microsoft Cloud Solution Provider
You handle the move to Dynamics 365 and the licensing with one partner. We go through your situation and take care of both.
Plan the Move from Dynamics AX.
In the initial conversation, we review the exact version, cumulative update, application scope, X++ customizations, database, and integrations. This defines the evidence needed to assess a supported upgrade and a new implementation.
Discuss the Move from Dynamics AX