Almost every stalled ERP or Dynamics 365 programme has been re-planned at least once before anyone calls it a recovery.
But changing the plan does not fix a programme when the underlying problem is structural.
The first job in ERP programme recovery is to establish the real position: what has actually been built, what has been tested, what remains uncertain, and whether the organisation is capable of describing the work left with confidence.
Only then should a new delivery date be agreed.
When does an ERP programme need recovery?
Being late does not necessarily mean an ERP programme is broken.
Programmes run late for ordinary reasons. A data source arrives in worse condition than expected. A key person leaves. An integration turns out to be considerably more complicated than originally understood.
Those programmes can often recover once the obstruction is removed. The right response may simply be to revise the plan and continue.
A structurally troubled programme behaves differently.
The delivery date moves repeatedly, often by similar amounts. Testing keeps uncovering the same type of defect rather than progressively reducing risk. Nobody can state clearly what remains to be built.
The sponsor, delivery team and business users may all describe the remaining scope differently — and each description may be sincere.
The reliable signal is not the size of the delay. It is whether the organisation can describe what remains with confidence.
If it cannot, producing another project plan normally creates another version of the same problem.
Warning signs that an ERP programme is in trouble
Several signals tend to appear when an ERP implementation has moved beyond an ordinary delivery delay.
- The same defects keep returning after being closed. This can indicate that environments, configuration or data are not sufficiently controlled.
- Requirements are still being clarified during development. Design decisions are then being made under delivery pressure rather than through a controlled design process.
- Cutover has never been rehearsed end to end. The migration approach exists on paper but has not been proved in practice.
- Business users have stopped engaging. Reduced attendance is often a sign of withdrawal or loss of confidence rather than satisfaction.
- Progress is described as a percentage complete. Nobody can translate that percentage into finished, tested and accepted functionality.
- The supplier relationship has become contractual. Both parties are spending more effort protecting their position than solving the delivery problem.
- Each revised go-live date is based on another estimate rather than new evidence.
One warning sign does not necessarily mean the programme requires recovery.
When several appear together, adding more effort or producing another plan is unlikely to solve the underlying problem. The priority should be to re-establish the facts.
Can a stalled ERP implementation be recovered?
Most troubled ERP programmes are not failing because every part of the implementation is wrong.
Usually, some parts are complete, some are recoverable and others need redesigning or removing from the immediate scope.
The first recovery decision therefore should not be:
When can we go live?
It should be:
What is actually true today?
Before deciding whether to continue, reset or significantly change the programme, sponsors need reliable answers to questions such as:
- What functionality has actually been built?
- What has passed meaningful testing?
- Which integrations work in a controlled environment?
- How repeatable is the data migration?
- Which requirements are genuinely required for go-live?
- Which decisions remain unresolved?
- What assumptions are still being treated as facts?
- Is the current delivery model capable of completing the programme?
Without those answers, deciding whether a programme can be recovered is largely guesswork.
A five-step ERP programme recovery process
The instinct in a stalled programme is usually to fix the most visible problem first.
That is often the wrong starting point because the visible problem may simply be the consequence of something further upstream.
We approach ERP programme recovery in a specific order.
1. Establish the true position
First determine what exists today.
That means separating work into categories such as:
- built and tested;
- built but not adequately tested;
- designed but not built;
- partially complete;
- assumed to be complete;
- not yet understood.
This is evidence gathering, not opinion gathering.
The purpose is to create a version of the programme that everyone can recognise and verify.
2. Stabilise environments and data
Testing is only meaningful if the environments and data behind it are controlled.
If builds cannot be reproduced, configuration changes are unclear or test data changes constantly, it becomes difficult to distinguish genuine defects from environmental problems.
The same applies to migration.
A data migration plan is not evidence that migration will work. The process needs to have been run, measured, corrected and repeated.
Until environments and data are stable, estimates based on testing results should be treated cautiously.
3. Re-baseline the scope
The next step is to separate what the organisation genuinely needs to go live from what it would eventually like the ERP platform to provide.
When programmes struggle, those two categories often become mixed together.
Recovery may require moving desirable functionality out of the initial release so the organisation can establish a stable core platform before extending it.
That is not necessarily a reduction in ambition. It is a change in sequence.
4. Restore clear decision-making
ERP programmes slow quickly when nobody has the authority to settle design questions.
Every significant decision should have a named owner who can make or escalate that decision within an agreed timeframe.
A question that remains unresolved for three weeks can create considerably more downstream work than the original issue itself.
Recovery therefore requires clear decision rights as much as it requires technical control.
5. Agree a new delivery date
Only once the position, scope, environments, data and governance are understood should the programme agree another delivery date.
That date should be supported by evidence and delivery gates rather than by pressure to provide a milestone.
Skipping directly from recognising a problem to announcing another go-live date is one of the most common mistakes in programme recovery.
A new date based on unverified information is simply another version of the commitment that created the current position.
What should be stabilised first?
ERP recovery normally involves several problems at the same time, but they should not all be treated equally.
A sensible order of attention is usually:
ScopeConfirm what must exist for go-live and what can follow later.
EnvironmentsMake sure configuration and deployments are controlled and reproducible.
DataProve that migration can be repeated reliably and that ownership of data quality is clear.
TestingUnderstand what has actually been tested, under what conditions and with what evidence.
IntegrationsConfirm not merely that interfaces have been designed, but that they operate reliably across realistic end-to-end scenarios.
GovernanceMake sure decisions have owners and unresolved issues cannot remain open indefinitely.
CutoverRun the process rather than relying on the existence of a cutover document.
These areas are connected. Weakness in one can make the others appear healthier than they really are.
Dynamics 365 programme recovery
The same recovery principles apply to Dynamics 365 programmes, but several areas frequently deserve particular attention.
Environment management is one of them. Configuration and development moving inconsistently between environments can make defects difficult to reproduce and testing difficult to trust.
Data migration is another. A successful sample load is not the same as a repeatable production migration.
Integrations also require careful examination because apparently small interface issues can affect several business processes at once.
For Dynamics programmes, we normally want to understand:
- environment and deployment control;
- solution and configuration management;
- integration ownership;
- migration repeatability;
- end-to-end testing;
- security and role design;
- business process readiness;
- cutover preparation;
- ownership between the customer, Microsoft partners and other suppliers.
The aim is not to start the implementation again. It is to determine which elements are sound, which need correction and which assumptions can no longer be relied upon.
ERP programme recovery is not only a technical exercise
By the time a programme is described internally as being in trouble, people are usually tired and reputations are involved.
Someone recommended the platform.
Someone approved the business case.
Someone selected the implementation partner.
Someone has been reporting progress to the board.
That matters because the information required to understand the real position is held by people who may feel exposed by the recovery process.
A recovery exercise that ignores this can fail before the technical work begins.
We therefore treat the initial assessment as a factual exercise rather than an attempt to attribute blame.
People need to be able to explain what has happened, what they know and what they do not know without first having to defend every decision that led there.
The same standard has to apply to the findings.
If the platform decision was sound but the implementation approach was not, that should be stated.
If the original requirement could not realistically have been delivered within the budget or timescale available, that also needs to be made clear.
ERP recovery only works when uncomfortable information can reach the people making the decisions.
Should you change implementation partner during an ERP recovery?
A stalled programme does not automatically mean the implementation partner needs to be replaced.
Changing partner introduces its own risks, including knowledge transfer, commercial negotiation and further disruption.
But the question should be considered where the existing relationship prevents effective recovery.
The important distinction is between a programme that has delivery problems and a delivery model that can no longer solve them.
A recovery assessment should make that visible.
Sometimes the correct answer is to retain the existing partner with stronger controls and clearer responsibilities.
Sometimes responsibilities need to be redistributed.
And sometimes a programme cannot move forward effectively without changing the delivery arrangement.
That decision should follow the evidence rather than precede it.
What successful ERP recovery should leave behind
An ERP recovery is not finished simply because the system eventually goes live.
It is finished when the organisation can operate and develop the platform without depending permanently on the recovery team.
That means the controls introduced during recovery need to be sustainable.
In practice, the organisation should be left with:
- controlled and documented environments;
- repeatable deployment processes;
- a proven data migration approach;
- a rehearsed cutover;
- a defect process understood by both IT and the business;
- clear ownership of decisions;
- reporting based on finished and tested work rather than effort;
- an understood backlog for anything deliberately moved beyond go-live.
Anything that only works while the recovery team remains in place is not a recovery.
It is a dependency.
ERP programme recovery: key points
If an ERP or Dynamics 365 programme is repeatedly slipping, the next step should not automatically be another re-plan.
The important questions are whether the organisation understands the true position and whether the information behind the new plan can be trusted.
A successful recovery should:
- establish verified facts before agreeing another delivery date;
- stabilise environments and data before relying on testing;
- separate essential go-live scope from future requirements;
- restore clear ownership and decision-making;
- prove migration and cutover through rehearsal;
- address commercial and organisational problems as well as technical ones;
- leave the internal team capable of operating the platform after recovery.
Need the real position before the next board meeting?
If your Dynamics 365 or ERP programme is repeatedly slipping, we can establish what is actually happening, identify the decisions that need to be made and set out the available recovery options.
That includes options that do not involve us delivering the subsequent work.
