Stakeholder management in M&A: the network architect caught between IT, OT and the deal team

Why network integration in M&A is an expectations problem

A synergy plan is usually drawn up before anyone has looked at the network. The documents reference data centres to be consolidated, a shared Active Directory structure, a consolidated ERP system, shared internet connections. These goals assume that the network is an interchangeable commodity that can simply be connected. It is precisely not that. Merging two organically grown infrastructures is usually the slowest, most expensive and riskiest part of any integration - and the only one that can directly endanger production.

The pattern repeats itself: the architect is brought in too late, namely after signing, when the synergy targets and timeline have already been negotiated and reported to the supervisory board. From that point on, every technical truth counts as bad news. Anyone who then only says "it doesn't work like that" loses. The task is to translate technical reality into the language of risk, cost and time, and from that build a path that all parties can support. That is stakeholder management, an important topic in every project.

The stakeholder landscape: who wants what

Stakeholders are interest groups or individuals with an interest in the project (whether positive or negative). Anyone who fails to cleanly separate these interests negotiates against a phantom. In a typical deal, the architect faces at least six groups with incompatible priorities:

• Deal team and Integration Management Office (IMO): think in milestones, synergy amounts and Day 1 readiness. For them, "connect the network" is a line in the plan, not a project. They steer via metrics and deadlines.
• IT management (CIO): wants to standardise, merge domains, cut licence and operating costs. Tends to treat OT as "just more IT" - with the same tools, the same maintenance windows, the same pace of change.
• OT and production (plant management, maintenance, automation): want stability, no outages, no voided manufacturer approvals. "Never touch a running system" is not laziness but learned caution. This group is often fundamentally sceptical of IT-driven change.
• Security and CISO: want visibility, segmentation, controlled access. In the target company, the security posture is initially unknown, and the unknown is their biggest problem.
• Legal and compliance: think about data protection, transitional service agreements, and, since NIS2 tightened requirements, personal liability of management.
• Works council: an independent stakeholder in Germany. New remote access, monitoring or changed workplaces touch on co-determination rights - and become a brake if involved only after the fact.

Added to this are external parties: existing service providers, managed service providers and (in a carve-out) the seller's IT function, on which the target company initially remains dependent. There can also be "non-integrated" interest groups: think, for example, of a nature conservation association or similar. Each of these groups has a legitimate claim. The mistake is to address them all with the same message, or worse, to ignore them.

The core conflict: synergy speed versus OT stability

The deepest contradiction runs between the desire for rapid merging and the resilience of OT. It can be pinned down to a single detail that appears in almost every deal: overlapping address ranges. Both companies are highly likely to use the same private IP address space, such as 10.0.0.0/8 or several 192.168.x networks. You cannot simply route between two identical address ranges. NAT is a stopgap that breaks down with industrial protocols, hard-coded addresses in PLC programs, and certain licensing mechanisms. There are also various devices where the IP address is transmitted not only at ISO/OSI Layer 3 but simultaneously within the application itself. NAT is of no help there either.

On top of this come constraints that simply don't exist in pure IT. An intervention in a controller can void the manufacturer's approval or a safety-related certification. Renumbering during live operation is out of the question, because a production line cannot simply be switched off "for a weekend". Real-time requirements and functional safety tolerate no experiments. These points are self-evident to production and invisible to the deal team. The architect's task is to make them visible and quantified - not as refusal, but as effort, risk and time on which management can decide.

Due diligence: what must be clarified before closing

Ideally, the network architect is already involved in technical due diligence - before signing. Because whatever is found or overlooked here later ends up as a synergy assumption baked into the purchase price. At minimum, the following should be checked:

• Addressing and documentation: Is there a reliable IP address plan? Experience shows that documentation for OT in particular tends to be incomplete or outdated.
• Segmentation status: Is the OT flat, or do zones already exist? A flat plant network is a cost driver that changes the entire integration timeline.
• Dependencies on the seller: Which services? DNS, AD, internet breakout, remote maintenance? In a carve-out, are these still running through the parent company? The scope of this entanglement determines the length and cost of the later transition.
• Remote access and legacy systems: Where are unsecured maintenance accesses located, and where are unsupported operating systems running that can no longer be patched?

The result is not an audit report for the drawer, but a realistic integration roadmap with effort and risk estimates. That is precisely how the architect earns credibility with the deal team: not by raising objections, but by delivering a figure that can be planned against.

Day 1 and the transition phase: coupling, not merging

At legal closing, minimal Day 1 connectivity is often expected - shared email, a handful of shared applications - even though nothing has actually been integrated yet. The correct response is controlled coupling, not merging: a transit zone routed through firewalls, in which only the few genuinely necessary connections are enabled and overlapping addresses are handled via NAT at a defined handover point. Everything else remains separate.

If a Transition Service Agreement is in place, the target company continues to draw services from the seller. The architect must design a clean demarcation and an exit plan for this - otherwise the temporary dependency becomes a permanent state. An early, clearly communicated boundary is essential: OT does not belong in the Day 1 scope. OT integration is a multi-year programme, not a task for the first week. Anyone who fails to make this clear to the deal team in good time will later be negotiating against a promise that was never deliverable. This is often referred to in terms of CMO (Current Mode of Operation), IMO (Interim Mode of Operation) and FMO (Future Mode of Operation).

Post-merger integration: segmentation as the target picture

The most common misconception of the integration phase is the image of one single, large, merged network. The correct target picture is a segmented one: a common core for shared IT services, with each site, each plant, as its own controlled zone, following the logic of the Purdue model and the zones-and-conduits methodology of IEC 62443. This reframing considerably eases the time pressure. Not every plant needs to be renumbered by day 100. Instead, zones, transitions and a step-by-step migration are defined.

Some OT islands will remain isolated for years - and that is a valid architecture, not a failure. A segmented target reduces risk, because an incident in one part of the business does not spread to another. At the same time, it meets the requirements of IEC 62443 and NIS2. And it allows the business to capture synergies where they are cheap - in shared IT services - while protecting where change is expensive and dangerous. The architect is thus not selling management on restraint, but on sequencing.

How to actually bring stakeholders on board

In practice, it is communication rather than technology that decides the outcome. Four principles carry through almost every deal:

1. Address each group in its own language. The deal team is given risk, cost and time; OT cares about stability and manufacturer approval; IT cares about standardisation and security. The same decision, three justifications.
2. Create a shared picture. A target architecture diagram that everyone can point to ends more "just connect it, it's easy" discussions than any spoken argument. People who look at the same graphic argue more concretely.
3. Bring conflicts of objectives openly to management. The architect does not decide on risk appetite. He presents options with their effort and consequences and lets leadership choose. The decision is then documented. This protects against becoming the scapegoat.
4. Involve OT early and give it a say over its own zones. Anyone who bypasses production reaps passive resistance that costs every maintenance window. Anyone who involves them wins over the people who are the only ones who really know what their plant can withstand. (Isn't production often the true cash cow?) The works council, too, belongs at the table for new access and monitoring arrangements. And please, beforehand, not afterwards.

Conclusion: architecture is also a question of liability

Since the NIS2 Implementation Act came into force in Germany, the acquiring company inherits not only the networks upon closing, but also the security obligations and the management's personal liability for the merged operation. Architecture decisions made under M&A time pressure thus become compliance facts. A segmented target architecture is therefore not just sound engineering, but the prerequisite for being able to defend the merged company under NIS2 and IEC 62443 at all. The network architect's real deliverable in a merger is not a cabling plan. It is a shared, realistic picture that IT, OT and the deal team can equally commit to.