A Business Central implementation is the end-to-end project that moves a business off its current finance and operations systems onto Microsoft Dynamics 365 Business Central. In the UK mid-market it typically runs three to six months and costs £20,000 to £150,000 in implementation services, with licensing charged separately per user per month. Success rarely turns on the software. It turns on the quality of your existing data, the speed at which your team makes decisions, and whether anyone owns adoption after go-live. Three things changed in 2026: the product now ships autonomous AI agents, compliance reporting moved into scope, and the Dynamics GP end-of-life deadline has pulled a large wave of migrations forward.
Key takeaways
- A straightforward single-entity implementation takes 8 to 12 weeks. A mid-market project with integrations takes 4 to 6 months. Multi-entity or manufacturing rollouts take 6 to 12 months.
- Implementation services typically cost £20,000 to £60,000 for a simple rollout and £60,000 to £150,000 for a mid-market project with integrations.
- Over three years, licensing usually costs more than the one-off implementation fee. Most published cost guides leave this out.
- Business Central lists at $80 per user per month for Essentials and $110 for Premium on an annual commitment. Copilot is included; additional AI capacity is metered separately.
- Poor data readiness is the single most common cause of overrun. It is also the cheapest problem to fix, because you can start before the project does.
- Business Central’s autonomous agents work by pattern-matching your data. Duplicate vendors and free-text dimensions do not just slow reporting now, they make the agents unusable later.
- Microsoft has confirmed Dynamics GP product support and updates end on 31 December 2029, with security patches ending 30 April 2031.
- Independent research by Forrester found a composite Business Central customer achieved around 209% ROI over three years. Realising that depends on baselining your metrics before you start.
What is a Business Central implementation?
A Business Central implementation is the end-to-end project that takes an organisation from its current finance and operations systems onto Microsoft Dynamics 365 Business Central. It covers discovery, solution design, configuration, data migration, integration, testing, training, go-live and post-launch support. Most mid-market implementations run three to nine months and are led by a Microsoft partner.
Four words get used interchangeably and they mean different things:
- Implementation is the full project, including process design and change management.
- Deployment is the technical act of provisioning environments and pushing configuration live.
- Migration is moving from a specific source system, such as Sage or Dynamics GP.
- Upgrade is moving from an older Dynamics NAV or on-premises Business Central version to the current online release.
The distinction matters commercially. If a partner quotes you for a deployment when you asked for an implementation, the gap between the two numbers is the process work, and that is where most of the value sits.
What Business Central implementation includes
| Workstream | Typically owned by | Effort (mid-market project) |
| Discovery and requirements | Partner, with your process owners | 8–15 days |
| Fit-gap analysis | Partner | 3–6 days |
| Solution design and sign-off | Joint | 6–12 days |
| Chart of accounts and dimension design | Joint | 3–8 days |
| Core configuration | Partner | 15–30 days |
| Data cleansing | You | 10–30 days |
| Data migration and reconciliation | Joint | 10–25 days |
| Integrations | Partner | 5–40 days |
| Custom extensions | Partner | 0–40 days |
| Training | Partner, delivered to super-users | 6–15 days |
| Go-live and hypercare | Partner | 8–20 days |
Two lines in that table cause most of the trouble. Data cleansing is yours and nobody else can do it for you. Testing is business-led, and the moment it gets delegated to the partner it stops being a test of whether the system works for your business.
An implementation is not an IT project. The systems work is the predictable part. The unpredictable part is agreeing how your business will operate once the spreadsheets go away.
What’s different about implementing Business Central in 2026?
Three things changed. Business Central now ships autonomous AI agents that only work on clean, well-structured data, which raises the bar on data migration. Compliance reporting and e-document exchange moved from a phase-two nicety into scope. And Dynamics GP’s confirmed end-of-life has pushed a large wave of legacy migrations into the market, tightening partner capacity through 2027.
If you are reading an implementation guide written before 2026, it will be broadly correct about phases and broadly wrong about scope.
Agents are part of the product now, not an add-on
The 2026 release wave 1 added the Payables Agent and expanded autonomous agents into multi-step processes. An agent reads incoming invoices, matches them to vendors, categorises them against the right accounts and prepares them for approval, learning from the patterns already in your ledger.
That last clause is the one that changes implementation practice. Agents inherit your data quality. A vendor master with the same supplier entered four different ways does not just make reporting untidy, it gives the agent four competing patterns and no basis to choose between them. A chart of accounts with free-text descriptions instead of structured dimensions gives it nothing to learn from at all.
Before 2026, dirty master data cost you reconciliation time. Now it also costs you the automation you bought the system for. That reframes data preparation from a migration chore into the highest-return activity in the project.
Copilot is included. The credits are not.
Microsoft Copilot ships with every Business Central online licence at no extra cost. Additional AI capacity is purchased separately as Copilot Credits, either pay-as-you-go or pre-purchased.
This is a new line in the budget and almost every published implementation cost model predates it. It is not usually large, but it is genuinely variable and it belongs in the business case rather than in a surprise invoice at month four.
Compliance moved into scope
E-document exchange in Business Central now extends beyond invoices to shipments and transfer documents, and sustainability reporting for CSRD and CBAM is built into the product rather than bolted on.
For UK businesses, two things follow. Making Tax Digital for VAT already applies to all VAT-registered businesses, and Business Central submits directly to HMRC once the VAT return setup is configured, so that is a configuration task rather than a project. The bigger question is trade. If you sell into France, the phased B2B e-invoicing mandate beginning in September 2026 is a hard external deadline that your ERP has to meet, and it is far cheaper to design for during implementation than to retrofit afterwards. Check the current phasing for your company size before you scope it, because the thresholds have moved more than once.
The legacy Dynamics migration wave
Microsoft has confirmed that Dynamics GP product support and updates end on 31 December 2029, with security patches ending 30 April 2031. Sales to new customers have already closed.
Those dates sound distant. They are not. A GP estate with a decade of customisation and history takes six to twelve months to move properly, and every GP customer in the UK is working from the same calendar. Partner capacity for GP and NAV migration specialists tightens as the deadline approaches, which means the practical cost of waiting is not just risk, it is price.
What to add to your scope in 2026
| Change | Implication for your project | Add to scope |
| Autonomous agents in-product | Data quality now gates automation, not just reporting | A data standard for vendor, customer, item and dimension records |
| Copilot Credits | New variable licensing line | Consumption forecast in the business case |
| E-documents beyond invoices | Compliance is design-time, not phase two | Mandate assessment for every country you trade into |
| Sustainability reporting in-product | CSRD/CBAM data capture needs configuring | Emissions data requirements in discovery |
| Dynamics GP end-of-life | Capacity tightens, timelines lengthen | Earlier start date than feels necessary |
Business Central implementation glossary
Fourteen terms that appear in every statement of work, defined plainly.
Dynamics 365 Business Central is Microsoft’s cloud ERP for small and mid-sized businesses, covering finance, sales, purchasing, inventory, projects, service and light manufacturing in one system.
An implementation partner is a Microsoft-certified consultancy that scopes, configures, migrates and supports your Business Central system. Microsoft sells the licences; the partner delivers the project.
Success by Design is Microsoft’s own implementation framework for Dynamics 365, structuring a project around a series of design reviews that check solution decisions before they become expensive to reverse.
Fit-gap analysis is the exercise of mapping your required processes against standard Business Central functionality, producing a list of what fits as standard, what needs configuration, and what needs building.
Configuration is setting Business Central up using its built-in options, with no code. Configuration survives Microsoft’s updates untouched.
Customisation is changing or extending how Business Central behaves using code. It creates a permanent maintenance obligation across two release waves a year.
An AL extension is a code package that adds functionality to Business Central without modifying the base application. AL is the programming language Business Central extensions are written in.
A per-tenant extension (PTE) is an AL extension built specifically for your organisation and installed only in your environment. You, or your partner, are responsible for keeping it working after each update.
An ISV app is a pre-built extension published on Microsoft AppSource by an independent software vendor, licensed as a subscription and maintained by its publisher.
A sandbox environment is a non-production copy of your Business Central tenant used for testing configuration, extensions and updates before they reach live data.
A release wave is one of Microsoft’s two annual major updates to Business Central, delivered in April and October, alongside monthly service updates.
Cutover is the scheduled transition from your old system to Business Central, when final balances are loaded, the legacy system goes read-only and live transactions begin.
Hypercare is the intensive support period immediately after go-live, typically two to four weeks, when the implementation team resolves issues in hours rather than days.
Agent-ready data is master and transactional data structured well enough for Business Central’s autonomous agents to act on without human correction.
What are the phases of a Business Central implementation?
Most Business Central implementations run six phases: discovery and requirements, solution design, build and configuration, data migration and testing, deployment and go-live, then optimisation and support. Microsoft’s Success by Design framework structures the first five. A typical mid-market project spends the largest share of its effort in build and data migration.
The phases themselves are not the interesting part, because every partner runs a version of them. The interesting part is knowing when a phase is genuinely finished. Most projects slip because a phase was declared complete when the deliverables existed but the decisions had not actually been made.
Phase 1 — Discovery and requirements (2 to 4 weeks)
Process owners walk their current workflows. The partner documents them, identifies pain points, and produces a requirements list ranked into must-have and nice-to-have.
Your time commitment: 6 to 10 hours per week per process owner.
Exit criteria: Requirements signed off by name, not by committee. Must-haves separated from enhancements in writing. A named internal project owner with authority to make decisions without escalation.
Phase 2 — Solution design (2 to 4 weeks)
The fit-gap analysis is completed. The chart of accounts, dimension structure and inventory costing method are designed. Integrations are specified. Anything requiring an extension is scoped and priced.
Exit criteria: Chart of accounts and dimensions signed off by the Financial Controller. Costing method decided and understood. Integration specifications agreed with the owners of the other systems, not just with you.
This phase carries the project’s irreversible decisions and gets the least attention. Inventory costing method and dimension structure are effectively permanent once transactions post. Spending an extra week here is the cheapest insurance in the entire project.
Phase 3 — Build and configuration (3 to 8 weeks)
The system is configured against the signed design. Extensions are developed. Integrations are built and connected in a sandbox.
Exit criteria: A configured system demonstrated end to end against your own business scenarios, using your data, not demo data.
Phase 4 — Data migration and testing (4 to 8 weeks)
Cleansed data is loaded into the sandbox, reconciled against the legacy system, and repeated until it balances. In parallel, testing runs across unit, process, integration and user acceptance layers.
Exit criteria: Two consecutive dry-run migrations that reconcile to the penny. UAT scripts completed and signed by the business, not the project team. All critical defects closed.
Phase 5 — Deployment and go-live (1 to 3 weeks)
Cutover executes against a rehearsed runbook. Final balances are loaded. The legacy system goes read-only. Hypercare begins.
Exit criteria: Opening balances agreed to the legacy trial balance. First live transactions processed and verified. Support escalation path published to every user.
Phase 6 — Optimisation and support (ongoing)
Deferred requirements are revisited. Release waves are tested and adopted. Adoption is measured and gaps addressed.
| Phase | Duration | Your hours/week | The decision that must be made |
| Discovery | 2–4 weeks | 6–10 per process owner | Who owns this project internally |
| Solution design | 2–4 weeks | 8–12 | Chart of accounts, dimensions, costing method |
| Build | 3–8 weeks | 3–5 | What we will not customise |
| Migration and testing | 4–8 weeks | 12–20 | What data we are not bringing across |
| Go-live | 1–3 weeks | 20+ during cutover | Go or no-go |
| Optimisation | Ongoing | 2–4 | What we deferred and when we revisit it |
Phases overlap in practice. Build begins before design is fully signed. Testing starts before migration finishes. Any plan that shows them as neat sequential blocks is a Gantt chart, not a schedule.
How long does a Business Central implementation take?
A straightforward single-entity Business Central implementation takes 8 to 12 weeks. A typical mid-market project with integrations and moderate customisation takes 4 to 6 months. Multi-entity, multi-country or manufacturing implementations take 6 to 12 months. Timeline is driven less by company size than by data quality, decision speed and how many integrations are in scope.
Most guides segment timelines by headcount. That is the wrong variable. A 200-person professional services firm with clean data and one integration goes live faster than a 40-person manufacturer with three warehouses and a bespoke costing model.
| Business profile | Discovery + design | Build | Migration + test | Go-live | Total |
| Single entity, standard finance, no integrations | 2–3 weeks | 3–4 weeks | 3–4 weeks | 1 week | 8–12 weeks |
| Distributor, warehouse, 2–3 integrations | 4–6 weeks | 6–8 weeks | 5–7 weeks | 1–2 weeks | 4–6 months |
| Manufacturer, production and costing | 6–8 weeks | 8–12 weeks | 6–8 weeks | 2 weeks | 6–9 months |
| Multi-entity group, multiple countries | 6–10 weeks | 8–12 weeks (template) | 6–10 weeks | 2–3 weeks + 4–8 weeks per entity | 8–14 months |
A rough calculator
Start with a base of 10 weeks for a single entity. Then add:
- 2 to 4 weeks per custom integration
- 3 to 5 weeks for warehouse management
- 6 to 10 weeks for manufacturing and production costing
- 4 to 8 weeks per additional legal entity after the template is signed off
- 2 to 6 weeks if source data has not been cleansed before kickoff
What actually extends timelines
Ranked by how often we see it:
- Slow decisions. A design question that waits three weeks for an answer costs three weeks. This is the most common cause of overrun and it sits entirely on the client side.
- Dirty source data. Discovered during the first dry run, when the schedule has no slack left.
- Unavailable subject matter experts. The person who knows how the pricing rules actually work is also the person running month-end.
- Scope added mid-build. Every addition after design sign-off costs more than the same requirement would have cost in week three.
- Third-party delays. Integration partners work to their schedule, not yours.
Note what is absent from that list: technical complexity. Business Central rarely fails to do the thing. Projects run late because of people, decisions and data.
How much does a Business Central implementation cost in 2026?
Business Central implementation services typically cost £20,000 to £60,000 for a simple single-entity rollout, £60,000 to £150,000 for a mid-market project with integrations, and £150,000 or more for multi-entity or manufacturing implementations. Licensing is charged separately per user per month. Over three years, licensing usually exceeds the one-off implementation fee, which is the number most cost guides leave out.
That last sentence is the honest version of this section, and it is worth sitting with. If you are budgeting for an ERP decision on the basis of the implementation quote alone, you are looking at the smaller half of the number.
Implementation services by component
| Component | Typical range (UK) | What moves it |
| Discovery and solution design | £4,000–£15,000 | Number of processes, number of entities |
| Core configuration | £8,000–£30,000 | Modules in scope, complexity of costing and pricing |
| Data migration | £5,000–£40,000 | Source system, data quality, volume of history |
| Integrations | £3,000–£25,000 each | Native connector versus custom build |
| Custom development | £0–£40,000 | Whether you genuinely need it |
| Training | £2,000–£12,000 | Number of roles and users |
| Project management | 10–15% of project | Project duration |
| Hypercare | £3,000–£10,000 | Duration and cover hours |
The three-year picture
Here is a worked example for a 40-user distributor on Essentials, with two integrations and one ISV app. Figures are illustrative and rounded.
| Cost | Year 1 | Year 2 | Year 3 | 3-year total |
| Licensing (40 users, Essentials) | £30,000 | £30,000 | £30,000 | £90,000 |
| Implementation services | £75,000 | — | — | £75,000 |
| ISV app subscription | £6,000 | £6,000 | £6,000 | £18,000 |
| Copilot Credits (variable) | £1,000 | £2,000 | £2,500 | £5,500 |
| Support retainer (15–20% of implementation) | £6,000 | £13,000 | £13,000 | £32,000 |
| Release wave testing and enhancement | £2,000 | £6,000 | £6,000 | £14,000 |
| Total | £120,000 | £57,000 | £57,500 | £234,500 |
The implementation fee is 32% of the three-year cost. Nobody quotes it that way, and the result is a business case that looks stronger than it is and a year-two budget conversation nobody planned for.
Use this as a structure rather than as your number. Licensing varies by currency, agreement and country; get a current quote.
The eleven scope decisions that move the price
- Number of legal entities
- Number of countries and required localisations
- Number of named users, and the Essentials versus Premium split
- Whether warehouse management is in scope
- Whether manufacturing and production costing are in scope
- Number and type of integrations
- Volume and quality of data to migrate
- How much transactional history you insist on bringing across
- Number of custom reports beyond standard financial statements
- Complexity of approval workflows
- Whether training is delivered to super-users or to every end user
Why the cheapest quote costs more
A quote materially below the others is not usually a better rate. It is a smaller scope, and the difference shows up in three predictable places: data migration priced for clean data you do not have, training reduced to a single handover session, and hypercare billed separately from day one.
Ask any partner quoting low to show you the assumed number of data migration dry runs, the training hours by role, and what hypercare includes. The gap will explain itself.
What does Business Central licensing cost, and what are Copilot Credits?
Business Central lists at $80 per user per month for Essentials, $110 for Premium and $8 for Team Members, on an annual commitment. Microsoft Copilot is included at no additional cost. Extra AI capacity is purchased separately as Copilot Credits, either pay-as-you-go or pre-purchased. List prices vary by country and currency, so confirm your UK pricing before budgeting.
| Licence | List price (USD, per user/month) | Who it is for | The common mistake |
| Essentials | $80 | Finance, sales, purchasing, inventory, projects, warehouse | Assuming it covers manufacturing. It does not. |
| Premium | $110 | Everything in Essentials plus manufacturing and service management | Buying it for everyone when only production staff need it |
| Team Members | $8 | Read data, approve, submit timesheets, update own records | Assuming it allows invoice entry or order processing. It does not. |
Prices confirmed against Microsoft’s published pricing, August 2026.
Two practical notes. You cannot mix Essentials and Premium in the same tenant, so the decision is made once for the whole organisation. And Team Members is more restricted than it sounds; a good rule is that if the person creates or edits a transaction, they need a full licence.
Copilot Credits
Base Copilot capability is included. Credits cover additional AI consumption, and consumption scales with how heavily you use agents and generative features rather than with headcount.
Forecast it in the business case rather than discovering it. Start with a pre-purchase for year one, monitor actual consumption for a quarter, then size year two from real data. It is a modest line in most budgets, but it is a variable one and finance directors dislike variable lines they were not told about.
Should you self-implement, use a partner, or use a rapid deployment package?
Self-implementation works only for very small organisations with standard processes, no integrations and internal ERP experience. A rapid deployment package suits single-entity businesses that can accept out-of-the-box configuration. A full partner-led implementation is warranted once you have multiple entities, industry-specific processes, integrations, or a migration from a legacy Dynamics system.
| Your situation | Self-implement | Rapid deployment | Full partner-led |
| Under 10 users, standard finance only | Viable | Recommended | Over-specified |
| 10–50 users, one or two integrations | Not viable | Viable | Recommended |
| Warehouse or manufacturing in scope | Not viable | Not viable | Required |
| Multiple legal entities | Not viable | Not viable | Required |
| Migrating from GP, NAV or SL | Not viable | Rarely viable | Required |
| Regulated or audited environment | Not viable | Rarely viable | Required |
What self-implementation actually gets wrong
Saying self-implementation is risky is not useful. Here is what specifically breaks, in order of expense to fix:
- Inventory costing method. Chosen at setup, effectively permanent once transactions post. Getting this wrong means either living with wrong margins or a data rebuild.
- Dimension structure. Dimensions are how Business Central reports on anything other than the account code. Design them badly and every report afterwards is a workaround.
- Chart of accounts design. Importing your old chart unchanged carries a decade of accumulated compromises into a system that could have retired them.
- Posting groups. Wrong posting group setup routes transactions to the wrong accounts silently, and the discovery usually happens at year end.
None of these are difficult to configure. They are difficult to design, and the difference between the two is experience.
Cloud or on-premises: which should you choose in 2026?
Choose Business Central online unless you have a specific, documented reason not to. Cloud gets the AI agents, Copilot, automatic release waves and the e-document compliance framework. On-premises makes sense only for genuine data-residency mandates or deep infrastructure dependencies, and it means forgoing the AI capabilities that increasingly define the product.
The argument used to be about features, cost and control. In 2026 it is simpler than that. The autonomous agents, Copilot and the continuously updated compliance frameworks are cloud capabilities. Choosing on-premises is now a decision to opt out of the direction the product is going.
| Dimension | Business Central online | On-premises |
| AI agents and Copilot | Included | Not available |
| Updates | Two release waves a year, applied automatically | You schedule and fund each upgrade |
| Infrastructure | Microsoft managed | Yours to buy, run and secure |
| Upfront cost | None | Servers, licences, implementation |
| Compliance frameworks | Continuously updated in-product | Your responsibility to maintain |
| Customisation depth | Extensions only | Deeper, at the cost of upgradeability |
| Data residency | Microsoft UK and EU datacentres | Wherever you put it |
| Three-year TCO | Predictable subscription | Lower licence cost, higher total cost |
If you are on-premises today and cannot move immediately, design your extensions to be cloud-compatible now. It converts a future migration from a rebuild into a lift.
What do you need to prepare before implementation starts?
Before kickoff, prepare a clean chart of accounts, a deduplicated customer and vendor master, an accurate item list with costs, open transaction balances, and a documented picture of your current processes. Also decide who owns the project internally. Poor data readiness is the most common cause of Business Central implementations running late, and it is the one problem you can start solving before the project begins.
The readiness checklist
Data – Chart of accounts, with obsolete accounts identified for retirement – Customer master, deduplicated, with current addresses and payment terms – Vendor master, deduplicated, with bank details and payment terms – Item master with descriptions, units of measure, and current costs – Open sales orders and purchase orders – Open AR and AP with ageing – Inventory quantities and values by location – Fixed asset register with cost, depreciation to date and method – Opening trial balance – Bank account details and current reconciliation status – Employee records, if payroll integration is in scope
Process – Documented order-to-cash flow – Documented procure-to-pay flow – Documented month-end close checklist – Current approval limits and who holds them – List of every spreadsheet the finance team relies on and what each one does
People and decisions – A named internal project owner with decision authority – A named process owner per functional area – Super-users identified per department – Agreed go-live target date and the reason behind it – Agreed budget including a contingency of 10 to 15%
How ready are you? A ten-question score
Score one point per yes.
- Can you export your customer and vendor lists to a spreadsheet today?
- Do you know how many duplicate records those lists contain?
- Is your current trial balance reconciled?
- Do you have a documented month-end close process?
- Can you name the person who will make design decisions without escalating?
- Have you agreed which processes you are willing to change to match the system?
- Do you know which spreadsheets are business-critical and why?
- Have you decided what historical data you actually need in the new system?
- Have you allocated named people 8 or more hours a week for the project duration?
- Have you agreed a budget with contingency?
8–10: Ready to start. 5–7: Start, but fix the gaps in the first fortnight. Below 5: Spend a month preparing. It will cost less than the delays it prevents.
What is agent-ready data, and why does it change data migration?
Agent-ready data is master and transactional data structured well enough for Business Central’s autonomous agents to act on without human correction. Agents match vendors, categorise expenses and prepare approvals by pattern, so inconsistent naming, duplicate records and unstructured dimensions do not just slow reporting, they stop the agent from working at all.
This is the part of implementation practice that 2026 genuinely rewrote, and it is worth understanding before you sign off a migration scope.
What the Payables Agent needs from your data
The agent reads an incoming invoice and tries to answer three questions: which vendor is this, what is it for, and who approves it. It answers them by looking at the patterns already present in your system.
That means it needs:
- One record per vendor. “Acme Ltd”, “Acme Limited” and “ACME LTD” are three vendors to the system and three competing patterns to the agent.
- Consistent expense categorisation in history. If the same category of spend has been posted to four different accounts over the years, there is no pattern to learn.
- Structured dimensions rather than free text. Department and cost centre held as dimensions are usable. The same information typed into a description field is not.
- Complete vendor records. Payment terms, currency and default accounts populated, not left blank and corrected manually each time.
- Enough history to establish a pattern. This is the argument for migrating some transactional history rather than none.
The data standard to set before migration
| Data object | Requirement | Why the agent needs it |
| Vendors | Single record per legal entity, standard naming convention, no trailing punctuation | Reliable matching of incoming documents |
| Customers | Deduplicated, consistent naming, complete payment terms | Correct application of receipts and terms |
| Items | Consistent categorisation, populated units of measure and base costs | Line-level categorisation and costing |
| Chart of accounts | Purpose-built, obsolete accounts retired | Clear categorisation targets |
| Dimensions | Structured, mandatory where required, defined value set | Contextual understanding beyond the account code |
| Posting history | Consistent account usage across at least 12 months | Pattern establishment |
The commercial argument
Teams that migrate dirty data pay for it twice. Once during the project, in reconciliation time and delayed sign-off. Then again six months later, when the automation they bought the system for cannot be switched on without a data remediation exercise they did not budget for.
Cleansing before migration is not a cost. It is the cheapest possible time to do work you will otherwise do later at a worse rate.
How does Business Central data migration actually work?
Data migration follows four steps: decide what to migrate, cleanse and deduplicate at source, load into a sandbox and reconcile against the legacy system, then repeat until two consecutive dry runs balance. Most projects run three to four dry runs. The decision that saves the most time is choosing not to migrate historical transactions.
Start with what you are not migrating
Most guides list what to bring across. The more useful conversation is the opposite one, because every additional data object adds cleansing, mapping, loading and reconciliation effort.
| Data | Recommendation | Reasoning |
| Open AR and AP | Migrate | You need to collect and pay |
| Open sales and purchase orders | Migrate | Live commitments |
| Inventory quantities and values | Migrate | Required for costing continuity |
| Master data (customers, vendors, items) | Migrate, cleansed | Foundation of everything |
| Opening balances | Migrate | Non-negotiable |
| Fixed assets | Migrate | Depreciation continuity |
| 12–24 months of posted transactions | Usually migrate | Comparatives, and pattern data for agents |
| More than 24 months of history | Usually archive | Cost rises sharply, value falls sharply |
| Closed orders and historical documents | Archive | Keep the legacy system read-only instead |
| Legacy custom fields nobody can explain | Leave | If nobody can name the use, there isn’t one |
Keeping the old system read-only for a defined period, or exporting history into a reporting database, satisfies audit and curiosity at a fraction of the cost of migrating it.
The dry-run cycle
A dry run is a full migration into a sandbox, followed by reconciliation. Reconciled means specific things:
- Trial balance matches the legacy system exactly
- AR and AP ageing matches by bucket, not just in total
- Inventory matches on both quantity and value, by location
- Record counts match on every master data table
- Spot checks on individual records confirm field-level accuracy
Run it until two consecutive dry runs pass without correction. The first will fail. The second usually fails differently. If the third passes, run a fourth to prove it was not luck.
Sign-off
Each data set is signed off by the person who owns it in the business. The Financial Controller signs the trial balance. The Credit Controller signs the AR ageing. The warehouse manager signs inventory.
Sign-off by the project manager is not sign-off. It is a formality that transfers no knowledge and catches no errors.
How do you migrate from Dynamics GP, NAV, SL, Sage or QuickBooks?
Each source system has a different migration path. Dynamics GP and NAV have Microsoft-supported migration tooling for core master data. Sage and QuickBooks migrations are usually template-based extracts. In every case the tooling moves data, not process, so the configuration work of rebuilding your chart of accounts, dimensions and posting setup is the same regardless of where you are coming from.
| Source system | Path | What transfers well | What must be rebuilt |
| Dynamics GP | Microsoft migration tooling for core master data, plus extract for the rest | Customers, vendors, items, balances | Every customisation, all reports, security roles, workflows |
| Dynamics NAV | Upgrade path where versions allow; otherwise treated as a fresh implementation | Master data, configuration concepts | C/AL customisations must be rewritten as AL extensions |
| Dynamics SL | Extract and load | Master data, balances | Project structures, all customisation |
| Sage 50 / Sage 200 | Template-based extract | Master data, balances, open items | Nominal structure, reporting, any bespoke work |
| QuickBooks / Xero | Template-based extract | Master data, balances | Almost everything beyond master data |
| Spreadsheets | Direct template load | Whatever you have | Process itself, which usually did not exist formally |
The Dynamics GP timeline
Microsoft has confirmed that Dynamics GP product support and updates end on 31 December 2029, with security patches ending 30 April 2031. New customer sales have already closed.
Working backwards from those dates for a typical GP estate:
| When | What should be happening |
| 2026 | Assessment: what is customised, what is used, what can be retired |
| 2026–2027 | Implementation, while partner capacity is still comfortable |
| 2028 | Last comfortable window for a complex multi-entity GP migration |
| 2029 | Support ends 31 December. You are running unsupported after this |
| 2031 | Security patches end 30 April. Continuing to run GP becomes a risk decision |
The warning worth giving
The most expensive GP and NAV migrations are the ones scoped as a like-for-like replication. A decade of customisation usually encodes workarounds for limitations that no longer exist, plus a handful of genuine competitive processes. Separating those two categories is the highest-value week in the entire project. Replicating both is how a migration budget doubles.
How do you handle multi-entity and multi-country rollouts?
Multi-entity rollouts work best as a template model: build and prove a reference configuration in a pilot entity, then deploy it to the remaining entities with only localisation differences. Multi-country adds statutory localisations, tax reporting and language. Expect four to eight weeks per additional entity once the template is signed off.
The template model
Design once, deploy many. The reference configuration covers your chart of accounts, dimension structure, posting setup, approval workflows, document layouts and reporting. Each subsequent entity inherits it and varies only where local law or genuine operational difference requires it.
The discipline that makes this work is refusing local variation that is preference rather than requirement. Every accepted variation multiplies across the estate and turns a template rollout into a series of separate implementations.
Choosing the pilot entity
Not the largest one. Choose the entity that is:
- Complex enough to exercise the template properly
- Small enough that problems are contained
- Staffed by people who will engage rather than resist
- Not facing a year end during the go-live window
Rollout models
| Model | Fit | Risk |
| Big bang, all entities at once | Small group, near-identical entities | High. One problem stops everything |
| Phased by entity | Most multi-entity groups | Moderate. Longest total duration, lowest risk per step |
| Phased by function | Large single entities with distinct divisions | Moderate. Needs careful interim reporting |
Multi-country specifics
Microsoft provides localisations for the UK, US, Canada and most European markets, covering statutory reporting and tax. Anything beyond that comes from an ISV or a per-tenant extension.
For a UK-headquartered group, plan explicitly for: intercompany setup and eliminations, consolidation currency and rates, VAT treatment across entities, MTD submission per VAT-registered entity, and shared master data governance so the same customer is not created three times in three countries.
Which integrations matter, and what do they cost?
The integrations that matter most are CRM, e-commerce, banking, payroll, EDI and warehouse management. Native Microsoft connections such as Dynamics 365 Sales, Power BI, Outlook and Shopify cost configuration time rather than development. Custom integrations to legacy or industry systems typically cost £3,000 to £25,000 each and are the most common source of timeline overrun.
| System | Tier | Method | Typical cost | Common pitfall |
| Dynamics 365 Sales | Native | Built-in dual-write | Configuration only | Not agreeing which system owns the customer record |
| Power BI | Native | Built-in connector | Configuration only | Building reports before the data model is stable |
| Outlook and Teams | Native | Built-in | Configuration only | Underused because nobody trains it |
| Shopify | Native | Built-in connector | Configuration only | Variant and pricing mismatches |
| Banking | Connector | Bank feed or ISV | £1,000–£5,000 | Assuming every UK bank has a live feed |
| Payroll | Connector or file | ISV or import | £2,000–£8,000 | Journal mapping designed late |
| EDI | ISV | AppSource app | £5,000–£20,000 | Each trading partner needs its own mapping |
| Warehouse / barcode | ISV | AppSource app | £6,000–£25,000 | Scoped after warehouse design, which is backwards |
| Legacy or industry-specific | Custom | API or middleware | £8,000–£25,000+ | Error handling and retry logic left as an afterthought |
Three questions decide whether an integration succeeds, and all three should be answered in design, not in build:
- Which system owns each record? Two systems both believing they own the customer master is the single most common integration failure.
- Which direction does data flow, and how often? Real-time is not always better and is always more expensive.
- What happens when the other system is unavailable? If the answer is “it fails silently”, that is a defect you have agreed to build.
A note on Power Automate: it is excellent for approvals, notifications and light orchestration. It becomes a liability when it holds business-critical logic that nobody has documented and one person built. Draw that line deliberately.
Configuration, extension or ISV app: when should you build something custom?
Configure first, buy second, build last. Configuration covers most requirements and survives release waves untouched. An AppSource ISV app is the right answer when a proven solution already exists for your industry. Build a custom AL extension only when the process is a genuine competitive differentiator, because every extension is a permanent maintenance obligation across two release waves a year.
The four-question test
Run every requirement that does not fit standard functionality through this, in order:
- Can it be configured? If yes, configure it. Stop here.
- Does an AppSource app already do it? If yes, and the publisher is credible, buy it. The publisher maintains it through every update, not you.
- Is this process a genuine competitive differentiator? If it is how you actually win business, build it. If it is just how you have always done it, change the process instead.
- Will we still want to maintain this in five years? Every extension needs regression testing twice a year, forever. If that sentence causes hesitation, do not build it.
What customisation actually costs
The build fee is the visible number and the smaller one. The real cost is the tail:
- Regression testing against two release waves a year
- Remediation when a Microsoft change affects your code
- Documentation, so the next developer can maintain it
- The eventual retirement project when Microsoft ships the feature natively
Budget 15 to 20% of the original build cost annually for maintenance. Over five years that roughly doubles the price of the extension.
PTE or AppSource app?
A per-tenant extension is built for you and installed only in your environment. You own its maintenance. An AppSource app is published, licensed and maintained by its vendor, who tests it against each release wave as part of their business.
Where a credible AppSource app exists, it is almost always the better commercial decision, even at a higher sticker price. You are buying somebody else’s obligation to keep it working.
How do you test a Business Central implementation properly?
Testing runs in four layers: unit testing of individual configurations, process testing across end-to-end business flows, integration testing between systems, and user acceptance testing run by the people who will use the system daily. Budget four to six weeks. UAT should follow scripted real-world scenarios rather than free exploration.
| Layer | What it proves | Who runs it | Duration |
| Unit | Each configuration behaves as designed | Partner consultant | Continuous during build |
| Process | A full business flow works end to end | Partner with a process owner | 1–2 weeks |
| Integration | Data moves correctly between systems, including on failure | Partner and third party | 1–2 weeks |
| User acceptance | The business can do its job in the system | Your users | 2–3 weeks |
Write UAT as scripts, not as an invitation
“Have a look around and tell us if anything is wrong” produces a list of interface preferences. Scripted scenarios produce defects.
A good UAT script names the role, the scenario, the exact steps, the expected result and a pass/fail box. Cover at minimum:
- Order to cash: quote, order, pick, ship, invoice, receipt, credit note
- Procure to pay: requisition, purchase order, receipt, invoice matching, payment
- Month end: accruals, prepayments, bank reconciliation, VAT return, close
- Inventory: receipt, transfer, adjustment, count, valuation
- Reporting: every report the business currently relies on, reproduced
The cutover rehearsal
This is the practice that most reliably prevents a bad go-live and almost nobody publishes it.
Two to three weeks before go-live, run the entire cutover as a timed rehearsal: final extract, load, reconciliation, validation, sign-off. Use the real runbook. Time every step. If the rehearsal takes 26 hours and your cutover window is 20, you have found that out on a Tuesday rather than at 3am on a Sunday.
Go or no-go
Define pass criteria before testing starts, so the decision is not made under go-live pressure:
- Zero open critical defects
- No more than an agreed number of open high-severity defects, each with a workaround
- Two consecutive reconciled dry runs
- UAT signed by every process owner
- Cutover rehearsal completed within the available window
- Support path published and tested
The go/no-go decision belongs to the business sponsor. Not the partner, and not the project manager whose bonus depends on the date.
How do you train users and drive adoption?
Train by role rather than by module, and train close enough to go-live that people remember it, usually two to three weeks before. Use a train-the-trainer model with named super-users in each department. Adoption is measured rather than assumed: track active users, transaction volumes by user, and support ticket trends across the first ninety days.
| Role | Focus | Format | Hours | Timing |
| Financial Controller | Close, reporting, dimensions, VAT | Workshop | 12–16 | 4 weeks before |
| AP clerk | Invoice entry, matching, payments, agent review | Hands-on | 6–8 | 2 weeks before |
| Credit controller | Receipts, allocation, ageing, chasing | Hands-on | 6–8 | 2 weeks before |
| Sales admin | Quotes, orders, pricing, shipment | Hands-on | 6–8 | 2 weeks before |
| Warehouse | Receipt, pick, ship, count, device use | On-floor | 4–6 | 1 week before |
| Approvers | Approvals in Business Central and Outlook | Short session | 1–2 | 1 week before |
| Executives | Dashboards and reports | Briefing | 1–2 | At go-live |
The super-user model
Name two super-users per department. Train them deeply, a week ahead of everyone else, and let them help build the UAT scripts. They become the first line of support, which is faster for users and cheaper for you than routing everything to the partner.
Recognise the role formally. It is real additional work and treating it as a favour is how it quietly stops happening in month two.
Measure adoption, do not assume it
| Metric | Where to find it | 30-day target | 90-day target |
| Active users as % of licensed | Admin centre | 80% | 95% |
| Transactions entered outside the system | Ask, honestly | Declining | Near zero |
| Support tickets per user per week | Helpdesk | Peak, then falling | Below 0.5 |
| Month-end close duration | Finance | At or near legacy baseline | Better than baseline |
| Shadow spreadsheets still in use | Ask process owners | Identified | Retired or justified |
That last row is the honest one. If the finance team still runs the old spreadsheet alongside Business Central at month three, adoption has not happened, whatever the login figures say.
What actually happens at go-live?
Go-live is a scheduled cutover, usually across a weekend or at period end. Final balances are loaded and reconciled, the legacy system is set to read-only, and the first transactions are processed under supervision. Hypercare follows for two to four weeks, with the implementation team resolving issues within hours rather than days.
A cutover runbook
Times are illustrative for a mid-market cutover across a weekend. Yours comes out of the rehearsal.
| When | Step | Owner |
| Thu, day −1 | Final go/no-go confirmed and communicated | Sponsor |
| Fri, 12:00 | Stop new transactions in the legacy system | Process owners |
| Fri, 15:00 | Complete and post outstanding legacy transactions | Finance |
| Fri, 17:00 | Final extract from legacy system | Partner |
| Fri, 18:00 | Legacy system set to read-only | IT |
| Sat, 09:00 | Load master data and opening balances | Partner |
| Sat, 13:00 | Load open AR, AP, orders, inventory | Partner |
| Sat, 16:00 | Reconciliation pass one | Finance and partner |
| Sat, 19:00 | Corrections and reload if required | Partner |
| Sun, 09:00 | Reconciliation pass two, formal sign-off | Financial Controller |
| Sun, 12:00 | Integrations enabled and verified | Partner |
| Sun, 14:00 | User access enabled, smoke test by super-users | Super-users |
| Sun, 17:00 | Go-live confirmed and communicated to all staff | Sponsor |
| Mon, 08:00 | Floor-walking support begins | Partner and super-users |
| Mon, 12:00 | First live transactions verified end to end | Finance |
Publish this to everyone involved a fortnight beforehand, with names against every row. Ambiguity about who does what at 4pm on a Saturday is how cutovers overrun.
What hypercare covers, and what it does not
Hypercare typically covers defect resolution, urgent configuration corrections, user questions and transaction troubleshooting, with a response time measured in hours.
It does not typically cover new requirements, additional reports, extra training for people who missed the sessions, or process changes. This is where clients most often feel misled, so get it in writing before go-live rather than discovering the boundary in week two.
Timing
Go live at a period end wherever possible; it makes reconciliation dramatically simpler. Avoid your year end, your busiest trading period, and the fortnight either side of a bank holiday. And do not go live on a Friday unless the runbook genuinely requires the weekend, because problems found on Friday afternoon sit unfixed until Monday.
What happens after go-live, and what do two release waves a year commit you to?
Business Central updates on a fixed cadence, with two major release waves each year plus monthly service updates. That commits you to a permanent cycle: test your extensions and integrations in a sandbox before each wave, review new features for value, and retire customisations the platform has absorbed. Ongoing support typically costs 15 to 20% of the implementation fee annually.
The annual operating rhythm
| Period | Activity | Effort |
| February | Review the April release wave plan, identify relevant features | 1 day |
| March | Test extensions and integrations against the preview in a sandbox | 2–4 days |
| April | Release wave 1 applies. Monitor, then enable new features deliberately | 1–2 days |
| May–June | Adopt selected features, retire any customisation now redundant | Varies |
| August | Review the October release wave plan | 1 day |
| September | Test against the preview in a sandbox | 2–4 days |
| October | Release wave 2 applies | 1–2 days |
| November–December | Adopt, review the year, plan next year’s backlog | Varies |
The mistake is treating updates as something that happens to you. Two structured half-days a year of preview testing prevents the entire category of “the update broke our integration” incident.
Support models
| Model | Fit | Typical cost |
| Internal only | Large IT team with real BC skills | Salary cost |
| Partner retainer | Most mid-market organisations | 15–20% of implementation, annually |
| Hybrid | Internal super-users plus partner escalation | 10–15%, plus internal time |
| Pay as you go | Very stable, very simple deployments | Unpredictable |
The month-six review
Every implementation defers something. Book a formal review at month six to revisit the deferred backlog, measure adoption against the targets you set, and assess which new agent and Copilot capabilities are now worth switching on. Without a scheduled review, the deferred list quietly becomes the permanent list.
Why do Business Central implementations fail?
Business Central implementations fail for predictable reasons: dirty source data, no empowered internal project owner, scope added mid-build, testing compressed to protect a go-live date, and training treated as an afterthought. Almost none of these are technical failures, and almost all of them show warning signs in the first six weeks.
| Failure mode | Mechanism | The week-three warning sign | Corrective action |
| Dirty data | Migration fails repeatedly, timeline absorbs the slack | Nobody can say how many duplicate vendors exist | Pause and cleanse at source before build completes |
| No empowered owner | Decisions escalate and wait | Design questions open longer than five working days | Name one person with authority. Escalate to the sponsor |
| Scope creep | Build never stabilises, budget drifts | New requirements arriving after design sign-off | Formal change control with cost and date impact stated |
| Compressed testing | Defects reach production | UAT scripts not written by end of build | Move the date. It is cheaper than a failed go-live |
| Training as afterthought | Users work around the system | No training plan by the midpoint of build | Book training now and name super-users |
| Over-customisation | Cost and maintenance burden compound | Extension list growing past the design scope | Re-run the four-question test on every open item |
| Wrong partner fit | Misalignment surfaces late | Different people delivering than pitched | Raise it immediately and formally |
| Executive disengagement | Blockers stay blocked | Sponsor missing two consecutive steering meetings | Escalate. A project without a sponsor does not land |
Run a pre-mortem
Before build starts, get the project team in a room and pose one question: it is go-live day and it has gone badly. What happened?
People will name the real risks in ten minutes, because it is easier to explain a failure than to predict one. Write the answers down. They will be more accurate than any risk register.
A recovery worth learning from
The most common rescue engagement follows the same shape. A project stalls somewhere between build and testing. Data has failed reconciliation three times. Scope has grown. The go-live date has moved twice and confidence has gone. The fix is almost never technical. It is to stop, freeze scope, cleanse the data properly at source, rebuild the test plan around real business scenarios, and reset the date once, honestly. Projects recovered this way usually go live within eight to twelve weeks of the reset. Projects that instead push for the original date usually go live badly and spend six months recovering afterwards.
What ROI should you expect, and how do you measure it?
Independent research by Forrester found a composite Business Central customer achieved around 209% return on investment over three years, with payback in under six months. Realising that depends on baselining before you start: days to close, order processing time, DSO and reconciliation hours. You cannot claim an improvement you never measured.
Read the Forrester Total Economic Impact study at source rather than through a summary, and treat the composite organisation as a model rather than as a promise. Your return depends on your starting point.
Where the value actually comes from
- Retiring legacy systems and their maintenance. Often the largest single line, and the easiest to quantify.
- Reduced manual processing. Invoice entry, matching and reconciliation, increasingly automated by agents.
- Faster close. Days off the month-end cycle is finance capacity returned to the business.
- Error reduction. Fewer credit notes, fewer duplicate payments, fewer stock write-offs.
- Better working capital. Visibility of debtors and stock usually improves both.
- Avoided headcount. Growth absorbed without proportional back-office hiring.
Baseline before you start
Capture these in the fortnight before kickoff. It takes a day and it is the difference between a proven business case and an anecdote.
| Metric | How to measure | Typical pre-BC | Target at 12 months |
| Days to close the month | Working days from period end to sign-off | 8–15 | 3–6 |
| Days sales outstanding | Standard DSO calculation | Varies | 15–25% reduction |
| Order processing time | Order received to confirmed | Varies | 30–50% reduction |
| Hours on manual reconciliation | Ask the team, honestly | 15–40/month | 60–80% reduction |
| Invoice processing cost | Total AP cost ÷ invoices processed | Varies | 40–60% reduction |
| Stock accuracy | Count variance | 85–95% | 98%+ |
| Reports produced in spreadsheets | Count them | 10–40 | Under 5 |
| Legacy system cost | Licences, maintenance, hosting | Varies | Retired |
Present these at the month-six and month-twelve reviews. A business case that is measured gets the next investment approved. One that is asserted does not.
How do you choose a Business Central implementation partner?
Assess partners on four things: implementations delivered in your industry and country, whether the people in the pitch are the people who deliver, their data migration and testing methodology, and what post-go-live support actually includes. Ask for a reference from a project that went wrong, because how a partner handles trouble tells you more than a success story.
Twenty questions, and the answers that should concern you
| Question | A good answer sounds like | Red flag |
| How many Business Central implementations have you delivered? | A specific number, with a date range | “Hundreds” with no detail |
| How many in our industry? | Named comparable projects | Deflection to general experience |
| How many in the UK? | A clear figure and named UK team | Offshore delivery presented as local |
| Will the people here today deliver the project? | Yes, named, with availability confirmed | “You’ll be assigned a team” |
| Who is our project manager and what else are they running? | A name and an honest workload | Vagueness |
| What implementation methodology do you use? | Success by Design or a documented equivalent | “Our own approach”, undocumented |
| How many data migration dry runs are in this quote? | Three or four, explicitly | One, or unspecified |
| How do you reconcile migrated data? | Trial balance, ageing, inventory by location | “We check it” |
| Who writes the UAT scripts? | Jointly, business-led | The client, unaided |
| What happens when we need something not in scope? | A documented change process with cost and date impact | “We’ll be flexible” |
| How many training hours, and to whom? | A breakdown by role | A single number |
| What exactly does hypercare include and exclude? | Written, specific | “We’ll look after you” |
| What are your support hours and response times? | Contractual SLAs | Best efforts |
| How do you handle release waves? | Sandbox preview testing as standard | “Microsoft handles it” |
| Who maintains any extension you build? | Named, with an annual cost | Unaddressed |
| Do you recommend ISV apps over custom builds? | Yes, with reasoning | Always builds custom |
| Can we speak to a client whose project went badly? | Yes, with context | Refusal |
| What is your average project overrun? | An honest figure | “We don’t overrun” |
| What do you need from us, and how many hours? | Specific roles and weekly hours | Understated |
| What is the most common reason your projects run late? | A candid, specific answer | Blames clients generically |
The last four questions do most of the work. A partner who cannot name their own failure modes has either not examined them or will not tell you.
Reading the statement of work
Five clauses decide whether you have a fixed price or a fixed argument:
- The definition of scope, and whether it names processes or just modules
- The change control process, and who authorises cost
- Assumptions about your data quality, which is where “fixed price” quietly stops being fixed
- What triggers additional charges during hypercare
- Acceptance criteria, and who signs
Working with Business Central Partner UK
We are the dedicated Business Central team at Dynamics Square, with 14 years in the Microsoft Dynamics ecosystem, more than 500 implementations delivered, and experience across 12 industries including manufacturing, distribution, retail, construction, professional services, and food and pharma.
We deliver from the UK, we run the methodology described in this guide, and we will tell you before you sign if your data is not ready, because the alternative is a project neither of us enjoys.
If you want a straight answer on timeline and cost for your situation, book a scoping call. Bring your customer and vendor lists. We will tell you what we see.
Business Central implementation FAQs
Can I implement Business Central myself?
Only if you are a small organisation with standard finance processes, no integrations and someone internally who has implemented an ERP before. The parts that go wrong are design decisions such as inventory costing method and dimension structure, which are effectively permanent once transactions post.
How long does a Business Central implementation take?
A single-entity implementation with standard processes takes 8 to 12 weeks. A mid-market project with integrations takes 4 to 6 months. Multi-entity or manufacturing implementations take 6 to 12 months. Data quality and decision speed affect the timeline more than company size does.
How much does Business Central implementation cost in the UK?
Implementation services typically cost £20,000 to £60,000 for a simple single-entity rollout and £60,000 to £150,000 for a mid-market project with integrations. Multi-entity and manufacturing projects start around £150,000. Licensing is charged separately per user per month.
What is the difference between Essentials and Premium?
Essentials covers finance, sales, purchasing, inventory, projects and warehouse. Premium adds manufacturing and service management. You cannot mix the two in one tenant, so if any part of the business needs manufacturing, everyone is on Premium.
Can Business Central handle multiple companies?
Yes. Business Central supports multiple legal entities in one tenant, with intercompany transactions, consolidation and per-entity localisation. Multi-entity rollouts work best using a template configuration proven in a pilot entity, then deployed to the rest.
Do I need to migrate historical data?
Usually 12 to 24 months of posted transactions is enough for comparatives and for giving AI agents a pattern to learn from. Beyond that, cost rises sharply and value falls. Keeping the legacy system read-only satisfies audit more cheaply than migrating years of history.
What is hypercare?
Hypercare is the intensive support period immediately after go-live, typically two to four weeks, when the implementation team resolves issues within hours. It normally covers defects and user questions but excludes new requirements and additional training, so confirm the boundary in writing.
How often does Business Central update?
Business Central receives two major release waves a year, in April and October, plus monthly service updates. Updates apply automatically to online tenants, which is why testing extensions and integrations in a sandbox before each wave is standard practice.
Will an update break my customisations?
Configuration is unaffected by updates. Extensions can be affected when Microsoft changes underlying functionality. AppSource apps are tested by their publishers; per-tenant extensions are your responsibility, which is why regression testing before each release wave belongs in your support arrangement.
Can Business Central replace my CRM?
Business Central includes basic contact and opportunity management, which suits smaller sales operations. Organisations with a real sales function usually keep a dedicated CRM and integrate it, most straightforwardly Dynamics 365 Sales, which connects natively.
How do I move from Dynamics GP to Business Central?
Microsoft provides migration tooling for core master data. Balances and open items are extracted and loaded. Everything else, including customisations, reports, workflows and security, is rebuilt. Microsoft has confirmed GP support ends 31 December 2029, with security patches ending 30 April 2031.
Is Business Central good for manufacturing?
Yes, with the Premium licence, which adds production orders, bills of materials, routings, capacity planning and machine centres. Complex manufacturing often adds an AppSource app for advanced scheduling or quality management rather than custom development.
What are Business Central AI agents?
Agents are autonomous features that carry out multi-step tasks inside Business Central, such as the Payables Agent, which reads incoming invoices, matches vendors, categorises them and prepares them for approval. They learn from patterns in your existing data, so data quality determines how well they work.
Do I need to buy Copilot Credits?
Base Copilot capability is included with every Business Central online licence. Copilot Credits cover additional AI consumption and are bought pay-as-you-go or pre-purchased. Consumption depends on how heavily you use agents and generative features rather than on user count.
Does Business Central support e-invoicing?
Yes. Business Central includes an e-document framework covering invoice exchange and, since the 2026 release wave, shipment and transfer documents. If you trade into a country with a mandate, such as France’s phased B2B requirement, design for it during implementation rather than retrofitting.
Does Business Central handle Making Tax Digital?
Yes. Business Central submits VAT returns directly to HMRC once the VAT return setup and HMRC connection are configured. It is a configuration task within a standard UK implementation rather than a separate project.
How many internal people do I need on the project?
A named project owner with decision authority, a process owner per functional area, and two super-users per department. Expect 8 to 12 hours a week for process owners during design, rising to 12 to 20 during testing. Understating this is the most common planning error.
What happens if we miss our go-live date?
Moving the date is usually cheaper than going live unprepared. The costly mistake is protecting the date by compressing testing or training, which converts a schedule problem into a live operational one. Reset the date once, honestly, rather than moving it repeatedly by a fortnight.
How do I know if my data is ready?
Export your customer and vendor lists and count the duplicates. If you cannot produce those lists quickly, or you find substantial duplication, inconsistent naming or missing payment terms, cleanse before the project begins. It is the cheapest work in the whole implementation.
