What Happens to Requirements Management After a Merger or Acquisition?
Picture this: a mid-tier defense prime acquires a systems integrator that has been running a successful avionics program for eight years. The acquiring company runs IBM DOORS. The acquired company runs Jama Connect. Both have active programs under configuration control. Both have customer-facing CDRLs due within six months. The integration team’s first instinct is to pick one tool and migrate everyone into it.
That instinct is wrong, and acting on it immediately can compromise both programs.
Requirements management during M&A is one of the most under-discussed operational risks in aerospace and defense engineering. The engineering press covers financial due diligence, talent retention, and IP consolidation — but rarely the moment when two engineering organizations discover they cannot read each other’s baselines, cannot trace each other’s verification evidence, and cannot agree on what “approved” means.
This article covers what actually happens, what decisions have to be made fast, and how modern requirements tooling changes the calculus.
The Immediate Risks No One Puts in the Integration Plan
When two organizations merge their engineering functions, requirements risk accumulates in three specific ways before anyone has written a single migration plan.
Duplicate requirements with divergent interpretations. Both organizations may have captured the same parent requirement — perhaps from a common customer specification — and decomposed it differently. Neither decomposition is wrong in isolation. But when the merged organization has to verify compliance at the system level, those two decompositions may produce contradictory verification approaches, contradictory acceptance criteria, or contradictory interface allocations. Finding duplicates in a single DOORS database is hard. Finding them across two databases with different attribute schemas and different numbering conventions is genuinely difficult without deliberate tooling support.
Broken traceability chains. Modern programs trace requirements to design artifacts, to verification events, to test results, to hazard analyses. That traceability lives inside each organization’s tool, often referencing internal document IDs and internal artifact paths. After a merger, those links do not automatically extend across organizational boundaries. An engineer on the acquired side who needs to answer a customer question about verification coverage suddenly cannot trace up to the parent spec that now lives in a different tool managed by a different team under a different configuration control board.
Lost context that was never formally captured. This is the most dangerous category. Requirements carry rationale — why a threshold was set where it was, why a particular interface was allocated to a particular subsystem, why a waiver was accepted. In both DOORS and document-based tools, that rationale often lives in discussion threads, email chains, informal notes attached to objects, or simply in the memory of engineers who are now being asked to move buildings and report to new managers. The merger creates social disruption precisely when institutional knowledge needs to be most accessible.
The Governance Decisions That Cannot Wait
Before a single requirement is migrated, three governance questions have to be answered. These are not IT decisions. They are engineering leadership decisions with contractual implications.
Which baseline controls which? If both organizations have an approved system requirements document, and if those two SRDs conflict on an interface allocation, which one is authoritative? The answer is not always “the acquiring company’s document.” On programs where the acquired organization holds the prime contract, the acquired baseline may be the contractually binding one. Engineering leadership has to establish baseline authority by program, not by corporate hierarchy, and document it formally before engineers from either organization start making changes.
Who has configuration control board authority? Mergers often blur CCB membership before they clarify it. If an engineer on the acquired side needs to raise a change request against a requirement, which CCB reviews it? If both CCBs still exist in parallel, do both need to approve? These questions sound procedural, but unresolved CCB authority is how requirements changes get made without proper review during the integration chaos period — and how those changes become undocumented departures that auditors find two years later.
What is the interim operating model? Full toolchain unification takes twelve to thirty-six months on a realistic schedule. Active programs cannot stop during that window. Engineering leadership needs to formally designate an interim operating model — likely meaning each organization continues to use its current tool for current programs, with defined interfaces for cross-organizational traceability and a clear data ownership map. The interim model is not a failure to decide. It is the decision that keeps programs safe while unification proceeds.
How Requirements Harmonization Actually Works Without Derailing Programs
The word “harmonization” appears in every integration plan. It rarely comes with a method.
Harmonization has three phases, and the sequence matters.
Phase one: inventory and gap analysis. Before any normalization or migration, someone has to produce a complete map of what exists: every requirements repository, every baseline state, every attribute schema, every traceability link type. This sounds obvious and is consistently skipped or done incompletely. The output of this phase is not a migration plan — it is a risk register. Which programs have traceability gaps already? Which requirements have no verification evidence? Which baselines have not been formally placed under configuration control? You need to know what you are actually working with before you decide how to harmonize it.
Phase two: normalization without migration. This is the step most integration plans skip entirely, jumping straight from inventory to “pick a tool and move everything.” Normalization means establishing a common semantic layer — agreeing on what attributes are required on every requirement, what the approval state vocabulary means, how parent-child relationships are expressed — without necessarily moving any data from its current location. In practice, this often means building a requirements exchange format or a shared data model that both existing tools can feed into, so engineers from either organization can get a coherent view without either organization abandoning its current tool mid-program.
Phase three: structured migration, program by program. Migration happens at natural program breakpoints — after a phase review, before a new development phase begins, at contract renewal. Migrating a program that is mid-CDR is a risk that is rarely worth taking. The migration sequence should be driven by program schedule and risk, not by a corporate IT standardization timeline.
How Modern Tooling Changes the Integration Problem
The traditional approach to post-merger requirements integration assumes that every artifact must eventually live in one tool. That assumption made sense when requirements tools were document managers that required data to be co-located to be linked. It is a less necessary constraint today.
Graph-based requirements management treats requirements, their attributes, their relationships, and their verification evidence as nodes and edges in a connected model. The model does not care whether source data originated in DOORS, Jama, a spreadsheet, or a Word document with custom attributes. What matters is whether the relationships are explicit and traversable.
Flow Engineering is built on this model. When an organization imports requirements from DOORS Next or Jama Connect into Flow Engineering, the import does not simply flatten those requirements into a list — it preserves and makes explicit the hierarchical and trace relationships that existed in the source. Requirements from two different organizational toolchains can be imported, normalized to a common attribute schema, and connected across organizational boundaries without waiting for either organization to abandon its source-of-record tool.
This matters specifically for the post-merger scenario because it separates two problems that are usually conflated: the problem of getting a coherent view across two incompatible repositories, and the problem of long-term toolchain standardization. The first problem is urgent and has program consequences. The second problem is important but can proceed on a longer timeline. Flow Engineering’s import and normalization capability addresses the first problem on a timeline of weeks, not years — teams can establish cross-organizational traceability and common views before a single program milestone is at risk.
The graph structure also handles something document-based tools handle poorly in mergers: the question of where duplicate or conflicting requirements are. In a document model, finding conflicts requires someone to read both documents and compare them manually. In a graph model, requirements with similar natural language content, similar attribute values, or similar positions in a decomposition hierarchy can be identified programmatically. That does not eliminate the human judgment required to resolve conflicts, but it makes the inventory problem tractable.
Flow Engineering’s current focus is on requirements management and traceability for engineering teams rather than the full PLM and program management scope that tools like Polarion or Codebeamer address. For organizations that need tight integration with hardware configuration management or manufacturing BOMs from day one, that scope boundary is a real consideration. But for the specific problem of post-merger requirements harmonization — getting two engineering organizations to a common operational picture of their requirements without stopping active programs — that focused scope is precisely what makes the tool applicable at the speed mergers require.
An Honest Assessment
Post-merger requirements integration fails most often not because of tooling limitations but because of governance decisions that are deferred too long. The questions of baseline authority, CCB structure, and interim operating model are engineering leadership decisions. No tool resolves them.
What tooling can change is the cost of operating across two incompatible environments while those governance decisions are being made and while long-term unification proceeds. If the interim operating model requires engineers from both organizations to manually re-enter requirements into a shared spreadsheet to get a common view, the risk of transcription errors and lost relationships is high and the engineering overhead is significant. If the interim model can be supported by import, normalization, and graph-linked views that preserve the relationships from both source tools, the risk stays manageable and programs continue moving.
The practical recommendation for engineering leaders navigating a merger: separate the governance timeline from the toolchain timeline. Make the governance decisions in the first sixty days. Let the toolchain unification follow program schedules, not corporate IT schedules. And look for requirements tooling that can operate as a coherent layer across heterogeneous sources, not just as a migration destination.
Two toolchains do not have to become one before engineering can proceed safely. They have to become legible to each other. That is a solvable problem.