When to Rebuild vs When to Fix a Failing Integration

Every integration reaches a point where it stops behaving the way it did on day one. The question that lands on an IT director’s desk is rarely whether something is wrong. It is whether the right move is to repair what exists or to replace it. Get that call right and you protect uptime, budget, and roadmap. Get it wrong and you either pour money into a system that was always going to fail again, or you throw away a serviceable asset and absorb months of avoidable rebuild risk.

This guide lays out how experienced integration teams make that decision. It covers how to define failure precisely, how to weigh the true cost of a struggling integration, the signals that point toward a fix, the signals that point toward a rebuild, and a scoring framework you can apply to your own environment. It also covers what changes when the integration runs on Workday, Infor, or MuleSoft, because platform lifecycle rules often decide the matter for you.

What “Failing” Actually Means

Failure is not a single event. It is a set of distinct modes, and naming the mode is the first step toward the right remedy.

Intermittent errors are the most common and the most misleading. A job that fails one run in fifty, a webhook that occasionally times out, or a batch that silently drops records looks minor until you trace the blast radius. These faults usually point to weak retry and dead-letter handling, missing idempotency, or a downstream system that applies backpressure your integration never learned to respect.

Throughput and latency degradation is a slower burn. The integration still works, but volume has grown past what the original design assumed. Queues back up, sync windows stretch, and the business starts feeling lag in reporting or fulfillment. This is a capacity problem, not necessarily a correctness problem, and that distinction matters when you choose a path.

Data integrity issues and schema drift are the failures that erode trust. A source system adds a field, changes a data type, or repurposes an existing attribute, and the integration keeps running while quietly corrupting the target. Schema drift is insidious because there is often no error at all, only wrong data discovered weeks later.

Security gaps are a category of their own. Hardcoded credentials, unencrypted payloads, a missing authentication check on an internal endpoint, or a dependency carrying a known vulnerability all qualify, whether or not the integration is currently broken in a functional sense.

Unsupported dependencies and runtime end-of-life are failures waiting to happen. A connector the vendor has deprecated, a language runtime past its support window, or a platform version scheduled for retirement puts a clock on the integration regardless of how well it runs today.

Scaling ceilings and unmaintainable code round out the list. An integration that cannot be extended without breaking, that no current team member understands, or that is architecturally incapable of handling the next phase of the business is failing in a strategic sense even if every job shows green.

The Real Cost of a Failing Integration

The cost of a struggling integration is almost always larger than the incident ticket suggests, because most of it is hidden.

Direct downtime is the visible layer. When an order-to-cash or hire-to-retire flow stops, the business stops with it. Below that sits the manual workaround, which is where real money leaks. Teams start exporting spreadsheets, rekeying records, and reconciling by hand, and those workarounds calcify into permanent process. The labor is continuous and rarely measured.

The industry data makes the scale of the problem clear. MuleSoft’s 2026 Connectivity Benchmark Report, drawn from more than a thousand IT leaders, found that 95 percent of organizations report facing integration challenges, and that IT teams now spend an average of 36 percent of their time designing, building, and testing custom integrations rather than advancing new work. The same research reports that 26 percent of IT projects were not delivered on time over the prior year, and that 71 percent of IT leaders say their infrastructure makes systems overly dependent on one another. That last figure is the technical debt problem stated plainly: tight coupling turns a single failing integration into a drag on everything connected to it.

Accumulated technical debt is the compounding cost. Every quick patch on a fragile design raises the price of the next change. At some point the interest on that debt exceeds the cost of the principal, and that crossover is exactly the moment a rebuild starts to pay for itself.

When Fixing Is the Right Call

Fixing is the correct default more often than vendors admit. If the architecture is fundamentally sound and the failure traces to a specific, well-understood cause, repair is faster, cheaper, and lower risk than replacement.

Fix when the root cause is shallow and contained. A missing retry policy, an unhandled edge case, a credential rotation that was never automated, or a single query that needs an index are all repairable without touching the wider design. Fix when the platform, runtime, and dependencies are all still supported and the integration simply needs hardening. Fix when the data model is stable and schema drift can be absorbed with a mapping change rather than a re-architecture.

The other strong signal is time to value. If the business needs the flow healthy this quarter and the underlying design can support that, a targeted repair wins. Bringing in a specialist to diagnose and repair a broken integration often surfaces a root cause the original team could not see, and resolves it in a fraction of the time a rebuild would take. A good repair is not a patch on a symptom. It is a fix at the level of the actual defect, with observability added so the same failure is caught earlier next time.

When Rebuilding Is the Right Call

Rebuilding is the right call when the problem is the design itself, not a defect within it. No amount of patching fixes an architecture that was wrong for the current requirements.

Rebuild when failures are systemic rather than local, when fixing one issue reliably surfaces another, and when the team can no longer predict what a change will break. Rebuild when the runtime or a core dependency has reached end-of-life, because a supported foundation is not optional and back-porting security fixes onto an unsupported base is a losing game. Rebuild when the integration cannot scale to meet committed volume no matter how it is tuned, since a capacity ceiling baked into the design is not a tuning problem. Rebuild when security cannot be retrofitted cleanly, for example when secrets are woven through the code or the transport layer was never designed for encryption.

The maintainability test is decisive. The ISO/IEC 25010 software quality model defines maintainability through sub-characteristics such as modularity, analyzability, modifiability, and testability. When an integration scores poorly on all of them at once, the honest conclusion is that you are maintaining a liability. In that situation, choosing to rebuild the integration cleanly on modern patterns, with proper decoupling, idempotent processing, and first-class observability, is the lower-risk path over any horizon longer than a single quarter.

A Decision Framework

Because the answer is often that it depends, it helps to make the dependence explicit. The rubric below scores the decision across the factors that actually move it. Rate each factor from 1 to 5, where 1 favors fixing and 5 favors rebuilding, multiply by the weight, and sum the results. A weighted total in the lower range points to repair, the upper range points to replacement, and the middle is where an independent opinion earns its keep.

The framework is a structured conversation, not an algorithm. A single factor can override the total: a runtime past end-of-life or an unfixable security flaw forces a rebuild regardless of how favorably everything else scores. When the total lands in the ambiguous middle, an independent integration assessment from a team that did not build the original system removes the sunk-cost bias that distorts in-house decisions.

Platform-Specific Considerations

Lifecycle policy often decides the question before technical merit does. Each platform sets its own rules for versioning, deprecation, and support, and those rules put hard dates on your options.

Workday

Workday’s public Web Services APIs are versioned, and older versions are retired on a rolling schedule as new ones ship. An integration pinned to an aging API version carries a built-in expiration, and Workday configuration changes such as security policy or business process updates can break tightly bound integrations that were never designed to tolerate them. When the binding is brittle and the version is old, Workday integration work frequently favors a clean rebuild against a current API version with looser coupling, rather than repeated patching against a moving target.

Infor

Infor environments commonly integrate through ION and the platform’s document and event framework, and the calculus depends heavily on deployment model and version currency. A supported CloudSuite release with healthy ION flows is usually a fix candidate. An older on-premise footprint with customizations layered on a version nearing the end of its support window pushes toward replacement. Sound Infor integration starts by confirming where the deployment sits in its lifecycle before committing to either path.

MuleSoft

MuleSoft is explicit about lifecycle, which makes the decision unusually clear. Under the MuleSoft product versioning and back support policy, a Long-Term Support release receives a minimum of eighteen months of Standard Support followed by a minimum of six months of Extended Support, and applications left on an end-of-life runtime on CloudHub are eventually stopped. If your MuleSoft integration on the Anypoint Platform runs on a runtime approaching end-of-life, a runtime upgrade is mandatory, and that upgrade is often the right moment to address accumulated design debt rather than lift a flawed application onto a new runtime unchanged.

Security cuts across all three platforms. The OWASP Top 10 treats vulnerable and outdated components as a distinct and well-documented risk, and a dependency with a known exploit is a rebuild trigger on its own when it cannot be patched in place.

How to De-risk Either Path

Whichever path you choose, the difference between a smooth transition and an outage is disciplined execution.

Start with observability, before you change anything. You cannot safely fix or replace what you cannot see. Instrument the current integration for error rates, latency, throughput, and data-quality checks, so you have a baseline to measure against and an early warning system for regressions.

Test against real conditions. Contract tests catch schema drift, load tests expose capacity ceilings before production does, and replaying historical payloads validates that a fix or a rebuild handles the edge cases the old system actually encountered. Idempotency belongs in the test plan, so reprocessing a message never doubles a transaction.

For a rebuild, favor a phased cutover over a big-bang switch. Run the new integration in parallel with the old one, compare outputs on live traffic, and shift volume gradually. Keep a tested rollback ready at every stage, because a rollback you have never exercised is a hope, not a plan. Once the new flow is stable, ongoing monitoring and maintenance is what keeps a healthy integration healthy and catches the next drift or deprecation long before it becomes an incident.

Frequently Asked Questions

How do I know if my integration is worth fixing or should be rebuilt?

Trace the failure to its root cause first. If the cause is shallow and the underlying design still matches your requirements, fixing is almost always faster and cheaper. If failures are systemic, the runtime is unsupported, or the architecture cannot meet current volume, a rebuild is the sounder investment. The scoring framework above turns that judgment into a repeatable process.

What are the warning signs that an integration is failing?

Watch for intermittent errors that resist explanation, throughput and latency that degrade as volume grows, data integrity problems from schema drift, security gaps, and dependencies or runtimes nearing end-of-life. A quieter sign is maintainability: if no one on the team can safely change the integration, it is already failing in a way that does not show up as a red alert.

How much does it cost to rebuild an integration versus patch it?

A patch is cheaper up front, and when the design is sound it is the right economic choice. The calculation changes when patches keep multiplying, because each one raises the cost of the next change. A rebuild carries a higher initial cost but eliminates the compounding interest on technical debt, which is why the total cost over a multi-year horizon often favors replacement for a genuinely broken design.

Can a failing integration be fixed without downtime?

Often, yes. Many repairs can be staged and deployed behind feature flags or during low-traffic windows, and a well-instrumented environment lets you validate the fix on live traffic before full cutover. Zero downtime is not guaranteed for every change, but with parallel running and a tested rollback the exposure can usually be reduced to near zero.

How long does an integration rebuild usually take?

It depends on the number of systems involved, the complexity of the data mappings, and how much business logic is embedded in the flow. A single point-to-point interface can be rebuilt in weeks, while a multi-system, high-volume integration with strict compliance requirements can take several months. A phased approach lets you deliver value incrementally rather than waiting for a single large release.

Is technical debt a good enough reason to rebuild on its own?

Not by itself. Technical debt justifies a rebuild when it has become pervasive enough that routine changes are slow, risky, or unpredictable, and when the maintainability characteristics defined in the ISO/IEC 25010 quality model are weak across the board. Isolated, well-understood debt is usually better managed with targeted refactoring than with a full replacement.

When does a platform or runtime end-of-life force a rebuild?

When reaching a supported foundation requires more than a routine upgrade. If the current version can move to a supported release without redesign, that is maintenance, not a rebuild. If reaching a supported runtime means the integration will no longer function as written, the end-of-life event is effectively forcing a rebuild, and it is better to plan for it than to be caught by a hard cutoff.

Should security vulnerabilities trigger a rebuild or a fix?

It depends on where the vulnerability lives. A patchable dependency or a misconfiguration can be fixed in place quickly. A flaw rooted in the design, such as credentials embedded throughout the code or a transport layer that was never built for encryption, usually cannot be retrofitted safely and points to a rebuild. OWASP’s treatment of vulnerable and outdated components is a useful reference for deciding which case you are in.

The Next Step

The rebuild-versus-fix decision rewards honesty over optimism. Fix when the design is sound and the fault is contained. Rebuild when the design itself is the fault, or when the platform lifecycle has made the choice for you. When the signals conflict, the fastest way to a confident answer is a structured assessment from an integration specialist who has triaged both outcomes many times. If you are weighing that decision now, talk to a team that works across Workday, Infor, and MuleSoft and can tell you plainly which path your integration actually needs.