Mapping Dependencies After a Merger

Mapping dependencies after a merger means reconciling the service maps of two organisations into a single, accurate picture of the combined service. A merger brings together different systems, suppliers, teams, data stores, and processes, often for services that appear similar but run in very different ways. Customers may be migrated, systems may be consolidated, and teams may be merged, while the underlying dependencies remain a mixture of both predecessors for a considerable period. The map must reflect that mixture honestly, showing which parts come from which predecessor, what has been consolidated, and what still runs in parallel, so that responders are not misled by an assumption of uniformity.

It is hard because knowledge is fragmented and incentives pull in different directions. Each predecessor team understands its own service well and the other's service poorly. Documentation may use different terms for the same thing, or the same term for different things. Systems may have overlapping functions but incompatible data. Suppliers may be duplicated, with two contracts for the same capability. During integration, attention naturally focuses on migration and cost, while mapping can feel like a retrospective exercise. Yet it is precisely during integration, when services are changing fastest and knowledge is most dispersed, that an accurate map is most needed for incident response.

Start with the services that customers actually use after the merger, and trace each one across both predecessors. For each service, show which systems, suppliers, teams, and data stores support it now, regardless of origin, and flag where duplicate or parallel arrangements still exist. A service that runs on two processing systems during migration, for example, should show both, with the migration state noted, rather than showing only the intended future system. The map should also show interim workarounds and manual bridges between predecessor systems, because those bridges often become critical dependencies that nobody planned to keep, yet everyone relies on during transition.

Duplicates should be recorded, not hidden. If two suppliers provide the same function for different customer groups, both belong on the map until consolidation is complete. If two teams both claim ownership of a process, the map should record the actual division of work and the agreed owner for incident decisions, even if the organisational answer is still evolving. Hiding a duplicate to make the map look tidy creates a false sense of simplicity. A responder who follows the tidy map may contact the wrong supplier or team, or restore the wrong system, while the duplicate that actually serves the affected customers remains unexamined.

Mergers change people as much as systems. Staff leave, teams are restructured, and knowledge that was once held by a predecessor team may be lost or dispersed. The map should be updated as people move, with new owners and deputies named for each part of the combined service. It should also capture knowledge that is at risk: a legacy integration understood by one departing specialist, a supplier relationship held by one manager, or a manual workaround known only to a small team. Treating knowledge transfer as a mapping task, with owners and follow-up, helps prevent a situation where the combined firm owns a service on paper but no longer understands how it runs.

Validate by rehearsing incidents against the combined map, with teams from both predecessors participating. A rehearsal that involves a service spanning both organisations will quickly reveal whether owners are agreed, whether duplicate systems are understood, and whether interim bridges work as assumed. It will also reveal terminology gaps, where teams use different words for the same dependency. Update the map after each rehearsal, and repeat the exercise as integration progresses, because a map that was accurate at merger completion will be outdated once consolidation advances. Under DORA in the EU and under FCA and PRA policy in the UK, the combined firm remains responsible for the resilience of its services, labelled separately in these guides, regardless of which predecessor originally built them.