Most of what gets written about Business Central focuses on what the platform can do. Less gets written about what actually happens during an implementation: how long it really takes, where projects commonly go wrong, and what a healthy go-live looks like compared to a shaky one. This piece sets out the practical realities of a Business Central implementation, independent of any particular sector or partner, so you know what to expect before you start.
What a Realistic Implementation Timeline Looks Like
Implementation timelines vary by project size and complexity, but most Business Central projects move through the same broad phases. Understanding where time is typically spent helps set realistic expectations before a project starts.
Discovery and solution design
Mapping current processes, data structures, and reporting needs. This phase determines almost everything that follows, so rushing it tends to cost more later than it saves now.
Configuration and build
Setting up the system to match agreed processes, building integrations, and preparing migration scripts. Most of the technical work happens here.
Data migration and testing
Extracting, cleaning, and loading data, followed by user acceptance testing. This is consistently the phase most likely to overrun if source data quality is poor.
Training and go-live preparation
End-user training, final rehearsal, and cutover planning. Under-investing here is one of the most common causes of a rocky go-live.
Go-live and hypercare
A period of intensive support immediately after go-live, including the first month-end close on the new system, where most remaining issues surface.
In total, a straightforward implementation typically runs three to six months. More complex projects, with multiple integrations or significant customisation, often run six to twelve months. The software itself rarely sets the pace; data readiness and internal decision-making speed usually do.
Configuration vs Customisation: Why the Distinction Matters
One of the most consequential decisions in any Business Central project is how much to configure versus how much to customise. The two approaches differ significantly in cost, risk, and long-term maintainability.
| Configuration | Customisation |
|---|---|
| Uses Business Central’s built-in settings, fields, and workflows | Extends the platform with custom code, fields, or logic |
| Generally upgrade-safe and lower maintenance cost | Can complicate future upgrades if not built carefully |
| Faster and cheaper to implement | Higher upfront cost and longer build time |
| Best for the majority of standard business processes | Justified where a process is genuinely unique to the business |
The strongest implementations configure first and reserve customisation for the small number of processes where it is genuinely necessary. Projects that default to customisation early, often because it is faster to build something bespoke than to adapt a process to fit the platform, tend to cost considerably more to maintain over time.
Warning Signs to Watch for During Implementation
Most implementation problems are visible well before go-live, if you know what to look for. These are the patterns worth raising immediately if you notice them.
Discovery feels rushed
If discovery workshops are compressed into a day or two with no real process mapping, configuration decisions later will be guesswork.
Scope keeps quietly expanding
Small additions that each seem reasonable can accumulate into significant timeline and budget pressure if nobody is tracking them against the original plan.
Migration testing keeps slipping
Repeated delays to data migration testing usually mean source data quality issues are bigger than first assumed.
Training is treated as an afterthought
If user training is scheduled in the final week with no rehearsal, expect a difficult first few weeks of live usage regardless of how well the system was built.
What a Healthy Go-Live Actually Looks Like
Go-live is rarely flawless, even on well-run projects. The difference between a healthy go-live and a troubled one is less about whether issues appear and more about how quickly they are resolved.
- A defined hypercare period with closer-than-normal support availability for the first two to four weeks
- Daily or near-daily check-ins with key users during the first fortnight
- A clear escalation path for issues that affect core transactions or reporting
- Close monitoring of the first month-end close on the new system, since this is where many remaining issues surface
- A planned transition point from hypercare into standard ongoing support, agreed in advance rather than decided reactively
Before signing any implementation contract, ask exactly what hypercare looks like in practice: how long it lasts, what support response times apply, and what happens once it ends. A vague answer to this question is a meaningful signal.
