How to Recover a Failed ERP Implementation
Your ERP implementation has missed another deadline. The partner is asking for more budget, but your team still can't complete billing, purchasing, or month-end close in the new system. If you've gone live, those gaps may be holding up invoices, supplier payments, or financial reporting.
To recover a failed ERP implementation, protect essential operations, find the cause of the problems, and test whether the application can meet your requirements. Use those findings to decide what to keep, what to change, and how much more you're prepared to spend.
Protect billing, payments, and other essential operations
If the ERP has not gone live, keep the system you're using in place while you check whether the new ERP is ready. Reconsider the launch date if users can't complete critical processes, balances don't reconcile, or essential integrations remain untested.
If the ERP is live and disrupting operations, identify what's blocked: invoicing customers, paying suppliers, processing orders, or producing reliable financial information. Assign an owner to each affected process. If a temporary procedure is needed, document how transactions will be approved, checked, and entered into the system afterward.
For example, if invoices must be prepared outside the ERP temporarily, define who approves them, where they are recorded, and how duplicate billing will be prevented when normal processing resumes.
Pause nonessential changes while the team investigates. Urgent, controlled corrections may still be necessary to protect operations. Record what changed, who approved it, and how the result was checked.
Before returning to the old system, account for transactions entered since the switch, changes in connected systems, and any records that need reconciling. Microsoft's cutover guidance includes a rollback plan, task ownership, verification, and business approval. Your plan needs to explain how people will resume processing and what will happen to transactions entered in the new ERP.
Find out why the implementation is failing
Start with a specific failure your team can demonstrate. “The system doesn't work” is too broad to guide a correction.
Ask the person responsible for the process to walk through a transaction using data that reflects actual business activity and their normal permissions. Record where the transaction fails or produces the wrong result. Compare that result with the agreed requirement and how the system was configured.
The following examples are illustrative, not findings from a customer engagement.
What the business sees | What to investigate | Evidence to request |
|---|---|---|
Customer balances do not match the old system | Migration mappings, opening balances, and transactions entered around cutover | Reconciliation by customer, with explained differences |
Orders cannot be invoiced | Posting setup, missing data, permissions, or integration errors | A complete order-to-invoice test and the failure details |
Purchasing approvals happen by email | An omitted requirement, incorrect approval rules, or an agreed process that users cannot follow | The approved process, configured rules, and a user demonstration |
Delivery dates keep moving | Unresolved decisions, dependencies, underestimated effort, or missing skills | The remaining backlog, named owners, and estimates tied to deliverables |
Review the available material: the statement of work, requirements, change requests, design decisions, migration results, test evidence, issue log, and invoices. Interview business users as well as the implementation team. Record where their accounts differ and what evidence can resolve the disagreement.
If documentation is missing, record which requirements are unconfirmed. Agree on them with the people responsible for the process, then check whether the application supports them.
An ERP implementation audit can organize this review. Its findings should identify the issue, its business consequence, the recommended correction, and its priority. They should also identify what is working well and can be retained.
Separate application fit from delivery problems
A missing approval step, for example, might be available in the standard application but never configured. It might require an extension or a change to the approval process. If none of those options meets the business requirement at an acceptable cost, investigate whether the software is suitable.
Ask the team to demonstrate the proposed solution before approving a rebuild. Include exceptions such as a credit note, a rejected approval, or a failed integration, where relevant.
Microsoft's Dynamics 365 testing guidance calls for testing complete processes with realistic migrated data, user acceptance testing, and regression testing after changes. Check that users can complete the corrected process and that the change hasn't broken another part of the system.
Assess the partner and the software separately. If the application can support the required process but the partner hasn't delivered it, changing partners may be reasonable. If the application can't meet an essential requirement, a replacement partner needs to explain how they would address that limitation.
Decide what to repair, reduce, rebuild, or replace
Option | When to consider it | What leadership needs before approving it |
|---|---|---|
Repair the current implementation | Required processes are achievable and useful parts of the build can be retained | Defined corrections, estimates, dependencies, and acceptance tests |
Reduce or defer scope | Optional features are blocking an otherwise usable system | A smaller scope that still supports complete essential processes |
Change implementation partners | The application fits, but the current team cannot provide the necessary capability or delivery control | A transition plan, access review, and a replacement team's assessment of the existing build |
Rebuild selected areas | A design problem affects a specific process, integration, or customization | Evidence that targeted rebuilding is preferable to repeated corrections |
Replace the application | Essential requirements cannot be met acceptably, or another approach has a stronger investment case | A validated alternative and a comparison that includes migration, disruption, training, and ongoing support |
You might retain the application, replace the partner, and rebuild one integration. A complete restart needs evidence that the usable parts of the build are insufficient or too costly to retain.
Compare costs from today forward. Show previous spending separately, along with reusable assets, but base the next approval on what each option will require and deliver. Include internal staff time, testing, temporary procedures, transition costs, and ongoing support alongside consulting fees.
If the cause is still unclear, agree on what the investigation must establish and set a spending limit. Request a written finding and recommendation before approving the repair.
Put owners, costs, and acceptance tests in the recovery plan
A revised completion date needs a supporting plan. For every priority correction, record:
The affected process and business consequence.
The correction and the parts of the existing build being retained.
The accountable owner and required business participants.
Dependencies, estimated effort, and unresolved assumptions.
The test that will prove the correction is complete.
The decision or approval needed before it moves into production.
For an invoicing problem, ask a billing user to create, post, and correct invoices using normal permissions, with finance checking the resulting entries. Mark the correction complete when that test passes and finance accepts the result.
Correct source data before testing its migration, and agree on approval rules before users test them. Reserve time for testing in people's schedules so they can participate without leaving billing, purchasing, or other daily responsibilities unattended.
In progress reviews, show which processes pass their tests, which balances reconcile, and what the remaining issues prevent users from doing. Include the next decision needed from leadership and the consequence of delaying it.
Prove readiness before another go-live
For a delayed launch or substantial relaunch, define the conditions that must be met before the business switches over.
Microsoft's go-live checklist covers agreed scope, completed testing, data migration validation, external dependencies, training, and support readiness. It also calls for testing with migrated data and the correct user security roles, with business sign-off.
Ask finance to sign off on the reconciled balances and process owners to accept the test results. Confirm how integration failures will be detected and who will respond if a critical process stops after launch.
Document unresolved issues, their consequences, and any accepted temporary procedures. The person authorizing go-live should understand what remains unresolved and why operating with it is acceptable.
Let users test the fixes before retiring their workarounds
Ask users who experienced the failure to test the corrected process. Show them how the problem was addressed, provide instructions for their role, and give them a clear route for reporting errors.
Retire a workaround after its replacement has been demonstrated and the affected records have been reconciled. If people still maintain a spreadsheet, ask what it provides that the ERP does not. It may expose a missing report, an unresolved exception, or a control that the recovery team overlooked.
Check whether purchase approvals are being recorded in the ERP and whether invoices can be processed without separate calculations. If users still need another tool, investigate the reason before asking them to stop using it.
How Highlight Health recovered a stalled Dynamics 365 implementation
Highlight Health brought Alliason into a stalled Dynamics 365 Customer Service implementation that did not reflect its claims process. An assessment identified what could be retained and what needed to change. Alliason established documented requirements and a backlog, then rebuilt the application around the claims workflow, with documentation and training for handoff.
The Highlight Health customer story describes a Customer Service recovery, not an ERP implementation. The team retained the existing platform and corrected the build to support the claims process.
Questions leadership should ask before approving recovery
Can a failed ERP implementation be recovered without starting over?
Yes, if the application meets the essential requirements and enough of the existing build can be retained. Ask the assessment team to identify those parts and explain the cost of repairing them compared with rebuilding.
How long does ERP implementation recovery take?
You need a diagnosis before you can trust the schedule. Correcting an approval rule may require far less effort than rebuilding an integration and reconciling migrated balances. Ask for a schedule that includes each correction, its dependencies, and time for business users to test it.
Should we replace the implementation partner?
Consider whether the partner can explain the failures, provide the required skills, and deliver against a credible correction plan. If a change is necessary, confirm company access to environments, administrative accounts, data, documentation, and the relevant code or extensions. Review contractual rights and handover obligations before arranging the transition.
What should an independent assessment deliver?
It should explain what's causing the problems, what remains usable, what to address first, and what still needs investigation. An Alliason Assessment reviews an existing Business Central or supported Dynamics 365 application; changes to the application are a separate engagement. If another partner continues to lead implementation, Client-Side Advocacy can help your team review scope, design, cost, and other decisions before approving them.
Find out what needs to change before approving more spending
Bring Alliason the problems your team is facing with Business Central or Dynamics 365, along with the available requirements, test results, and delivery documentation. We can help identify what can be retained, what needs attention, and whether the proposed next step addresses the cause of the failure.
