Business Central Implementation: Timeline and Best Practices

A Business Central implementation is not a technology project. It is a business change project that uses technology as the mechanism. The partner does the technical work. The client provides the business knowledge, the decisions, and the internal ownership that make that work possible. This distinction is where most implementation problems begin.

According to industry data, only 49% of ERP projects go live on schedule, with 27% experiencing slight delays and 24% facing moderate to significant overruns (DocuClipper ERP Statistics, 2025). In Zoosh Digital’s experience working with Irish and UK SMBs, the gap between expected and actual go-live timelines is one of the most consistent patterns we see. The expectation is almost always shorter than the reality. This is not caused by the software. It is almost always caused by the same three things: data quality issues discovered mid-project, scope additions that seemed minor individually but compound, and insufficient internal resource allocation. This article addresses all three, and what a well-run implementation looks like from start to finish.

Realistic Timelines by Scope

The most useful thing a partner can do before a project begins is give you an honest timeline, not an optimistic one. Here is what the data and our experience suggest for Irish and UK SMBs.

Basic scope covers finance and light inventory, standard configuration, minimal customisation, clean data, and under 20 users. Realistic timeline: 6 to 12weeks. UK and Ireland-specific partner Yes Dynamic cites 8 to 14 weeks for standard SMB deployments at this scope, with more complex environments running16 to 26 weeks (per yesdynamic.com). This is the fastest realistic go-live for an SMB, and it requires genuinely clean data and well-defined processes to hit the lower end of that range.

Standard scope covers finance, purchasing, inventory, sales, one to three integrations, some configuration work, and 20 to 50 users. Realistic timeline: 3 to 5 months. This is the most common range for growing Irish and UK SMBs moving to Business Central from accounting software or a legacy system. Three months is achievable with a well-prepared client and a disciplined partner. Five months is more typical when integrations are involved or data needs significant cleaning.

Complex scope covers manufacturing or service management modules, multiple integrations, data migration from a legacy ERP, multi-entity structures, or more than 50 users. Realistic timeline: 6 to 12 months. A phased approach is strongly recommended at this scale: a defined Phase 1 go-live on core finance and operations, followed by Phase 2 for manufacturing, integrations, or additional entities.

Why most projects take longer than buyers expect: the two most consistent causes of timeline overruns are data quality issues discovered in the data migration work stream(which is almost always later in the project than it should be), and scope additions that accumulate after the initial statement of work is signed. Both are preventable with the right approach upfront. Industry data confirms the pattern: only 49% of ERP projects go live on schedule (DocuClipper ERPStatistics, 2025), and in Zoosh Digital’s experience, the businesses that hit their go-live date are almost always the ones that completed a thorough data assessment and fixed their scope in writing before the project started.

A relevant documented example of what this looks like in practice: Harding Retail, aUK-based retailer, worked with Microsoft Partner TNP (The 365 People) on aBusiness Central eCommerce integration project that was delivered under budget and in less time than anticipated (per TNP case studies, the365people.com/case-studies).The outcome reflected the same factors this article identifies: a well-defined scope, active internal involvement throughout, and a partner methodology that did not attempt to start configuration before requirements were understood.

The Four Phases of a Business Central Implementation

Every credible Business Central implementation follows a sequence of four phases, regardless of scope. The timelines within each phase vary, but skipping or compressing any phase creates specific and predictable problems.

Phase 1: Discovery and requirements (2 to 4 weeks)

This is the most important phase and the one most frequently underinvested. Discovery covers requirements gathering, process mapping, fit-gap analysis (identifying where standard BC functionality meets the business requirement and where configuration or customisation is needed), and the data assessment.

The output of discovery is a detailed statement of work, a data migration plan, an integration specification, and a project plan with milestones. Any partner who jumps to configuration before completing a thorough discovery phase is creating rework risk. At Zoosh Digital, the discovery and process mapping phase is treated as the foundation of the project: understanding how the business actually operates before a single field is configured.

Phase 2: Configuration and development (4 to 16 weeks, depending on scope)

This phase covers system configuration to match the agreed requirements, bespoke development using Application Language (AL), the programming language used to build custom extensions on top of Business Central, AppSource extension installation and configuration, and integration development. Configuration against documented requirements is faster, lower-risk, and less expensive than configuration based on assumptions. This is why Phase 1 matters.

The guiding principle here: configuration over customisation wherever possible. In Zoosh Digital’s experience, Business Central’s out-of-the-box functionality covers around 80% of SMB requirements without any bespoke development. Every bespoke AL extension adds upfront development cost, increases complexity during Microsoft’s twice-yearly updates, and creates long-term maintenance overhead. A good partner pushes back on customisation requests that standard BC handles through configuration. A less experienced partner says yes to everything in the sales phase and deals with the consequences during the project.

Phase 3: Data migration, testing, and training (3 to 8 weeks)

Data migration, user acceptance testing (UAT), and user training run in parallel during this phase.

Data migration best practice: migrate master data (customers, vendors, items, chart of accounts) and opening balances only. Historical transaction data adds weeks of reconciliation effort for minimal business value. The historical data should be archived and accessible for reference, not migrated into the live system. Clean the data before migration, not after: data quality issues that emerge during migration extend the project timeline and require decisions that should have been made earlier.

UAT is the process by which the client team tests the configured system against the agreed requirements. UAT requires the internal team’s active participation. A partner who runs UAT without substantial client involvement is not running a properUAT.

Training should be role-based and structured across the final two to three weeks before go-live, not compressed into the week before. Users who understand the system before go-live see reduced adoption issues in the post-go-live period.

Phase 4: Go-live and stabilisation (30 to 90 days post go-live)

Go-live is the beginning of adoption, not the end of the project. The 30 to 90 days following go-live are when the team transitions from trained users to confident operational users. This period requires active partner support: rapid response to issues, hypercare for the first two weeks, and structured check-ins at 30, 60, and 90 days. Budget for this phase explicitly. It is one of the most consistently under planned elements of BC implementations, and the absence of structured post-go-live support is a primary reason why businesses find themselves working around the system in spreadsheets six months after go-live.

Why Implementations Fail: The Five Root Causes

The ERP industry has a pattern of underselling implementation complexity to win deals. The result is expectation misalignment that becomes visible at month three when the timeline has slipped and the internal project team is burning out. Here are the five root causes of Business Central implementation failure, in order of frequency.

1. Data quality problems discovered too late. Data migration is the most underestimated work stream in every ERP project. Customer records with duplicate entries, items without complete pricing or costing data, supplier records that have not been reconciled in years: these are normal in any business that has grown organically. When they are discovered during migration, the project stops while the data is cleaned. A proper data assessment in Phase1 identifies these issues before the project plan is set.

2. Scope not fixed at the start. Scope creep is the single most common cause of timeline overruns. Every addition that seems minor in isolation adds hours of configuration, testing, and training. The go-live date should follow the defined scope. If the scope changes, the date changes. A project where the date is fixed and the scope is allowed to grow will fail to deliver either on time or on quality.

3. Insufficient internal resource allocation. An ERP implementation requires 20 to 30% of a named internal person’s time throughout the project.This is not a marginal commitment. For a four-month standard-scope project, that is effectively four to six weeks of one person’s full attention. Businesses that treat the implementation as the partner’s project, and assign their own people to it only when available, consistently experience delays, rework, and go-live day surprises.

4. Lack of executive sponsorship. Implementations without a named executive sponsor have a documented pattern of priority conflicts, delayed decisions, and stalled projects. The sponsor does not need to be technical. They need to be visible, available to unblock decisions, and publicly committed to the project outcomes. When the project competes with daily operations for internal resource time, the sponsor is the person who resolves that conflict.

5. Training treated as a final event. User adoption is not a training event at the end of the project. It is a programme that starts in the discovery phase when users understand why the new system is being introduced, continues through role-based training before go-live, and requires a post-go-live stabilisation period with active support. Research consistently identifies inadequate training and change management as primary causes of ERP underperformance after go-live (Panorama Consulting ERP Report, 2024).

A comparable documented example: the Akita case study describes a UK manufacturer that had been running a legacy Sage 200 system creating operational bottlenecks the business had been working around for years rather than resolving. The BC migration resolved those bottlenecks and improved visibility and automation across the business. The full case study is available at

akitais.com/case-studies/sage-200-to-business-central-migration/.The root cause in that case was not the software. It was the absence of a clear path to resolve process gaps within the existing system, which is a pattern that appears in many of the conversations Zoosh Digital has with businesses that come to us having already attempted a partial implementation or a system change that did not deliver what was expected.

What a Good Implementation Partner Actually Does

A credibleBusiness Central partner does more than configure the software. The partner’s methodology is the primary variable in whether an implementation delivers its intended outcomes.

Zoosh Digital’s approach is built on a co-creation model. The first step in any engagement is the discovery and process mapping phase: understanding how the business actually operates, where the current processes have gaps, and what the system needs to do before a single field is configured. This phase is not a formality before the real work begins. It is the work that determines everything that follows.

The characteristics of a credible BC partner:

• They give you a realistic timeline before they give you a go-live date. If the first conversation is about the date rather than the scope, that is a signal.
• They conduct adata assessment in the discovery phase, not during migration. They tell you what needs to be cleaned before the project plan is agreed.
• They push back on customisation requests that standard BC handles through configuration. Unnecessary AL (‘Application  Language’. A programming language created by Microsoft for customising and  building extensions for Dynamics 365 Business Central) extension development is a cost to the client, not a revenue opportunity for a good partner.
• They can clearly answer: what is the internal time commitment from our team? What does post-go-live support look like for the first 90 days? And what does it cost?
• They have experience with Irish and UK-specific requirements: Revenue and ROS compliance for Irish clients, Making Tax Digital for UK clients, and the practical implications of both for the configuration.

The Questions to Ask Before Signing a Statement of Work

These four questions are worth asking any partner before committing to a project, and the quality of the answers will tell you what you need to know.

What does the internal time commitment look like from our team? A credible answer is 20 to 30% of a named person’s time throughout the project, with specific phases requiring more. If the answer is minimal, that is a red flag.

What is in scope and what is out of scope, in writing? The statement of work should define this precisely. If the scope is described in broad strokes, the project is not yet ready to start.

Who is our data owner, and what does the data migration process look like? The data owner is the person responsible for the customer master, vendor list, and item records. They need to be identified, available, and committed from week one.

What does post-go-live support look like for the first 90 days, and what does it cost? This should be a clear, priced answer. If it is vague or deferred to a later conversation, the partner is not treating the stabilisation phase as a structured part of the project.

FAQ

How long does a Business Central implementation take?

Timeline depends on scope. Basic scope (finance and light inventory, under 20 users, minimal customisation): 6 to 12 weeks. Standard scope (finance, purchasing, inventory, sales, one to three integrations, 20 to 50 users): 3 to 5 months. Complex scope (manufacturing, multiple integrations, legacy ERP migration, 50 or more users):6 to 12 months. Industry data shows only 49% of ERP projects go live on schedule (DocuClipper, 2025). In Zoosh Digital’s experience, the businesses that hit their go-live dates are consistently the ones that fixed their scope in writing before the project started and completed a data assessment in the discovery phase.

How much internal time does a Business Central implementation require?

A named internal resource should expect to commit 20 to 30% of their working time throughout the project. For a standard four-month implementation, that is effectively four to six weeks of one person’s full attention across the project duration. Additional stakeholders (finance, operations, warehouse, IT) will be required for specific phases: process mapping, data validation, user acceptance testing, and training. An implementation that requires minimal internal resource commitment is not a well-run implementation.

What is the most common cause of Business Central implementation failure?

Data quality problems discovered mid-project and scope not fixed at the start are the two most common causes of timeline and budget overruns. Both are preventable: a thorough data assessment in the discovery phase identifies data issues before the project plan is set, and a precisely defined statement of work removes the ambiguity that allows scope to creep. Executive sponsorship and structured user adoption are the other two critical success factors.

Should we migrate historical data to Business Central?

Best practice is to migrate master data (customers, vendors, items, chart of accounts) and opening balances only. Historical transaction data adds significant reconciliation effort during migration for limited operational value. The historical data should be archived and accessible for reference from the existing system or a dedicated archive, not migrated into the live BC environment. Attempting full historical migration is one of the most consistent causes of data migration delays.

What is an AL extension and when do we need one?

ApplicationLanguage (AL) is the programming language used to build custom extensions ont op of Business Central. AL extensions add functionality beyond the standard product: industry-specific workflows, custom integrations, bespoke reporting, or unique business processes that standard BC configuration cannot accommodate. Every AL extension adds upfront development cost, increases complexity duringMicrosoft’s twice-yearly updates, and creates long-term maintenance overhead.In Zoosh Digital’s experience, standard Business Central covers around 80% ofSMB requirements through configuration alone. A good partner explores configuration options before recommending AL development, and builds AL extensions only where there is a clear business case.

What happens at go-live?

Go-live is the day the business switches from its previous system to Business Central for live operations. It is not the end of the project. The 30 to 90 days following go-live are the stabilisation period: the team transitions from trained users to confident operational users, issues surface and are resolved, and the partner provides active hypercare support. Budget for this phase explicitly and agree the support scope before the project starts. The stabilisation period is where the return on the implementation investment is either secured or lost.

How do we choose a Business Central implementation partner?

The most important factors are methodology, UK and Ireland-specific experience, and honest communication about timelines and scope. Ask the partner for a realistic timeline before asking for a go-live date. Ask what the internal time commitment looks like. Ask for a data assessment in the discovery phase. Ask how post-go-live support is structured and priced. A partner who can answer all of these questions clearly, with specifics, is demonstrating the methodology that produces successful implementations.

Closing Thought

The businesses that get the most from Business Central are not the ones with the cleanest data or the simplest processes. They are the ones that treated the implementation as a business project, with internal ownership, an executive sponsor, and a realistic plan, rather than as a technology installation they could hand off to a partner and collect on delivery.

A well-run implementation changes how the business operates. A poorly prepared one creates an expensive system that the team works around. The difference between the two outcomes is rarely the software. It is the preparation, the methodology, and whether the partner told you the truth at the start.

Referenced Sources

• DocuClipper. ERP Statistics 2025. docuclipper.com/blog/erp-statistics/.
• Panorama Consulting. 2024 ERP Report. panorama-consulting.com.
• Yes Dynamic. Business Central standard SMB deployment timeline. yesdynamic.com/solutions/dynamics-365-erp/business-central/.
• TNP (The 365 People). Harding Retail: Business Central eCommerce implementation case study. the365people.com/case-studies.
• Akita. Sage 200 to Business Central migration case study. March2026. akitais.com/case-studies/sage-200-to-business-central-migration/.
• Microsoft. Dynamics 365 Business Central pricing and licensing. microsoft.com/en-ie/dynamics-365/products/business-central.
• Microsoft Learn. Dynamics 365 Business Central 2025 Release Wave1 Overview. learn.microsoft.com.

‍