When a program is in trouble, the instinct is to fire the systems integrator. It is usually the wrong first move. The problems that sink ERP programs are governance, data, and staffing, and a new SI inherits all three along with a learning curve that costs months. A rescue already runs 30 to 50% of the original budget, by one advisory firm's figure, and starting the SI relationship over adds to that number rather than subtracting from it. The moves that recover a program are re-baselining honestly, fixing the contract at the next change order, backfilling the business, standing up independent assurance, and making the steering committee govern again.
A new SI inherits the same problems and adds a learning curve
The case for replacing the SI assumes the SI is the problem. In most troubled programs it is a contributor, not the cause. Gartner predicts that by 2027 more than 70% of recently implemented ERP initiatives will fail to fully meet their original business case goals, and the common threads are weak governance, dirty data, and a business that did not staff its own side of the work. A new SI changes none of those.
A replacement also pays a learning tax. The incoming team has to read the design decisions, the configuration, the integrations, and the half-migrated data before it can add a line of value. On a program with hundreds of signed design decisions, that is two to four months of senior time billed at boutique SI rates, which KORE1's 2026 staffing surveys put at $150 to $250 an hour for Dynamics 365, $150 to $275 and up for NetSuite, and $200 to $325 and up for SAP. You pay that tax twice: once in fees, once in the schedule.
A rescue is expensive before you add any of that. Deliberate Directions, a firm that sells NetSuite rescue services, puts the cost of a rescue at 30 to 50% of the original budget. It is a single advisory firm's figure, so treat it as a planning range rather than a benchmark. The point holds either way: on a $6M program, a rescue is a $1.8M to $3M decision, and switching SIs loads months of relearning on top of it.
| Path | Governance, data, staffing fixed? | Learning curve | Added cost | Time lost |
|---|---|---|---|---|
| Replace the SI | No, the new SI inherits all three | 2 to 4 months of senior relearning | Rescue cost plus a second SI ramp-up | Relearning plus re-contracting |
| Rescue with the current SI | Yes, that is the work | None, the team knows the build | Rescue cost only | Weeks to a few months |
The table is the argument in short form. Replacing the SI keeps the three real problems and adds two new ones. Keeping the SI and fixing the program attacks the problems directly. Ultra Consultants, an advisory firm that sells rescue services, says a recovery takes several weeks to a few months, which is faster than any transition to a new SI could run.
Re-baseline from the records before you renegotiate anything
A rescue starts with an honest re-baseline, built from the source records rather than the status deck. You cannot fix a plan you do not believe, and the plan that got the program into trouble is still the one on the wall. The records that matter are the defect log, the last data load reconciliation, the change request register, the SI staffing list, the steering minutes, and the workshop attendance sheets. The warning signs those records carry, and the thresholds to read them against, are the subject of the governance pillar on the seven signs an ERP program is in trouble.
The re-baseline sets a date and a cost you can defend, not the ones the program wishes were true. Suppose a 20-month S/4HANA program is in month 14 with go-live set for month 20, and the defect log shows open severity 2 defects rising for three straight weeks while the report reads "on track." The honest baseline moves go-live out by the time it takes to clear the backlog and run a real regression cycle, and it prices the extra SI weeks at the rate in the contract. That number is the start of the rescue, and it is also the number the steering committee has to approve rather than discover.
Re-baselining is not a concession to the SI. It is the moment the business takes the plan back. Do it with independent eyes, because a baseline the SI writes alone carries the same optimism that produced the green report.
Fix the contract at the next change order, not in a dispute
A re-baseline always needs a change order, and the change order is where the contract gets fixed. You are already negotiating cost and date, so attach the governance terms the original contract lacked. Opening a dispute to force the same terms is slower, more expensive, and tends to harden both sides. The next change order is leverage you already hold.
Three clauses matter most in a rescue. Name the key personnel and require your approval before the SI replaces any of them, so the lead architect and the data lead cannot quietly leave and be backfilled with a junior. Co-own defect severity with the business, so a severity 2 cannot be downgraded to a 3 out of the executive's sight. Write data-migration acceptance criteria with a stated reconciliation tolerance, so "migration complete" means a loaded trial balance the controller has signed within a set variance, not 80% of the mapping objects built.
| Clause | What it fixes | What "done" means after the change |
|---|---|---|
| Named key personnel with replacement approval | Silent downgrade of the people who made the design decisions | No change to named roles without your written sign-off |
| Defect severity co-owned with the business | Severity drift that empties the executive view without fixing anything | A severity 2 stays a 2 until the business agrees it is not |
| Data-migration acceptance with a reconciliation tolerance | "Migration complete" that is neither loaded nor reconciled | A loaded trial balance signed by the controller inside a set variance |
These are the headline clauses. The detail of SI contract terms, and how to negotiate them at selection rather than mid-rescue, sits in the contracting articles on both sites. In a rescue you are retrofitting, and the next change order is the cheapest place to do it.
Backfill the owners, stand up assurance, and make the committee govern
The business side of the fix costs less than any contract change and does more. Three moves carry it.
Backfill the business process owners first. When a program is in trouble, the finance, order-to-cash, and supply chain owners are usually absent from design and test sessions because their day jobs win every scheduling conflict. A design signed by an IT delegate instead of the owner is a decision the business has not made, and it reopens the moment testing reaches it. The rule the site recommends is that each owner has at least half of their time freed during design and again during integration testing, with attendance tracked by name. Backfilling a controller's routine work for a few months is cheaper than the change requests that follow an absent owner.
Stand up independent assurance that reports to you, not to the program. The reviewer reads the same source records the re-baseline used and keeps reading them week to week, so the steering committee governs from evidence rather than opinion. The site's recommended budget is 1 to 2% of the program budget. A review under 1% cannot read the records deeply enough to contradict the SI, and one over 2% competes with the program for money and attention. How to run that review is covered in the assurance article; here it is one of the five rescue moves.
Reset the steering committee to govern. A committee that meets for 40 minutes and records "no escalations" has become a readout, and the decisions that belong to it, a date move, a scope cut, a contingency draw, are being made one level down. Rebuild its pack around the re-baselined metrics trended over eight weeks, write the thresholds into the governance charter, and require named sponsors to attend rather than send delegates. A program spending $1M a month generates at least one decision a month that belongs above the program manager.
Replace the SI only on structural churn, missing records, or a broken relationship
Keeping the SI is the default, not a rule. Three conditions flip it, and each is about capability or trust rather than a bad quarter.
Replace the SI when the churn is structural. A single departure is handover; losing the program manager, the lead architect, and the data lead inside a couple of quarters means the firm no longer has the team that made the program's decisions, and you are paying a new team to relearn work the SI was supposed to retain. At that point the learning tax falls due whether you switch or not, so switching to a firm you trust is defensible.
Replace the SI when it cannot produce the records you ask for. A re-baseline needs the defect log by week, the load reconciliation, the change register, and the named staffing list. An SI that cannot or will not produce them is either disorganized past the point of recovery or hiding the state of the program. Either way you cannot govern a program you cannot see, and no contract clause fixes a partner who will not open the books.
Replace the SI when the relationship has broken past repair. Rescues demand candor on both sides, and if the SI has lost the trust of the sponsor and the process owners, the honest conversations a rescue runs on will not happen. A broken relationship is a real condition, not a mood, and it is worth confirming with the independent reviewer before you act on it. When one of these three is present, a change of SI is the right call, and the re-baseline and the new contract terms become the brief you hand the incoming firm.