When an ERP or Salesforce program is in trouble, the first instinct is to look at the platform. Is the configuration wrong? Is the customization out of control? Did the partner understand the product?
Sometimes. But on the programs that reach the point of needing a rescue, the platform is rarely where the time went. The time went into the work around it: the integrations nobody scoped properly, the data migration that will not reconcile, the legacy system with no API, and the sync that works in testing and drifts apart in production.
This article is about ERP project rescue and Salesforce project rescue from that angle – the integration and data layer where most of these programs actually stall. For the general warning signs and the shape of a rescue, see our guide to software project rescue.
Why the platform usually is not the problem
Salesforce partners rarely lose deals on Salesforce, and ERP firms rarely lose them on the ERP. They lose them on the sentence that comes after: the ERP has to stay in sync, the billing platform owns invoicing, the warehouse system has no API, we have fifteen years of customer records.
That work is adjacent to the platform practice, technically unlike it, and almost always on the critical path. It is also the work most often left until late, because it depends on decisions about the platform that are still being made. By the time it starts in earnest, the go-live date is already fixed.
Five symptoms and what they usually mean
| What you see | What it usually means | First move |
|---|---|---|
| Go-live keeps moving, but configuration is “nearly done” | Integration and migration were scheduled after build, and are now the critical path | List every interface and migration object with an owner, a status and evidence |
| Test cycles fail on data, not on functionality | Migration has not been rehearsed against full production volumes | Run a full-volume rehearsal and reconcile the results, even if it fails |
| Numbers differ between the CRM and the ERP | No agreed system of record per object, or no conflict rules for two-way sync | Write down which system owns each object and field before fixing code |
| Interfaces work in test but fail intermittently | No idempotency, retry or dead-letter handling; failures are being rerun by hand | Instrument the interfaces and count failures before changing them |
| The client is asking for more status meetings | Confidence has gone before anyone has written it down | Produce one honest status, with evidence, and agree it with the client |
None of these is fixed by adding more platform consultants.
The first week of an integration-led rescue
Build the interface inventory
Every integration and data flow: source, target, direction, mechanism, frequency, volume, owner, test status and production evidence. On troubled programs this list often does not exist, or exists in three versions that disagree. Building it is the single most useful thing a rescue team does in week one.
Establish the systems of record
For accounts, contacts, products, prices, orders, invoices and payments, decide which system owns each object – and, for two-way sync, which owns each field. Most “sync bugs” on rescued programs are not bugs. They are two systems both being told they are the source of truth.
Rehearse the migration for real
A migration that has only been tested with a sample is not tested. Run the full volume, measure how long it takes against the cutover window, and reconcile the result: record counts, financial totals and a sample of records checked by the people who use them. The first full rehearsal usually reveals the real plan.
Measure before fixing
Count the failures each interface produces, how they are discovered, and how they are recovered. If the answer is “someone reruns it”, the interface needs idempotent processing, retries and dead-letter handling before anyone adds features to it.
Decide what to stop
Some integrations are unrecoverable in their current form; some are not needed for go-live at all. A rescue that cannot recommend stopping or deferring scope is not a rescue.
What the recovery plan has to include
A credible recovery plan for an ERP or Salesforce program has specific integration content, not just revised dates:
- An interface-by-interface plan with acceptance criteria that include reconciliation between systems.
- A migration plan with a rehearsed timeline, validation reporting the client can sign off against, and a rollback path.
- A cutover plan that names who does what, in which order, with go/no-go criteria.
- Operational readiness: monitoring, alerting and runbooks for every interface, so the first production failure is noticed by the team rather than by the client.
- End-state conditions that define done, with responsibilities held by both the rescue team and the client.
Who should lead it
The platform partner usually still owns the configuration, the advisory relationship and the client – and in most rescues that should not change. What changes is who owns the integration and data layer. That needs someone with the authority to make trade-offs across systems, and the experience to tell which interfaces to fix and which to replace.
If you are the platform partner, the rescue can run under your brand. Your client sees your firm arriving with reinforcements, not a replacement.
Related reading
- Software project rescue: warning signs and what a real rescue looks like
- NetSuite Salesforce integration: keeping CRM and ERP in agreement
- How to scope integration work in a statement of work
How eProxim helps
eProxim works on one side of a clear line: everything outside the platform. We do not run Salesforce or ERP implementation practices and do not bid against the partners who do. We build and repair what connects the platform to the rest of the business – ERP and CRM synchronization, middleware for systems that were never designed to integrate, event-driven interfaces, and data migration with validation reporting.
On at-risk programs we respond the same business day, start with a one-day deep dive, and propose a rescue only with specified end-state outcomes. We have taken over delivery leadership when the situation needed it – including a consumer travel portal that had shipped nothing in two years, where we stood up a 125-person offshore team and delivered.
If your client’s program is already going wrong, the useful day to call is today. See project rescue services, our services for Salesforce partners, or start a partner conversation.