The worst possible place for an ERP programme to stop is halfway. In 2008 and 2009, that is exactly where a large number of them stopped. The macro numbers explain the decisions. Global IT spending fell in 2009 — Gartner described the drop-off as worse than the one that followed the dot-com bust, with spending down to roughly $3.2 trillion after 6.1 percent growth in 2008, and at one point the firm was forecasting a decline of around six percent for the year. Capital committees stopped approving anything that was not already generating cash. What that looked like inside a multi-year ERP programme was a phone call in which someone senior said: pause it, we will restart when things improve. It sounded prudent. In most cases it was the most expensive decision available.
What a Frozen Implementation Actually Costs
A paused ERP rollout does not go dormant. It goes into a state that costs money every month while producing nothing. A typical freeze in early 2009 left an organization with three sites live on the new system, eleven on the legacy platform, and an interface layer built to keep them talking to each other. In that state:
- Two systems run in parallel. Two sets of infrastructure, two sets of licences, two support arrangements, two sets of month-end procedures, two charts of accounts that must be reconciled by hand.
- The integration layer becomes permanent. Middleware built as temporary scaffolding for a transition acquires its own support requirement, its own failure modes, and nobody's ownership.
- Consolidated reporting gets harder, not easier. Group numbers now come from two sources with different master data. The finance team absorbs the difference as manual effort, permanently.
- Knowledge evaporates. Contractors leave within weeks. The consultants who designed the configuration move to other clients. Internal staff who understood the design get reassigned. When the programme restarts, a substantial portion of the design work has to be redone because nobody can explain why decisions were made.
- You keep paying for what you are not using. Licences bought for the full rollout attract maintenance whether deployed or not, which turns a paused programme into recurring cash outflow with zero benefit. Add those together and a freeze frequently costs more than finishing at a reduced scope would have. The freeze feels like saving money because it stops the visible project invoices, while the invisible costs migrate into operations where nobody attributes them to the decision.
Pausing Was Not the Mistake
This needs saying clearly, because it is where most post-crisis commentary goes wrong. In a liquidity crisis, preserving cash is correct. Boards that stopped discretionary capital spending in late 2008 were doing their jobs. The mistake was pausing without a plan. There are three defensible ways to stop an ERP programme and one indefensible one, and the indefensible one was the most popular. Complete to a stable resting point. Finish the current phase to a state where one whole entity, site or end-to-end process runs on the new system and the legacy platform can be switched off for that scope. Reduced ambition, real benefit, no permanent parallel running. Unwind deliberately. Return the live sites to the legacy platform, write off the work, and run one system. Painful and honest, and cheaper than indefinite duality. Pause with a maintained plan. Document the design, retain two or three key people, keep the decision log current, set a named owner and a review date, and renegotiate vendor licensing to defer the undeployed portion. This costs real money and preserves the option. Pause indefinitely with no plan. The team disperses, documentation rots, the interim architecture becomes the architecture, and four years later someone discovers the company is running two ERPs because of a decision nobody can locate. A remarkable number of the hybrid landscapes consultants still find in 2026 date back to a freeze in 2009 that was never formally ended.
| Option | What must remain explicit |
|---|---|
| Stable resting point | The whole entity or process that can leave the legacy system. |
| Deliberate unwind | The return plan, write-off and single-system target. |
| Maintained pause | The owner, design record, retained knowledge and review date. |
| Indefinite pause | The unowned interfaces and continuing dual-running exposure. |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
Recovering a Stalled Programme
If you are holding one of these, the sequence that works is not "restart where we left off."
- Re-baseline against current business outcomes, not the original business case. The original case was written for a different economy, a different organizational structure and possibly a different product set. Justify the remaining work on what the business needs now, or cancel it.
- Find the nearest stable resting point and drive to it. Half a process live is the most expensive configuration in enterprise IT. Whole processes, whole entities, whole sites — partial anything is where the cost hides.
- Quantify the cost of the current state before proposing anything. Parallel infrastructure, duplicated licences and maintenance, interface support, manual reconciliation hours, and the finance close extension. Boards approve restarts when they see the monthly cost of not restarting.
- Recover the design knowledge first. Reconstruct the configuration rationale and decision log before technical work resumes. Teams that skip this spend the first three months rediscovering their own choices.
- Cut the customisation backlog hard. Most deferred customisations were requested by people who have since left, for processes that have since changed. Re-justify each one or drop it.
- Renegotiate with the vendor from a position of fact. Undeployed licences, deferred modules and maintenance on shelfware are all negotiable when you are re-committing to a programme.
- Set a governance rule for the restart: no phase begins without a named business sponsor, funded resources through completion of that phase, and a defined stable end state. This is the rule whose absence caused the original mess.
The Version of This Happening Now
The pattern recurs every time budgets tighten, and the current instance is cloud ERP migration. Organizations partway through moving off a legacy suite, under a vendor end-of-maintenance deadline, are running the old and new platforms side by side with integration debt accumulating between them. If that programme gets frozen for a budget cycle, the outcome will be identical to 2009: two systems, one reconciliation burden, dispersed knowledge, and a vendor deadline arriving regardless. The only reliable protection is to plan every phase so it ends somewhere you could stop permanently without paying for two of everything.
Common Questions
Is it cheaper to pause or finish an ERP implementation?
Usually cheaper to finish to a stable resting point. Pausing mid-rollout creates parallel infrastructure, duplicated licences, permanent integration overhead and manual reconciliation — costs that continue monthly while no benefit is delivered.
What is a stable resting point in an ERP rollout?
A state where a complete entity, site or end-to-end process runs on the new system and the corresponding legacy scope can be decommissioned. Partial processes are the expensive configuration.
How do you restart a stalled ERP programme?
Re-baseline the business case against current needs, quantify the cost of the current hybrid state, recover the design rationale, cut the customisation backlog, renegotiate vendor terms, and restart only with funded phases that each end in a decommissionable state.
How much does dual-system running cost?
It varies, but the recurring components are consistent: duplicate infrastructure and licences, maintenance on undeployed modules, interface support, extended finance close, and manual reconciliation effort. Measure it monthly — it is usually larger than the project spend that was saved.
Project Recovery Assessment — Outpace quantifies what your stalled or hybrid ERP landscape costs every month, identifies the nearest point at which a legacy system can actually be switched off, and builds the restart plan and business case to get there.