The business stops bleeding
Critical workflows are hardened. Manual workarounds get retired or formalised. Operations stop running on hope.
When the implementation has gone sideways,
The first move is stabilisation, not a rewrite.
We audit, triage, and harden the system. Then the rebuild decision is yours to make — on evidence, not on panic.
We don't touch the whole system. We triage, then we stabilise.
Critical workflows are hardened. Manual workarounds get retired or formalised. Operations stop running on hope.
Forensic audit, written documentation, observability, deploy hygiene. The system stops being a black box.
The previous build is not thrown out reflexively. The audit tells you what is salvageable; the rebuild conversation comes later, on evidence.
Stabilisation in weeks, decision-grade assessment in writing. No "give us another year" pitch.
When a project has gone wrong, the loudest options in the room are usually the worst ones.
Operations are limping. The previous vendor has gone quiet or defensive. Internally somebody is pushing "rebuild it from scratch." Externally another consultancy is pitching the same. Both ignore the fact that whatever is running, however badly, is the thing the operation now depends on — and that ripping it out without first understanding what it does will create a second outage on top of the first. Meanwhile every week of delay deepens the operational risk: workarounds entrench, the staff who remembered the original intent leave, and the parts of the system that are quietly degrading get closer to a public failure.
A contract-size decision dressed up as a technical one.
The previous vendor's documentation is rarely accurate.
The business is running on undocumented spreadsheet bridges and Slack approvals.
Every week the diagnostic is delayed, the price of the eventual decision rises.
The first job is to stop the bleeding so the decision can be made calmly.
The first job isn't to decide what to do.
Each appears in leadership meetings long before anyone says "we need to bring someone else in."
Tickets go unanswered. Calls don't get returned. The relationship has effectively ended without being formally closed.
The original PM left. Documentation is partial. Current operators know their part; nobody knows the whole.
What was supposed to be automated is being done in spreadsheets, in chat, in someone's head. Operations risk is invisible to the dashboard.
When something fails it isn't always obvious; sometimes it's discovered weeks later when a report doesn't reconcile.
Status updates have stopped being technical and started being political. The answer being asked for is "what do we do now?"
Another consultancy has pitched a 12-to-18-month rewrite at multiples of the original cost. The number landed and nobody knows whether it is right.
These aren't six independent problems. They are six symptoms of one situation: the implementation has stopped being managed, and the cost of every option is rising while the diagnostic hasn't been done.
Failed implementations don't usually fail in a single moment. They get worse in patterns. The patterns are not technical surprises. They are operational ones.
Throwing out a system that still contains real business logic because the code looks ugly. The business logic survives the rewrite as scope creep anyway, but the timeline doesn't.
Decisions made on the previous vendor's documentation, on the loudest internal voice, or on a competitor's sales pitch. None of those are the actual state of the system.
Going directly from "it's broken" to "let's redesign" without first hardening the parts that the business is currently running on.
Onboarding the new team without first extracting what the previous one knew. The new team relearns the same domain at the same cost.
Either treating the previous spend as throw-away (and over-rebuilding) or treating it as untouchable (and refusing to retire genuinely bad parts).
Making the rebuild-or-keep call while the system is actively on fire, instead of after the fire has been contained.
The rescue vendor proposes a scope that maximises their contract, not one that minimises the client's risk.
Failed implementations get cheaper to recover from with each week of calm. They get more expensive with each week of panic.
Every rescue engagement that turned out well had the same starting move.
The first 30 days were spent stabilising and diagnosing — not rebuilding.
The temptation, on both sides of the table, is to start "fixing" inside the first week. That impulse is what turned the original implementation into a rescue case in the first place. Stabilisation buys the calm in which the right decision becomes obvious.
Failed implementations rarely need to be rebuilt. They need to be stabilised first.
Four principles separate rescue work that lands from rescue work that just becomes the next problem.
A written forensic audit before any structural change. The audit answers four questions: what does the system actually do, what is at immediate risk, what is salvageable, and what is genuinely broken beyond repair.
Targeted hardening of the at-risk parts first. Backups, observability, error handling, secrets, deploy hygiene. The long-term direction decision comes after the operation is no longer running on the edge.
Knowledge reconstruction is part of the engagement, not an afterthought. The written record of what the system does is a deliverable, not a side effect.
The rebuild-or-keep decision is made after the audit, in writing, with options costed. It belongs to the client, not to the next vendor pitching for the bigger contract.
Four honest blocks: how we work, the phased cadence, the triage architecture, and what we will not do.
Architecture, data model, integration points, deployment, observability, security, debt. Written report at end of week 2.
Risk-ranked list of what to stabilise, with cost and timeline. Client approves scope before any structural work.
Targeted hardening on the approved scope. Backups, observability, error handling, secrets, deploy hygiene. Operations stop bleeding.
Documentation of what the system actually does, derived from the code and operation. Delivered as a written record, not a slide deck.
Written assessment of what to keep, refactor, retire, or rebuild. Options costed. The decision belongs to the client.
An Implementation, Modernization, Long-Term Support, or Dedicated Teams engagement — if and only if you choose.
Modules tagged critical (stabilise this week), at-risk (stabilise this month), or stable (leave alone for now). Stabilisation scope is the critical and at-risk tiers. The stable tier waits for the decision-support assessment, which is where its future is actually decided.
Four outcomes plus the six numbers we measure before declaring a rescue engagement complete.
Critical workflows are hardened, observability exists, manual workarounds are documented and retired or formalised. Operations risk drops in weeks, not quarters.
Written documentation of what the system actually does. The codebase is no longer a black box; the next decision can be made on evidence.
A structural decision is made after the operation is stable, on a written assessment with costed options, not under emergency pressure.
Where the previous build contains real business value, it is preserved. Where it doesn't, it is retired explicitly. Either way, the decision is intentional.
Each measurable. Each tied to the operating reality, not to a status slide. The mean-time-to-detect metric typically moves from weeks to hours over the stabilisation phase — that single number tells leadership whether the operation is being managed or just observed.
A rescue engagement is the right move when an implementation has gone sideways, leadership is willing to spend 30 days on diagnostic before structural commitment, the business has operational continuity needs that make "throw it out and rebuild" genuinely risky, or a previous vendor relationship has ended or stalled and somebody needs to take over the codebase responsibly.
It's too early when the implementation is still in active build with the original vendor — talk to them first. Or when leadership has already committed publicly to a full rebuild and wants only an execution vendor — that's an Implementation engagement, not a rescue. Or when the "failure" is a single bug or single bad release — that's a support engagement, not a rescue.
A rescue engagement converts to a follow-on roughly one in three times — the rest hand back to the client's internal team or to a vendor of the client's choice. That ratio is on purpose; rescues that always convert to follow-ons aren't rescues, they're sales pipelines. This ratio is currently pending leadership confirmation before publishing externally.
A typical rescue engagement runs 12 to 16 weeks end-to-end. Four phases. Each phase ends with a written deliverable, not a status meeting.
Architecture, data model, integration points, deployment, observability, security, debt. Output: written audit report.
Risk-ranked stabilisation scope, cost and timeline. Client approves before any structural work begins.
Targeted hardening on the approved scope. Documentation in parallel. Operations stop bleeding.
Written, costed options memo. Keep, refactor, retire, or rebuild. The decision is yours.
Recovery isn't heroics. It's the discipline that turns a project in crisis back into a project that can be decided on calmly.
Six engagement and engineering non-negotiables. Each is the floor, not the ceiling.
No rewrite, no redesign, no major refactor before the written audit is delivered and the client has read it.
A risk-ranked list with cost and timeline. Stabilisation scope is approved in writing, not assumed.
Only the at-risk parts get touched in the stabilisation phase. The stable parts wait for the decision-support assessment.
Written documentation of system behaviour is part of every engagement, not a side effect.
At end of stabilisation, a costed options memo. Keep, refactor, retire, rebuild — each option with a number. The decision belongs to the client.
The rescue engagement is priced and delivered as itself. Any follow-on is quoted separately and is the client's free choice.
Direct answers for leaders whose implementation has gone sideways.
Yes. That is one of the most common starting points for a rescue engagement. The first two weeks are a forensic audit of the codebase as it currently exists; we don't need the previous vendor's cooperation to do that, though we will request whatever documentation, credentials, and access you legitimately hold.
Full rebuilds are less common than buyers expect. More often the audit recommends a mix: keep the parts that work, refactor a few, retire one or two, harden the rest. The decision is yours; the audit gives you the evidence.
2 to 4 weeks depending on system size and complexity. The written report is delivered at the end of that period. Stabilisation work, if approved, begins immediately after.
The audit is typically a fixed-price engagement scoped to system complexity. Stabilisation is scoped after the audit and depends on what the triage reveals; typical stabilisation engagements run 6 to 10 weeks. Concrete pricing ranges are confirmed in the consultation conversation; we don't publish numbers on this page until they have leadership sign-off.
Then we say so, in writing, with costed options. The rebuild engagement is quoted separately under Implementation or Custom Applications. You are free to use us, another vendor, or your internal team for that next phase. The audit is the audit; it is not a sales document.
Also happens. Sometimes the system is fundamentally sound and what looked like a vendor problem was an operations problem, a training gap, or an integration issue. The audit will say so. The honesty is part of how the engagement actually works.
Yes, with care. The handover needs to be clean — credentials, code, documentation, customer data — and the previous vendor's contract needs to be wound down properly. We will work with you on the transition; we will not work around an active contract you haven't formally ended.
Often the better engagement type. A targeted audit plus stabilisation of one subsystem can run in 4 to 6 weeks total. Talk to us; we'll be honest about whether you need a full rescue or just a focused intervention.
Yes. Standard. The audit deliverable includes sensitive operational information about your business; we treat it accordingly.
We don't quote a "success rate" because the success metric for a rescue varies (stabilised and kept, stabilised and rebuilt, stabilised and handed back). What we'll say honestly: approximately one in three rescue engagements converts into a follow-on engagement with us. The rest hand back stable to the client or to another vendor. That ratio is on purpose; rescues that always convert to follow-ons aren't rescues, they're sales pipelines.
System Rescue starts with a 2-to-4-week forensic audit, not a rewrite. The audit produces a written report on what the system actually does, what is at immediate risk, what is salvageable, and what is genuinely broken beyond repair.
Most failed implementations do not need a full rebuild. The previous build typically contains six to twelve months of business logic, integration mappings, and customer-specific configuration that the operation now depends on. Stabilisation honours that sunk cost; reflexive rebuild ignores it.
A typical rescue engagement runs 12 to 16 weeks end-to-end: 2 weeks audit, 2 weeks triage, 6 to 10 weeks stabilisation, decision-support assessment at the end.
Audit first. No rebuild pitch in week one.