A Dynamics AX migration typically takes between 12 and 24 months for a mid-to-large enterprise, though smaller, less complex organisations can complete the process in 9 to 12 months. The biggest variable is not the technology itself but the state of your data, the complexity of your business processes, and how well your organisation is prepared before the project begins. The sections below break down what drives that timeline and where projects most commonly lose time.
What factors determine how long a Dynamics AX migration takes?
The length of a Dynamics AX migration depends on four main factors: the size and complexity of your organisation, the volume and quality of your data, the number of integrations and customisations in your current system, and your internal capacity to support the project alongside day-to-day operations. No two migrations run on the same clock.
Organisations with a single business unit, clean master data, and few custom developments can move considerably faster than multinationals running multiple legal entities across different countries. The more your current Dynamics AX environment has been customised over the years, the more time you will need to assess which customisations to rebuild, replace with standard functionality, or retire entirely.
Internal readiness also plays a larger role than most organisations expect. If your business process owners are not available to make decisions, if your data has not been cleansed, or if your IT team is stretched across other priorities, the project will slow down regardless of how experienced your implementation partner is. A business transformation assessment before you start can surface these blockers early and give you a realistic picture of where you actually stand.
What are the main phases of a Dynamics AX migration project?
A Dynamics AX migration project typically moves through five phases: discovery and design, build and configuration, testing, cutover preparation, and go-live with hypercare. Each phase has its own duration, dependencies, and risks, and delays in one phase almost always ripple forward into the next.
- Discovery and design (4 to 8 weeks): Mapping your current processes (As-Is) and defining your future state (To-Be), identifying gaps, and agreeing on scope.
- Build and configuration (3 to 6 months): Configuring the new system, developing integrations, and migrating data structures.
- Testing (6 to 12 weeks): Unit testing, integration testing, user acceptance testing, and performance testing to confirm the system is ready for production.
- Cutover preparation (4 to 8 weeks): Finalising the cutover plan, running mock cutovers, and preparing the organisation for go-live.
- Go-live and hypercare (4 to 8 weeks post-launch): Stabilising the system, resolving issues quickly, and supporting end users through the transition.
The testing and cutover phases are frequently underestimated. Organisations that treat testing as a formality rather than a structured quality gate tend to find their most serious problems after go-live, which is the most expensive place to find them.
How long does data migration typically take in a Dynamics AX project?
Data migration in a Dynamics AX project usually runs in parallel with the build phase and takes between three and six months of active work. However, data preparation, which includes cleansing, deduplication, and mapping, often starts weeks before the formal project begins and continues right up to cutover.
The actual duration depends on how much data you are migrating, how many source systems you are pulling from, and the quality of that data today. Legacy Dynamics AX environments that have been running for ten or more years frequently carry years of inconsistent records, outdated master data, and orphaned entries that need to be resolved before they can be moved into a new system.
Rigorous As-Is/To-Be analysis of your current data structures is not optional. It is the foundation that determines how many migration cycles you will need and how confident you can be in the data on day one. Testing procedures at each migration cycle, rather than only at the end, prevent errors from compounding and protect data integrity throughout the process. You can explore how we approach this through our full range of services.
What’s the difference between a Dynamics AX upgrade and a full migration?
A Dynamics AX upgrade moves you to a newer version of the same platform, typically from AX 2009 or AX 2012 to Dynamics 365 Finance and Operations, while preserving as much of your existing configuration and data as possible. A full migration involves moving to an entirely different ERP platform or rebuilding your Dynamics environment from the ground up using a greenfield approach.
Upgrades are generally faster because you are working within a known system architecture. Microsoft provides tooling and upgrade paths that reduce the amount of custom development required. That said, an upgrade is not simply a technical lift. Business processes that worked in AX 2012 may need to be redesigned for Dynamics 365, and integrations built for the old platform often need to be rebuilt entirely.
A full migration takes longer because you are making more decisions from scratch. Greenfield projects give you the opportunity to clean up years of technical debt and align your system with how the business actually operates today, but they require more design work, more testing, and more change management to bring your organisation along. Brownfield migrations, which carry over existing data and configurations into a new environment, sit somewhere in between and carry their own set of risks around what you choose to bring forward.
What can cause a Dynamics AX migration to run over schedule?
The most common causes of Dynamics AX migrations running over schedule are poor data quality discovered late, scope creep driven by undecided business requirements, insufficient testing time, and low user adoption that forces rework after go-live. Most of these are avoidable with the right preparation and governance in place.
Scope creep is particularly damaging. When business stakeholders continue requesting changes or additions after the design phase has closed, the project absorbs those changes at a much higher cost in both time and budget. Strong program governance, with clearly defined change control processes, is what keeps scope from expanding unchecked.
Cutover planning is another area where projects frequently lose time. Organisations that plan their cutover too late, or that run only one mock cutover before go-live, often discover timing issues or missing dependencies that push the launch date back. A well-structured cutover plan, built and tested well in advance, is what separates a smooth go-live from a chaotic one.
Change management is the factor that is most often underinvested and most often blamed after the fact. When end users are not prepared, when training happens too late, or when resistance is not addressed early, the business cannot operate effectively on the new system even if the technology works perfectly. That undermines the entire business case for the migration.
How Optinus helps with your Dynamics AX migration
We support organisations through every phase of a Dynamics AX migration, from the initial assessment through to post-go-live hypercare. Our consultants have hands-on experience with real ERP migrations at leading multinationals, which means we know where projects lose time and how to prevent it.
- Maturity assessment: We start by giving you a clear baseline of where your organisation actually stands before any budget or roadmap is committed.
- Data migration management: We run rigorous As-Is/To-Be analysis and structured testing cycles to protect your data integrity throughout the migration.
- Cutover management: We plan and manage your cutover end-to-end, including mock runs and real-time monitoring, so operational continuity is never at risk.
- Change management: We address both the technical and human side of the transformation, driving genuine adoption rather than just delivering training.
- Available on-site and remote: We work with organisations across the Netherlands, Belgium, and internationally, adapting to your team’s setup.
If you want to talk through your migration timeline or find out where your biggest risks are, get in touch with our team. You can also learn more about what we do and how we approach complex ERP transformations.
