When an integration is failing, the question that comes up quickly is whether to fix it or replace it. The replace argument is intuitive: the thing is broken, it was probably built badly, let's start fresh with something better.

The fix argument is less intuitive but often more defensible: rebuilding an integration takes longer than it looks, requires the same design decisions that were made badly the first time, and has a go-live moment that creates its own risk. A targeted rescue that stabilises what exists and addresses the root cause can be faster, cheaper, and far less disruptive.

The right answer depends on what you're actually looking at.

The case for rescue

Most integration failures aren't caused by fundamental architectural problems. They're caused by something specific: a data mapping that was wrong from the start, an assumption about input formats that stopped being true, an exception path that was never built because the edge case didn't appear in testing.

When the failure is specific, the rescue is specific. Fix the mapping. Handle the format variant. Build the exception path. Add monitoring so you know if the same class of problem recurs. The integration that was failing becomes stable, and the business can rely on it.

Rescue is usually the right starting point when:

  • The integration has been working and recently broke, rather than never having worked well
  • The failure traces to a small number of identifiable root causes
  • The business process the integration serves is stable and unlikely to change significantly
  • The downstream systems haven't changed in ways that require a different design

The case for rebuild

Rebuild makes sense when the problem isn't a specific failure but a fundamental design mismatch. The integration was built for a version of the business that no longer exists. The downstream system has changed in ways that require different data in a different shape. The original design has no room for the exception handling and monitoring that reliability requires.

It also makes sense when the integration is genuinely a black box — when no one understands how it works, when there's no documentation, when the code (if there is code) can't be safely modified without risk of unknown side effects. At that point, rescue has a ceiling: you can stabilise it, but you can't improve it.

Rebuild is usually the right approach when:

  • The business process has changed significantly since the integration was built
  • The failure is pervasive rather than specific — most documents fail, rather than a specific category
  • The integration has no exception handling, no logging, and no monitoring
  • The downstream system has been replaced or substantially upgraded

The danger of defaulting to rebuild

The risk with rebuild is that it feels like the clean answer when it isn't. A rebuild starts a project. Projects have timelines, budgets, and go-live moments. During the rebuild, the failing integration is still failing — or worse, it's been taken offline and the gap is being filled by manual process.

Rebuilds also tend to underestimate the design work. The decisions that led to the original failure — about data mapping, exception handling, downstream compatibility — have to be made again in the new build. If those decisions aren't made better this time, the new integration will develop the same problems.

The most common outcome of an unjustified rebuild is a new integration that fails in different ways.

A practical approach

The most reliable starting point, regardless of which direction you expect to go, is a structured assessment of the current failure. Not an architectural review of what should be built, but a forensic trace of what's actually breaking and why.

That assessment usually takes a few days. It answers: what is the failure rate, what are the failure modes, how many distinct root causes are there, and are those causes fixable in the existing design?

If the answer is two or three specific root causes that are fixable in the existing design, rescue it. If the answer is pervasive failure across most of the design surface, rebuild it. The assessment tells you which situation you're in — and it's a much more reliable guide than the instinct to replace something because it's broken.