How long does a Business Central implementation really take?

Three orders of magnitude, drawn from our own projects: One entity close to standard with clean data takes roughly three to four months. One or two entities with their own industry logic and a legacy system to replace, the most common mid-market case, roughly six to nine months. Several entities or countries with deep manufacturing: twelve months or more to the first site, after which it speeds up, because you are rolling out rather than implementing. The widely quoted 8 to 16 weeks apply to the first case only. A tight timeframe holds when three conditions come together: a single company with no multi-entity structure, processes close to the standard with little customisation, and a data foundation that is already clean. What matters is that all three apply, not two out of three. If the clean data foundation is missing, the clean-up moves into the critical path and extends the project at its most sensitive point. If a second company joins, it is not only the scope that changes but the logic: you then need a template and a pilot, so a different approach with a different duration. Anyone who wants a reliable answer on duration should therefore check these three points first.

When is a fast implementation realistic?

Fast implementations are not made up, but they apply to one clearly bounded case. When all three of the following conditions come together, a tight timeframe of a few months really does hold, and there is no reason to plan longer than necessary.

• A single entity, no multi-entity structure.
• Little customisation, processes close to the standard.
• An already clean data foundation.

What matters is that all three apply, not two out of three. If the clean data foundation is missing, the cleansing moves into the critical path and extends the project at its most sensitive point. If a second entity is added, not only the scope changes but the logic: then you need a template and a pilot, and that is a different approach with a different duration. So check the three points honestly before you commit to a schedule.

What really drives the duration?

As soon as you depart from that case, the arithmetic shifts. The duration depends on five factors that can be named up front instead of discovered during the project.

• The state of your legacy data and the effort to clean it.
• The number of entities and countries.
• The integration depth to surrounding systems.
• The degree of customisation relative to the standard.
• The documentation status of your processes.

Data migration and testing are the regularly underestimated blocks here, because both only show their true size inside the project. With several entities the rollout factor is added: harden the pilot first, then roll out, rather than starting all sites in parallel. And the last point works indirectly but strongly: undocumented processes have to be decided during the project, and decisions need calendar time, not consulting days. This is the point at which projects most often stretch in practice.

What the timeline is made of: the phases and their shares

More useful than a single total is the question of how the time is distributed. Our projects show a pattern that stays remarkably stable across all size classes:

Read this table the other way round: migration, testing and acceptance together account for roughly 40 per cent of the project. That is exactly the part that gets cut when the deadline tightens, because it sits late and looks like routine work. Cutting it does not remove the work, it only moves the moment it surfaces, straight into live operation.

What sits behind the three size classes

The ranges above are experience values, not a commitment. What matters is what they depend on, because that tells you which class your project falls into:

• One entity, close to standard, data already clean: roughly three to four months. This is the case the well-known short timelines are built on. It does occur, just less often than it is sold.
• One or two entities with their own industry logic and a legacy system to replace: roughly six to nine months. This is where most mid-sized companies sit. What decides the timeline is the migration and the number of connected systems, not the functional scope.
• Several entities or countries, deep manufacturing: twelve months or more to the first site. After that it speeds up, because you are no longer implementing but rolling out. What matters is that the pilot is genuinely hardened before the second site starts.

If you are offered a first-case timeline for a second or third-case project, that is not a sign of speed. It is a sign of an assumption nobody put on the table. Ask what sits behind the number, not for a discount.

What is an honest range instead of a wishful number?

We give you a range up front based on your actual complexity, not a figure that sounds good. A solid range that holds is worth more in the project than a tight date that bursts, because the entire planning of your business departments hangs on that commitment.

In practice that means we name the frame, the assumptions behind it and the two or three points that could tip it. That lets you steer instead of hope. A date without disclosed assumptions is not a plan, only a promise.

One point belongs in the picture from the start: the work does not end at go-live. Business Central receives two major releases a year plus ongoing updates, and Microsoft publishes the schedule for them in advance. Whoever plans for that rhythm from the start has quiet afterwards instead of surprises.

Source: Microsoft Learn: Update cycles

Whether the date holds is decided by a different question: How do you know you are ready to go live?