A prospective client asks how long a Business Central implementation takes, and gets an answer that sounds precise: "four months." What that answer usually leaves out is that the four months assumes clean legacy data, no major customizations, and a client team available for testing exactly when needed — three assumptions that turn out to be wrong at a large share of companies, and the resulting delay gets treated as a surprise rather than something that could have been planned for.
Here's what a realistic implementation timeline actually looks like, broken into its real phases, with the variables that most commonly extend it.
Discovery and Design: 3-6 Weeks
This phase maps your actual business processes against Business Central's capabilities — deciding what's standard configuration, what needs customization, and what workarounds you'll accept versus what you'll insist on solving properly. Companies that rush this phase to "get to the real work faster" routinely pay for it later, when a requirement surfaces mid-build that should have been caught here.
Configuration and Development: 6-12 Weeks
The range here is wide because it depends entirely on how much falls outside standard functionality. A company needing only standard modules configured to their chart of accounts and processes sits at the shorter end. A company needing custom integrations, specific approval workflows, or industry-specific extensions sits considerably longer — and this is where "four months" quietly becomes six, when custom development scope wasn't fully understood during discovery.
Data Migration: Runs in Parallel, But Rarely Finishes on the First Pass
Data migration typically runs alongside configuration rather than as a separate sequential phase, but it's worth calling out specifically because it's the single most common source of timeline slippage. Legacy data that looked clean in the old system frequently isn't — duplicate customer records, inconsistent item codes, incomplete historical transactions — and discovering this mid-migration, rather than during an honest data quality assessment at the start, is what turns a planned two-week migration into a six-week one.
User Acceptance Testing: 3-4 Weeks
This is the phase most likely to get compressed when the project is running behind, which is exactly backwards — inadequate testing means problems get discovered by end users after go-live instead of by a test team before it, at a much higher cost to fix. A realistic timeline protects this phase rather than treating it as flexible buffer time.
Go-Live and Stabilization: 2-4 Weeks
Go-live isn't the finish line — the weeks immediately after are when real-world usage surfaces issues testing didn't catch. A realistic timeline budgets dedicated support resources for this window rather than assuming the project team can simply move on once the system is technically live.
Fixed-Price vs. Time-and-Materials: A Real Timeline Difference
A fixed-price engagement locks scope early, which protects your budget but means any genuinely new requirement discovered mid-project becomes a formal change order — often adding real calendar time to negotiate and approve, not just cost. Time-and-materials engagements can absorb new discoveries more fluidly, but without a firm budget ceiling, timeline discipline depends heavily on how tightly the project is managed week to week. Neither structure is universally better; the right choice depends on how confident you are in your original scope.
What Actually Extends Timelines, Ranked by How Often We See It
Poor legacy data quality discovered mid-migration. Custom development scope underestimated during discovery. Client-side resources unavailable for testing when the project plan needed them. Scope creep from stakeholders introducing new requirements after design sign-off. Every one of these is avoidable with more rigorous upfront planning — none of them are inherent to Business Central as a platform.