The Two-System Handshake That Swallowed Four Years: Anatomy of an Integration Runaway

Ask a room of CIOs to raise their hands if they've ever had a simple integration balloon beyond recognition, and you'll watch a forest of arms go up. The pattern is so consistent it borders on folklore: two systems, one interface, a twelve-week estimate, and then — somehow — a workstream that outlives the CIO who approved it.

At FortumDS, we've sat on both sides of this table enough times to know the runaway integration isn't a failure of engineering. It's a failure of visibility. The project doesn't explode; it erodes, one undocumented business rule at a time.

The Anatomy of Scope That Doesn't Announce Itself

Runaway integrations follow a recognizable arc. It usually starts with data mapping — the phase every estimator rounds down because it looks like mechanical work. Field A maps to Field B. What could take longer than a sprint?

Then the edge cases surface. The legacy ERP in the Chicago distribution center has been storing customer credit terms in a free-text field since 2009 because, as one operations manager put it, "the dropdown never had the right options." Multiply that improvisation across fifteen years and four acquisitions, and your clean field mapping becomes an archaeology project.

The second wave arrives with undocumented business rules. These are the decisions someone made in 2016 that were never written down but are now load-bearing: the reason orders over a certain threshold route through a manual review, the reason certain SKUs are excluded from automated pricing. None of this lives in documentation. It lives in the muscle memory of three employees, one of whom is planning to retire in the spring.

By the time the integration team discovers rule number forty, the twelve-week project is nine months old and the steering committee is being shown burn-down charts with increasingly creative y-axis scales.

The Early Warning Signs Worth Treating as Alarms

The good news: runaway integrations telegraph their trajectory early. The signals are subtle, but they're consistent across industries and stacks.

The subject-matter-expert calendar becomes the critical path. When your project plan starts scheduling around the availability of a billing analyst rather than engineering capacity, you're no longer doing an integration — you're reverse-engineering the business.

"Known exceptions" become a growing list. A healthy integration handles a bounded set of variations. An unhealthy one accumulates them weekly. If your exception register grew from twelve entries to sixty without a corresponding design conversation, the system isn't being integrated — it's being imitated, rule by rule.

Testing reveals more than it verifies. When QA cycles keep surfacing behaviors nobody knew existed, that's not a quality problem. That's the integration functioning as an unintended audit of your entire order-to-cash process. Budget and schedule accordingly — or better, run the audit deliberately.

The estimate revises in the same direction, repeatedly. One schedule slip is noise. Three consecutive revisions, each with a plausible explanation, is a structural signal that the true scope was never visible in the first place.

Quarantining the Runaway: A Practical Playbook

Once an integration shows these symptoms, the instinct is often to throw more engineers at it. That almost always makes things worse, because the constraint was never coding speed — it was knowledge discovery. A more effective response follows three moves.

First, freeze the perimeter. Define precisely which data objects and transactions are in scope, in writing, signed by the business owner. Runaway integrations thrive on ambiguity; a one-page scope memorandum does more than a month of additional discovery.

Second, decouple the pipeline from the product. If the integration is blocking a customer-facing release, build a temporary, explicitly-labeled bridge — a scheduled export, a middleware queue, even a well-governed flat file. It's not elegant, but it returns the roadmap to the business while the real integration proceeds at an honest pace. The key is labeling it as debt with an owner and a review date, so the temporary fix doesn't quietly become permanent infrastructure.

Third, convert discovery into a deliverable. The undocumented business rules your team is excavating are valuable organizational assets. Capture them in a decision log with named sources and dates. This transforms the sunk cost of a struggling integration into durable institutional knowledge — and it protects the next project from repeating the excavation.

What This Means for the Portfolio

The deeper lesson for enterprise leaders is about portfolio governance, not project management. Integrations are where an organization's accumulated complexity becomes physically manifest. A twelve-week estimate isn't wrong because the estimator is bad; it's wrong because the estimate prices the interface, not the decade of undocumented decisions flowing through it.

Mature organizations respond by treating integration estimates as hypotheses to be validated through structured discovery, not commitments to be defended in steering committees. They fund a two-week mapping exercise before they fund the build. They require every integration proposal to name the three riskiest business rules and how they'll be surfaced. And they watch the exception register like a heartbeat monitor.

None of this guarantees the project finishes in twelve weeks. But it guarantees that when the estimate is wrong, you'll know within weeks rather than years — and that your roadmap survives the difference. In enterprise software, that's usually the whole game.