After a merger of two companies, how would you use capability mapping to drive application rationalization across the combined organization, and what trade-offs come with forcing both companies onto one shared capability model?

Post-merger integration is one of the highest-leverage, highest-difficulty applications of capability mapping, and it is worth walking through why the mechanism works and where it strains. ## One reconciled model, not two maps The mechanism starts with a decision that is easy to state and hard to execute: instead of keeping the acquirer's capability map and the target's capability map as two separate artifacts, you build **one reconciled capability model** that both companies' application portfolios get mapped onto. The reason this matters is that duplication only becomes visible when both portfolios sit on the same map. If Company A's Customer Relationship Management and Company B's Client Account Management are actually the same capability described in different language, keeping them as two separate map entries hides a duplicate CRM investment that a reconciled single entry would surface immediately - two applications, both full-strength, on one capability line, which is the textbook rationalization signal. Building that reconciliation is genuinely hard analytical work, not a mechanical merge: it requires architects and business stakeholders from both organizations to work through each pair of candidate-matching capabilities and decide whether they are - truly the same ability described differently, - meaningfully different abilities that happen to sound similar, - or a partial overlap where one company's capability is a subset of the other's broader one. Getting this wrong in either direction has real cost: | The mistake | What it costs | |---|---| | falsely merging two capabilities that were actually different | hides a genuine gap or forces an inappropriate application choice onto a business process it does not fit | | falsely keeping them separate | hides real duplication and lets the synergy case understate its own savings | ## The decisions that follow Once the reconciled map exists, the actual rationalization decisions follow the same logic as single-company mapping, just at higher stakes: for each capability where both legacy companies bring an application, you assess **technical health, cost, scalability, and strategic fit** for the combined entity, and choose one to keep, or occasionally neither, if a fresh best-of-breed replacement makes more sense than either legacy option. This produces the concrete deliverable M&A integration teams are actually asked for - a prioritized application-decommissioning and consolidation roadmap with a dollar synergy figure attached, which is usually the artifact that was promised to the board or the market as part of the deal's business case. ## The core trade-off: speed versus fidelity The core trade-off in how this gets executed is **speed versus fidelity**, and it is a genuinely difficult call rather than a solved problem. Post-merger integration usually operates under real time pressure - synergy targets are often publicly committed with a timeline attached, and the deal team wants an actionable rationalization roadmap within months, not the year-plus that a rigorous, fully validated capability reconciliation might take. A fast, coarse reconciliation, matching capabilities mostly on name and rough scope with limited deep validation, gets a roadmap moving quickly and captures the obvious, high-confidence duplication such as two ERPs, two email systems, or two HR platforms, which is usually where a large fraction of the total synergy value sits anyway. But it risks two costly errors: - **masking real differences behind similar-sounding capability names**, such as one company's Regulatory Reporting for a US-only business and another's Regulatory Reporting for a business also operating under EU regulation, which are not actually the same capability, and forcing them onto one application choice can create a compliance gap that surfaces only later; - **steamrolling genuine cultural or process differences** that made each company's version of a duplicate capability actually work well for its context, producing integration friction and change resistance that undermines the very synergy the rationalization was meant to deliver. A slower, more rigorous reconciliation reduces both risks but can miss the window when the organization has attention and urgency for integration work - post-merger focus and executive sponsorship for this kind of exercise tends to decay sharply after the first year, and a more-correct-but-too-late map may end up driving less real consolidation than a good-enough-and-timely one would have. ## The second trade-off: whose model wins A second, related trade-off is how much of the acquired company's capability model to preserve versus overwrite with the acquirer's own. Politically and practically, post-merger capability mapping is rarely a neutral exercise between equals - the acquiring company's EA team usually builds the reconciled model, and there is a real risk of unconsciously mapping everything onto the acquirer's existing capability language and granularity, effectively treating the acquired company's business as a subset of the acquirer's rather than genuinely reconciling two independent views. This can produce a map that looks complete but has quietly erased capabilities the acquired company had that the acquirer did not, often exactly the capabilities that motivated the acquisition in the first place, such as a specialized underwriting capability, a niche regulatory certification, or a distinctive customer segment. A principal-level architect running this exercise needs to actively guard against that bias, for instance by having the reconciliation reviewed jointly rather than delivered one-directionally. ## A concrete scenario A concrete scenario: a US insurer acquires a smaller European competitor specifically for its EU-compliant digital claims-processing capability, something the acquirer lacked. If the post-merger capability mapping exercise naively reconciles Claims Processing as one line and picks the acquirer's larger, more mature legacy claims system as the consolidation target purely because it scores higher on generic technical-health metrics, it would destroy the exact capability the deal was done to acquire. A properly executed reconciliation instead keeps Claims Processing as one capability but recognizes it now has two meaningfully different sub-scopes, US claims and EU-regulated claims, that should not be forced onto a single application just because they share a capability name - the rationalization roadmap consolidates where genuine duplication exists elsewhere, such as HR systems and the general ledger, while explicitly preserving the acquired capability the deal was built around.