Microsoft Dynamics 365

How Long Does a Dynamics 365 Implementation Take?

MR
Marcel Rizzolo
4 min read
Business Central in months, Finance and Operations in quarters, and the schedule is decided by data and decisions, not licences. Realistic timelines by scenario.

The honest answer is a range, and the range depends on which product you are implementing, how much of your business you are putting into it, and two factors that almost nobody budgets for properly: the state of your data and the speed of your decisions. Here are the timelines we quote and defend, scenario by scenario.

Business Central: three to six months

A Business Central implementation for a straightforward business, finance plus purchasing plus inventory, lands in the three to six month range. The shorter end assumes standard processes, a clean chart of accounts, and a customer willing to adapt to the product rather than the reverse. The longer end usually means integrations to other systems, data migration from something old enough to have opinions, or a business that wants its exceptions preserved.

If you are choosing between Business Central and its bigger sibling, that decision comes first and changes everything downstream. Our guide to Finance and Operations versus Business Central covers how to make it.

Finance and Operations: nine to eighteen months

Finance and Operations is a different animal. A single-entity, single-country implementation with disciplined scope can go live around the nine month mark. Multi-entity, multi-country programmes with manufacturing or advanced warehousing run twelve to eighteen months, and global rollouts phase over years by design. These are programme timelines, not project timelines, and they move at the speed of the slowest workstream, which is almost always data.

The single biggest schedule risk is not configuration. It is data migration, and we have written before about why F&O go-lives are decided before UAT. A customer master full of duplicates or an ETL run that cannot fit the cutover window will cost you months, and both are discoverable in the first quarter of the programme if someone looks.

Migrating from AX 2012: add the archaeology

An AX 2012 to F&O migration carries everything above plus the work of deciding what fifteen years of customisation actually earns a place in the new system. Code upgrade tooling shortens the mechanical work; the judgement work, what to rebuild as extensions and what to retire, is where the time goes. Plan for twelve months as a floor and treat any shorter promise with suspicion. The full decision framework is in our AX 2012 to D365 migration guide.

What actually sets the schedule

Four factors, in order of influence. First, data quality: cleansing and migration rehearsals are the workstream most often underscoped, and the one that cannot be compressed at the end. Second, decision speed: a programme where the steering committee resolves design questions in days runs quarters faster than one where every decision waits for a monthly meeting. Third, scope discipline: every process exception you preserve is configuration, testing and training that did not exist in the estimate. Fourth, team continuity: swapping key people mid-programme costs more time than any tool saves.

Notice what is not on the list: licences, environments and infrastructure. Microsoft has made the mechanical parts fast. The slow parts are yours.

Timeline and cost move together

Every month of programme is a month of team cost, which is why the timeline conversation and the budget conversation are the same conversation. We have set out the cost side, including the ranges we see in the Australian market, in how much a Dynamics 365 implementation costs.

If you want a timeline for your specific situation rather than a range, that takes a conversation about your entities, your integrations and the state of your data. Our Dynamics 365 practice has run these programmes as implementer and as rescue party, and a consultant who has delivered comparable work replies within one business day.