ERP failures often look like software problems. Public reviews point to a wider cause. Ownership is unclear, test work starts late, or key staff are stretched too far. An Australian government review found that 30 GovERP functions had been built. Only 18 had finished basic testing, and none had reached system integration testing, user acceptance testing, or production. The GovERP reuse assessment linked the weak result to scope shifts, unclear ownership, and uneven stakeholder input. That pattern matters for any Business Central rollout because the software can be ready while the business is not.
The first failure often happens before the system is built
A late ERP project may show bad data or missing features. The cause can sit much earlier in the plan. Teams may enter the build with open process choices and weak sign-off rules. Key users may join only when testing begins. By then, a small gap can force design changes and repeat work. Calance says its Business Central process covers requirements, data work, a core team, gap checks, UAT, and cutover planning. A buyer assessing a Microsoft Dynamics 365 Business Central Partner should ask who owns each choice and when it must be closed.
Thin project teams turn normal pressure into delay
Public reviews show how staff gaps can become cost problems. Vale of Glamorgan Council planned an Oracle Fusion rollout at £1.5 million. The final go-live cost reached £5.192 million. Its review found 59 lessons, with 38 marked as priority actions. The council’s implementation review raised concerns about staff capacity, testing, data migration, and project planning. It also found heavy use of business-as-usual teams while payroll and other core work still had to run. The product was different, but the control gap can occur in any ERP project.
The root cause can be a bad estimate of staff time. A finance lead may know the old system well. That doesn’t mean the same person has time for design reviews and test work. Data checks and sign-off also need protected hours. The delivery team needs steady access to those people. Late access moves rework toward go-live, when fixes cost more time.
System links create risks that one team may not see
Business Central often connects with tools outside the ERP. Finance data may move to reporting tools, Microsoft 365 apps, banks, or warehouse systems. Each link adds a handoff. A field map can be wrong, or one team may think another team owns the test. Calance’s Microsoft 365 services page includes ERP and CRM links, data checks, cutover work, and integration testing. This matters because the ERP screen can look right while a connected process is still failing.
A 2026 National Audit Office review shows the size of this risk. It reported £1.15 billion in UK government funding for shared services. Costs incurred since 2020 stood at £459 million. The work affected 470,000 civil servants as of October 2025. The NAO also found at least 25 other digital change programmes that could affect delivery. Its shared-services review said control of these links had been weak. The lesson is simple: cross-system risk needs one clear owner with enough detail to act.
Testing must follow real work from start to finish
UAT can turn into a late box-ticking task when the schedule is tight. Good tests follow real work from entry to final result. They need real user roles and known pass rules. They should also cover errors, access rights, month-end work, and recovery steps. A search for Microsoft Partner Dynamics 365 may return many firms, so buyers should ask to see the test plan and go-live rules. The useful question is whether the team can prove the process works across every needed handoff.
Microsoft gives specific controls for Business Central cloud moves. Its current guide says teams should use a sandbox for dry runs. It advises at least 2 dry runs before the final cutover. It also calls for a runbook with named owners, system links, decision gates, freeze timing, and rollback steps. The Business Central migration guidance warns that migration into a production system already in use can overwrite needed data. These checks make go-live a decision based on test results instead of a fixed date.
Contract terms and decision rights can shape the result
A partner can lower risk when problems are found early and raised fast. Scope rules also need to be clear before build work grows. If key needs stay vague, change requests can become the way old gaps are fixed. Testing may then begin while business choices are still open. Buyers should check how a provider handles scope, data ownership, UAT, change control, and support after launch. A Microsoft Dynamics 365 Partner should be able to explain who can stop cutover and what proof is needed before approval.
The evidence doesn’t support blaming the partner for every bad result. Client staffing can change the outcome. Legacy data can also add work, and outside events can cut available time. The Vale review, for example, cited pandemic pressure as one factor along with staff and design gaps. A fair root-cause review asks when a control failed and who had the needed facts. It should also ask why the decision path didn’t catch the issue sooner.
Go-live should be a control gate, not a deadline
Teams should test the work model before they trust the launch date. Each key process needs an owner and a clear pass rule. Data must be checked, and system links must be proved in test. Key users need time away from daily work during UAT and cutover. A rollback plan must be ready before the final switch. The go-live call should come from evidence gathered in dry runs and user sign-off.
What to investigate before the next rollout
ERP risk becomes easier to control when teams study handoffs before launch. They should check ownership, staff time, test depth, data quality, and system links. Those checks expose plans that depend on untested assumptions. Each key assumption should have an owner and a test. That makes the next rollout easier to judge before the business has to live with it.
Frequently asked questions
Why do ERP projects keep running late?
ERP projects often run late because open business choices reach the build stage. Data faults and weak ownership then cause repeat work. Staff shortages can add more delay near go-live. A better plan closes key choices early and gives each one an owner.
What should be tested before Business Central goes live?
Teams should test full work paths with real user roles and useful test data. They also need to test system links, access rights, error cases, and recovery steps. Microsoft advises sandbox checks and repeated dry runs before final cutover. A passed screen test doesn’t prove the whole process works.
How should a company judge an ERP partner?
Ask how the partner handles scope, data work, tests, change requests, and cutover approval. The answer should name owners and show real decision gates. Buyers should also ask what the client team must provide. Clear roles make late disputes less likely.
Why does data migration cause so many problems?
Old data often contains duplicates, missing fields, old codes, or unclear rules. A new ERP forces teams to map those items to a new structure. Dry runs help find bad records and measure the time needed. Business owners still need to decide which data is fit to move.
What is the strongest go-live control?
A formal go or no-go gate is a strong control. It should use agreed proof from tests, data checks, user sign-off, and cutover rehearsal. The owners of affected business processes need a real vote. Schedule pressure should never replace that gate.
For more info contact us or send mail at connect@calance.com to get a quote