The 180-Day Integration Clock
The value case for consolidation is almost always written as a cost synergy. The cost synergy is almost always deferred, because merging two networks is easy and merging two operating stacks is not.
Independent networks are built as self-contained operations. Each carries its own business support systems for billing and customer management, its own operational support systems for provisioning and assurance, its own geographic inventory, its own field-service tooling — frequently a mix of proprietary platforms, spreadsheets, and institutional memory.
Acquire three of them and you own three of everything.
What running in parallel actually costs
The temptation after close is to leave the acquired stacks running and integrate later. It is the lowest-risk decision available on day one and the most expensive one available over eighteen months. Parallel operation means duplicated licence costs, no single view of network inventory, reconciliation work between incompatible customer records, and a support function that has to be trained on multiple systems. The economies of scale that justified the transaction do not arrive, because nothing has actually been consolidated except the ownership structure.
The failure is rarely dramatic. It shows up as a synergy target that slips a quarter, then another, until it is quietly rebased.
What a 180-day target changes
A hard deadline for migrating acquired customers, billing, and inventory onto a single API-driven platform forces three decisions to be made before close rather than after: which stack survives, what data model everything maps to, and who owns the migration. Teams that defer those decisions to post-close discover that each one is now a negotiation between people who have just become colleagues.
The architectural requirement is unglamorous — an integration layer that lets network management, geographic information systems, and billing communicate through documented interfaces rather than point-to-point custom work. It is the same principle that makes the operating framework we have been building workable: define the interfaces first, so that adding a network is a configuration exercise rather than a rebuild.
None of this is a technology problem in any interesting sense. It is a sequencing problem. The organisations that hit their synergy numbers are the ones that treated integration as a diligence workstream, not a post-close programme.
For anyone who has run one of these: what actually slipped first — the systems migration, the field-force consolidation, or the customer communications? We suspect the answer is not the one that gets written into the plan.
Sources: Cyient, "Making M&A Work in the Fiber Broadband Industry"; EY, on OSS transformation strategy. Framework application is GreySynth's.
Next: digital twins, subscriber propensity, and how agents get governed.