How long does a Business Central implementation take?

It depends on scope, the number of companies and integrations, data quality and how much time your team can give the project. A partner should give you a dated plan after discovery, based on your processes and data rather than a general estimate.

Should we implement everything at once or in phases?

Phasing usually lowers risk. Many companies start with finance, purchasing, sales and inventory, then add manufacturing, projects, service or additional entities once the core is stable.

How much historic data should we migrate?

Usually master data, open items and summarised balances for comparison periods. Detailed history is rarely worth the migration effort; keeping the old system available read-only, or archiving its data, is often enough.

Hypercare is the period of close support right after go-live, usually running through at least the first month-end close. Consultants stay on hand to answer questions, fix issues quickly and help users settle into new routines.

How to plan a Business Central implementation

Start with outcomes and scope

Before anyone opens a configuration page, write down what the business needs to be true after go-live. Faster month-end close, accurate stock across warehouses, one set of books for several entities, approval workflows that leave an audit trail: these are outcomes you can design and test against. A list of screens and reports is not.

Then agree scope in plain terms. Which companies and countries are in the first phase? Which processes, from order to cash, procure to pay, inventory, manufacturing, projects, service? Which existing systems stay, and which will Business Central replace? Anything left vague here returns later as a change request, usually at a worse moment.

The phases of a Business Central implementation

Names vary between partners, but a sound implementation moves through the same sequence. Phases overlap a little, yet each one should end with a clear decision before the next starts in earnest.

Discovery: map current processes, pain points, data sources, integrations and reporting needs.
Design: decide how each process will run in Business Central, including the chart of accounts, dimensions, posting groups, approvals and any extensions.
Build and configure: set up the system, develop extensions and integrations, and prepare migration templates.
Data migration: cleanse, map and load master data and balances, with several practice loads.
Testing: confirm that each process works end to end with real examples, then let key users accept it.
Training: teach each role the tasks it will actually perform, in a system loaded with familiar data.
Cut-over and go-live: freeze the old system, load final balances, switch over and support users closely through the first close.

Who you need on the team

Business Central is quick to configure, but no partner can make decisions on your behalf. Your side of the team matters as much as ours, and the people named here need real time set aside, not just their names on a chart.

Executive sponsor: owns the outcomes, settles priorities and unblocks decisions that cross departments.
Project lead: runs the plan day to day, chases decisions and keeps the partner and internal teams aligned.
Key users: one per process area, usually from finance, purchasing, sales and the warehouse. They explain how work really happens, test the design and train colleagues later.
Finance controller: signs off the chart of accounts, tax setup, opening balances and reconciliations.
IT or systems owner: handles Microsoft 365 licensing and access, security, integrations and any third-party systems.
Partner team: a functional consultant for each area, a developer where extensions or integrations are needed, and a project manager who owns the delivery plan.

Plan data migration early

Data migration is the single most common reason go-live dates slip. Start by deciding what moves. Master data such as customers, vendors, items, fixed assets and the chart of accounts almost always moves. Open items, meaning unpaid invoices, open orders and stock on hand, usually move at transaction level so ageing and fulfilment work from day one. Historic transactions rarely justify the effort; most companies bring across summarised monthly balances for comparison and keep the old system available for look-ups.

Cleanse before you map. Duplicate customers, inactive items and inconsistent units of measure are easier to fix in a spreadsheet than after they are loaded. Then run at least two practice loads into a test environment, reconcile each one against the source system, and time the final load so you know how long cut-over will take.

Testing that reflects real work

Testing individual screens tells you very little. Write scenarios that follow a real transaction from start to finish: a customer order with a partial shipment, a credit note and a payment in a foreign currency; a purchase that is received in two batches and invoiced with a price difference. Include the awkward cases your team handles every month, because those are the ones that surface after go-live.

Run integration testing with the connected systems switched on, then hand over to key users for acceptance. Their sign-off should be against the outcomes agreed at the start, not a feeling that the system looks right.

Cut-over and go-live

Pick a go-live date that suits the accounting calendar. The start of a month or quarter keeps opening balances simple, and the start of a financial year is cleaner still, though not essential. Avoid dates close to statutory deadlines, audits or your busiest trading weeks.

Write a cut-over plan that lists every step with an owner and an expected duration: when the old system freezes, when final balances are extracted, when they are loaded and reconciled, and who decides to go live or roll back. Rehearse it. Then plan hypercare, a period of close support through the first month-end close, when most real questions appear.

What drives cost and timeline

Every implementation is priced differently, but the same factors move cost and timeline up or down. Understanding them helps you compare proposals fairly and decide where to simplify.

Scope: the number of companies, countries, localisations and process areas in each phase.
Fit to standard: processes that match Business Central's standard features cost less than those that need extensions.
Integrations: each connected system, such as e-commerce, a warehouse system, payroll or banking, needs design, build and testing.
Data volume and quality: clean, consistent data loads quickly; messy data takes cleansing time on both sides.
Reporting needs: standard reports and Power BI content are quicker than bespoke reporting packs.
Your team's availability: decisions and testing that wait for busy people extend the plan more than any technical task.
Training approach: training key users who then train others costs less than training every user directly, but needs strong key users.

Typical risks and how to avoid them

Most risks are predictable, which means most can be avoided with a little discipline early on.

Recreating the old system: challenge every request to copy a legacy process, and start from Business Central's standard way of working.
Scope creep: keep a parked list for phase two and protect the first go-live date.
Key users without time: agree time allocations with their managers before the project starts.
Late data work: begin cleansing during discovery, not after build.
Thin testing: test with real scenarios and real volumes, and include the exceptions.
Weak hypercare: keep consultants close through the first month-end close and the first tax return.

Published 2026-10-18 by the Synapserve team.