The honest short answer: a single legal entity with moderate customisation typically moves from assessment to go-live in a few months. Heavily customised, multi-entity systems take longer and go live in phases. The useful answer is what each phase contains and what makes it longer or shorter, because that is what you can influence.
Phase 1: Assessment (weeks, not months)
Microsoft’s upgrade analysis tools run over the AX 2012 model store and the database. The output lists every customisation with its size and complexity, every integration, and every table with its row count. Reading that output with the people who know the business turns it into decisions: keep, drop or replace for each customisation. This phase is short and it sets the duration of everything else. Skipping it is how projects end up double their estimate.
What makes it longer: nobody in the business remembers why a customisation exists, so every one needs investigation.
Phase 2: Environment and plan
Dynamics 365 environments are provisioned, the plan is written with dates, and the target month-end for go-live is chosen. Decisions made here: which entities move first, whether the parallel run is one month-end or two, and how integrations change.
Phase 3: Code migration
This is the phase whose length varies most. Over-layered AX 2012 code cannot be carried over; surviving customisations are rebuilt as extensions. A handful of small customisations is a few weeks. Hundreds of objects touching posting routines is months. The assessment tells you which you have.
What makes it shorter: dropping customisations that standard Dynamics 365 already covers. In most AX 2012 systems, a meaningful share of the custom code falls into this group.
Phase 4: Data migration runs
Data migration is repeated, not done once. Each trial run loads master data, open transactions and historical balances, then produces reconciliation reports your finance team checks. Differences are fixed at source and the run is repeated. Three to four runs is normal. Each run gets faster as the issues are removed.
What makes it longer: deciding late how much history to bring. Decide in Phase 2.
Phase 5: Parallel testing
Process owners run the same month-end, purchase-to-pay and order-to-cash scenarios in AX 2012 and in Dynamics 365 side by side until the numbers agree. One full month-end cycle is the minimum; two gives more confidence for finance-heavy organisations.
Phase 6: Cutover and hypercare
Cutover is planned around the close calendar: freeze, final migration, checks, go-live. Hypercare continues through the first month-end on the new system, because that is when the real questions arrive.
The duration drivers, ranked
- Volume and depth of customisation, especially anything touching posting, inventory costing or pricing.
- Number of legal entities and countries, with their localisations.
- Integrations that have to be rebuilt rather than reconnected.
- Availability of your process owners for workshops and testing. This one is under your control and it matters more than people expect.
- How much history you migrate.
Two illustrative timelines
| Situation | Shape of the plan |
|---|---|
| One legal entity, finance and purchasing, around forty customised objects, two integrations | Assessment, then code and data streams in parallel, one parallel month-end, go-live after the following close. A matter of months from start to live. |
| Three legal entities in two countries, manufacturing and warehousing, several hundred customised objects, six integrations | Assessment, then a pilot entity taken through code migration, migration runs and two parallel month-ends; remaining entities follow in one or two further phases. Well over half a year, planned around two or three closes. |
Neither timeline is a promise for your system. Both show the same thing: the calendar is driven by customisation depth, entity count and how many month-ends you want to prove before you trust the new system.
Where projects lose time, and how to avoid it
- Deciding scope by committee during the build. Agree the keep, drop or replace list in the assessment and treat later changes as change requests.
- Process owners who are only available on Fridays. Block their workshop and testing time in the plan before the project starts, and get their managers to protect it.
- Integrations discovered late. The “small” EDI script that turns out to feed the top customer’s orders. The assessment must include a walk through every scheduled job and every file folder on the AX server.
- Migrating history nobody asked for. Decide the history scope with finance and the auditors in the planning phase.
- Testing against the configuration instead of the business. Scripts written from real month-end and order-to-cash scenarios find the problems that matter; scripts written from the setup screens do not.
How to read an estimate
When a partner gives you a single duration without an assessment, ask what it is based on. When they give you a range after an assessment, ask which of the five drivers above sits at the top of the range and what you can do about it. An honest estimate is a list of assumptions with dates attached, and it gets more precise at the end of each phase.
Want a dated plan instead of a range? See the upgrade service or book a consultation.
Frequently asked
Can we shorten the upgrade by skipping the parallel run?
You can, and some organisations with simple finance do. For anyone with inventory costing, intercompany or a strict audit, the parallel month-end is the cheapest insurance you will buy.
Should we upgrade everything at once or in phases?
Phasing by legal entity or business unit usually reduces risk and lets the team learn on a smaller scale. It needs a plan for intercompany transactions during the transition.
What does the assessment cost us in time?
Mainly a few workshop days from your process owners and IT. The tools themselves run in the background.