Post-merger IT integration is one of the highest-risk, highest-cost phases of any acquisition. It is also one of the most predictable sources of failure. The problems that derail integration programs — shadow systems nobody knew about, undocumented dependencies between critical applications, incompatible governance standards, duplicate capabilities that both organizations want to keep — are architecture problems. They can be addressed with architecture governance. Most integration programs do not have it until the damage is done.
This article covers how enterprise architecture — specifically Sparx EA — provides the integration map that M&A IT programs need, and the timeline for when architecture work should happen to be useful.
Why M&A IT Integration Fails Without Architecture Governance
The failure patterns in post-merger IT integration are remarkably consistent:
Unknown systems. Neither organization has a complete, accurate application inventory. The acquired company’s CMDB is out of date. The acquirer’s architecture team has never seen the target’s systems. The integration program builds a plan on an incomplete picture, then discovers critical systems — a custom middleware layer, a set of legacy databases, a third-party integration that nobody documented — weeks or months into execution.
Undocumented dependencies. Two applications look like candidates for rationalization — they do similar things, so one should go. But when the team looks closer, they are integrated with ten other systems each, in different ways, and decommissioning either one requires a project larger than the merger itself.
Duplicate capabilities, conflicting standards. Both organizations have an ERP, two HR systems, three CRM platforms, and their own security standards. Deciding which to keep requires understanding not just what each system does, but which business processes it supports, which regulatory obligations it satisfies, and which integrations it has — information that lives in architecture models, not in application vendor catalogs.
Different governance cultures. One organization uses ArchiMate with a mature MDG governance framework. The other uses a mixture of Visio diagrams and SharePoint pages. Connecting these two architecture estates is not just a technical problem — it is a governance problem that requires agreed standards, an integration metamodel, and tooling that can span both repositories.
Enterprise architecture does not eliminate these problems, but it makes them visible early enough to manage. The organization that has a governed, model-based architecture repository — with application inventories, dependency maps, and business capability linkages — has a material advantage in M&A integration compared to one that does not.
How EA Provides the Integration Map
Merging the Two Architecture Repositories
When both organizations use Sparx EA, the most powerful starting point is repository integration via EA GraphLink. EA GraphLink can connect two Sparx EA repositories — the acquirer’s and the target’s — and expose cross-repository queries that neither organization could run independently:
- “Which applications in the target organization overlap with capabilities we already have?”
- “Which systems in the target environment have integrations that would be broken if we migrate their ERP?”
- “What is the combined application portfolio, by business capability, across both organizations?”
This is not available with point-solution tools or spreadsheet-based inventories. It requires that both organizations have their architecture in a queryable, structured repository. Where only one organization has Sparx EA, the first task is to build a baseline model of the other organization’s estate — which is achievable but takes longer.
The Application Rationalization Process
Application rationalization in a post-merger context follows a structured process:
Step 1: Unified application inventory Consolidate both organizations’ application lists into a single Sparx EA repository (or a federated view via EA GraphLink). Each application is documented with: name, business capability supported, technology stack, integration points, regulatory obligations, hosting environment, and owner.
Step 2: Capability mapping Map both organizations’ applications to a common business capability model. This reveals which capabilities are duplicated (both organizations have a Claims Management system), which are gaps (the acquirer lacks a capability the target has), and which are unique to each organization.
Step 3: Rationalization decision framework For each duplicated capability, document the four possible outcomes:
- Keep acquirer’s system, retire target’s
- Keep target’s system, retire acquirer’s
- Keep both temporarily, plan future consolidation
- Replace both with a new platform
Each decision is documented in Sparx EA with rationale, dependencies that must be resolved first, and the migration approach for the retiring system.
Step 4: Integration architecture design The target integration architecture — which systems will connect to which, through what middleware, under what data governance — is documented in ArchiMate using the same approach as any architecture design project. The difference in a post-merger context is that the architecture team is designing for an estate that is still being rationalized, which requires iterative design and strong change management.
The AI-Accelerated Integration Analysis
Post-merger integration timelines are compressed. Decisions that would normally take months of architecture analysis need to be made in weeks. This is where AI-assisted querying of the architecture repository provides genuine acceleration.
With Kernaro AI Hub (or Copilot/Claude via the Sparx EA MCP server) connected to a federated repository view, integration architects can ask:
- “Which applications in the target estate have dependencies on systems we plan to retire in the first 90 days?”
- “How many applications across both organizations are tagged as ‘critical’ and hosted on infrastructure that will be decommissioned as part of data centre consolidation?”
- “What does the combined application portfolio look like by business domain, sorted by age and technical risk rating?”
Queries that would previously require a week of manual analysis across multiple spreadsheets return in seconds from a well-governed Sparx EA repository. The architecture team can spend their time on analysis and decision-making rather than data gathering.
The People and Process Dimension
Technical repository integration is the straightforward part. The harder challenge is governance alignment:
Different modeling standards. One organization may model at the business architecture level; the other at the application portfolio level only. Agreeing on a common level of detail — and a common MDG profile that both teams use going forward — is a governance design task that should be completed in the first four to eight weeks.
Different naming conventions. Application names, business capability taxonomy, and organizational unit names will differ between the two organizations. A mapping exercise is needed before cross-repository queries produce meaningful results.
Different ownership structures. The acquirer’s EA team may use a centralized model; the target’s architecture function (if it exists) may be distributed across business units. The integration program needs to decide on a governance model for the combined architecture function before meaningful integration analysis can happen.
Different tool maturity levels. If the target organization does not have mature EA governance — common in smaller acquisitions — the acquirer’s architecture team needs to rapidly assess and document the target estate. This assessment phase, done well, is the foundation of a successful integration program.
What EA Should Be Doing at Each Stage
Weeks 1–4: Architecture Discovery and Assessment
The immediate priority is building a complete picture of both application estates:
- Activate EA GraphLink connections to CMDB, cloud provider APIs, and any existing application inventory sources from both organizations
- Produce a combined application inventory in a shared Sparx EA workspace
- Identify critical integration points — the systems that, if disrupted, would materially impact business operations
- Map applications to business capabilities using a common capability model
- Document the top 10–15 high-risk dependency clusters that require careful sequencing
This phase should produce a documented “integration risk register” — not a full architecture design, but a clear picture of where the landmines are.
Months 1–3: Application Rationalization and Decision-Making
With the inventory in place, the rationalization process begins:
- Facilitate rationalization decisions for each capability cluster, with documented rationale in the Sparx EA repository
- Design the interim integration architecture — the middleware and API connections that will link the two organizations’ systems during the transition period
- Begin detailed design for the first consolidation projects (typically starting with the simplest rationalization decisions)
- Establish the combined architecture governance model: which MDG profile will be used going forward, what are the architecture review processes, who owns what
Months 3–12: Integration Execution and Governance
The integration execution phase is where architecture governance pays its dividends:
- Maintain the architecture model as the golden record for the integration program — all changes to the target state are reflected in Sparx EA before they are executed
- Provide Power BI dashboards (via EA GraphLink) showing integration program progress: applications rationalized, systems decommissioned, integration milestones completed
- Manage architectural change control — any deviation from the agreed integration architecture is assessed for dependency impacts before approval
- Document lessons learned in the architecture repository for future programs
Frequently Asked Questions
What if the acquired company doesn’t use Sparx EA — can we still use this approach? Yes. If the target organization does not have a governed EA repository, the integration architecture team builds one from scratch using whatever documentation exists — CMDB data, application owner interviews, discovery tool output. This takes longer but is not fundamentally different. EA GraphLink can pull from CMDB and cloud provider APIs to accelerate the baseline build. The absence of existing architecture governance in the target company is itself a risk that should be flagged in the due diligence phase.
Should architecture assessment happen during due diligence, before the deal closes? Ideally yes. Architecture due diligence — assessing the target organization’s technology estate for hidden complexity, unknown technical debt, and integration risk — is a legitimate and valuable activity in the M&A due diligence phase. The findings inform the deal valuation (integration cost is part of the acquisition economics) and the Day 1 planning. Where this is not possible before close, the architecture discovery should begin on Day 1.
How do we handle the situation where both organizations have strong architecture practices but different standards? This is the best-case scenario for M&A integration. The task is governance alignment, not baseline building. The architecture teams from both organizations should jointly design the combined governance model — agreeing on a common business capability taxonomy, a combined MDG profile, naming conventions, and a combined architecture review process — as a parallel workstream to the integration execution program. Sparx Services can facilitate this governance alignment workshop as a focused Discover engagement.
What is the connection between post-merger IT integration and the Discover service? The Discover service is the natural starting point for an M&A integration architecture engagement. Discover covers: assessing the current architecture estate, documenting the integration landscape, identifying the key rationalization decisions, and producing the integration architecture roadmap. This is the architecture phase of the integration program — the foundation for the execution that follows.
How long does it take to build a usable architecture model of an acquired organization? For a mid-size organization (200–500 applications), a baseline application architecture model — inventory, capability mapping, key dependencies — can typically be built in four to eight weeks with a dedicated team of two to three architects, using EA GraphLink automation to accelerate data collection. This is sufficient to support rationalization decision-making and integration wave planning. Deeper architecture documentation (detailed integration patterns, security architecture, data architecture) is built out over the following months.
Can AI tools really help with M&A integration analysis at the speed the timeline requires? Yes, with the important caveat that the AI is only as useful as the model it is querying. Where the architecture repository is well-governed and current, AI-assisted querying via Kernaro AI Hub or Copilot provides genuine acceleration — turning multi-day manual analysis into minute-scale queries. Where the repository is incomplete or poorly governed (which is common in early-stage integration), the priority is building a reliable model first. The Discover engagement addresses both: building the model and enabling AI querying of it.
Engage Early — Architecture Surprises Are Expensive
The cost of finding an unknown dependency during migration execution is ten times the cost of finding it during architecture discovery. The M&A integration programs that go smoothly are the ones where architecture governance was in place before the integration plan was written.
If your organization is in a pre-close due diligence phase, post-close integration planning phase, or mid-integration and finding unexpected complexity, the Discover service is the right starting point.
CTA: Discover — Post-merger integration architecture assessment