Dynamics AX to Dynamics 365
Moving from Dynamics AX 2009, 2012 or R3 to Dynamics 365 Finance and Supply Chain Management is rarely a technical exercise. The cost and the risk are decided by what happens to your customisations, your history and your integrations. We work that out first, then build the plan around the answer.
UK Microsoft partner delivering AX migration assessments and Dynamics 365 implementations.
The upgrade decision
These are settled during an assessment, before anyone commits to a date. Getting them wrong is the usual reason an AX migration overruns.
AX 2012 R3 offers an upgrade path, but carrying twelve years of customisation into a cloud platform that updates twice a year is rarely the cheaper option. The right answer depends on how much of your code still earns its place.
Every modification gets one of three verdicts: replaced by standard capability, rebuilt as an extension, or retired. Extensions are the only supported model in Dynamics 365, so overlayered code cannot simply come across.
Full transactional history is expensive to migrate and slows every later release. Opening balances plus an archive for enquiry is usually the better trade. We decide it deliberately rather than by default.
AIF services, custom jobs and file drops need rebuilding on supported patterns. This is frequently the largest single item of work and the one most often underestimated.
Entity by entity, site by site, or big bang. Sequencing is driven by close calendar, stock count windows and how much manual bridging your team can absorb.
Cloud licensing changes the cost shape entirely. We model it before the business case is signed rather than after the first true-up.
Most organisations move to Dynamics 365 Finance and Supply Chain Management, the direct enterprise successor to AX. A minority, typically those that have simplified since AX was implemented, are better served by Business Central at a lower run cost. Both answers are legitimate, and the assessment tells you which one applies.
A bounded piece of work producing a code inventory, integration inventory, data profile, process fit view and a written recommendation on upgrade versus re-implementation, with the cost and risk shape of each. You can take that document to another partner if you want to. Several have.
Migration runs through our normal delivery system, with gates, shared responsibilities and a cutover plan the business signs rather than receives.
Licensing changes the running cost more than most people expect. Licence planning belongs in the business case, not after it.
Before you call
A conversation, not a demo
Tell us the version, the entity count, roughly how customised it is and what still runs outside it. We will tell you whether an upgrade or a re-implementation is the sensible route, and what would need to be true either way.
