When two companies merge, they also merge two application portfolios, and almost nothing about those portfolios is designed to fit together. Duplicate systems, overlapping licences, undocumented integrations, and tools nobody in IT knows about all arrive on day one. Application rationalization is the part of an M&A integration strategy that works through that combined portfolio and decides, system by system, what happens next. Done well, it reduces cost and complexity. Done badly, it breaks the business processes the merger was meant to strengthen, and the damage compounds downstream.
What Application Rationalization Means When Two Companies Merge
Application rationalization means evaluating each system in a portfolio and deciding its fate. In an M&A context, it differs from a standard IT portfolio review in three ways: the timeline is compressed, the politics are higher-stakes, and on day one the inventory is incomplete on at least one side.
The scope covers everything: ERP and CRM platforms, internal tooling, SaaS subscriptions, legacy on-premise systems, and custom-built software that has never been formally catalogued. The hardest case is the dual-codebase scenario, where both companies have built or heavily customised their own versions of the same system. That case is covered in its own section below.
Building the Combined Application Inventory First
You can’t rationalize what you can’t see. The first task is a full discovery pass across both entities before any disposition decisions are made.
Start with the sources that give the most coverage fastest. Single sign-on and identity providers record which applications users actively authenticate into, so they are a quick way to surface most sanctioned and SaaS applications in use. Software asset management data adds licence counts, installation records, and utilisation. Together, these two sources usually account for the majority of licensed applications.
The acquired company’s documentation gap is a real problem. Many smaller organisations have no configuration management database (CMDB, a record of all IT assets and their relationships) and no application register. When that’s the case, interview department heads directly. Ask what tools their teams use daily, what they’d lose if their laptop were wiped, and what they pay for personally that IT doesn’t know about. Shadow IT, meaning software bought outside the formal procurement process, tends to surface this way.
The output of this phase is a single inventory entry for every application, tagged by owner, business function, user count, contract expiry date, and integration dependencies. Inventories assembled under deadline pressure are almost always incomplete, and gaps discovered late are one of the most common reasons integration timelines slip. Skipping or rushing this phase saves time only on paper.
The Four-Category Decision Framework
Once the inventory is complete, every application needs a disposition. The retain-retire-consolidate-replace model gives four clear options.
| Decision | What It Means | Typical Use Case | Key Risk |
|---|---|---|---|
| Retain | Keep as-is, no change | No overlap; unique business function | Technical debt accumulates if review is deferred too long |
| Retire | Decommission with no replacement | Duplicate or abandoned system | Hidden dependencies missed before cutoff |
| Consolidate | Move users from one instance to another of the same system | Two instances of the same CRM; two directory domains | Data migration complexity; user disruption |
| Replace | Both systems retire; a third is selected | Neither system meets combined needs | Longest timeline; heaviest change management burden |
Each decision should be driven by five factors: total cost of ownership (licensing, support, and internal administration), active user count and adoption, depth of integration with other systems, vendor support status and product roadmap, and any regulatory or compliance dependencies.
Consolidation where both companies use the same vendor but different instances is often the most politically charged case. Two instances of the same CRM look like an easy merge on paper. In practice, each carries years of custom objects, workflow rules, and integrations that don’t transfer cleanly. Once migration engineering time is counted, consolidation is not always cheaper than replacement.
The acquiring company’s preference is not automatically the right answer. Buyer-led consolidation that ignores a technically stronger system from the acquired company destroys value. The decision criteria should drive the outcome, not organisational hierarchy.
The Dual-Codebase Problem
When both companies have built or heavily customised their own version of the same capability, such as a pricing engine, a customer portal, or a modified ERP, the standard framework needs extra care. These systems encode years of business rules, often undocumented, and the people who understand them may be at risk of leaving during the integration.
Three practices help. First, document the business logic before evaluating the code; the rules a system enforces matter more than how it’s written. Second, compare the two systems against the combined organisation’s future requirements rather than against each other, which keeps the decision from becoming a contest between teams. Third, plan for knowledge retention explicitly, because losing the engineers who built a system can turn a manageable migration into a reverse-engineering project. In many cases the right answer is to run both systems in parallel for a defined period while a merged or replacement solution is built.
How to Sequence the Rationalization Program
Sequencing by risk tier produces better results than working department by department. The order that tends to work in practice is as follows.
- First wave: low-risk SaaS with short contract cycles and no deep integrations. Duplicate project management tools, standalone analytics subscriptions, and productivity apps fall here. These are quick wins with low migration effort and real licensing savings.
- Second wave: shared infrastructure and identity systems. Consolidate directory domains, single sign-on, and endpoint management before touching business applications. If identity isn’t unified, everything downstream is harder.
- Third wave: core business systems. ERP, CRM, and HR systems carry the most risk, require the most migration planning, and have the deepest integration maps. They should not be touched until the inventory and decision framework are fully validated.
The most costly mistake in M&A rationalization is decommissioning a system before its data has been migrated or archived. A close second is retiring an application that feeds data to other systems without first remapping those connections. Both failures come from skipping dependency mapping.
Types of Tooling That Support Rationalization
No single tool covers the full scope of a rationalization program. Most programs combine two or three categories.
Enterprise architecture and dependency mapping tools visualise how applications connect to one another. That dependency information is what makes it safe to retire anything. Some IT service management platforms include discovery modules that perform similar mapping, which can be worth using if one is already in place.
SaaS management platforms show which subscriptions are actively used versus abandoned, often broken down by department with usage or engagement data. This is especially useful for the first rationalization wave.
Software asset management tools track licence compliance and utilisation. They identify unused licences that can be reclaimed before the next renewal cycle, which is where much of the near-term cost reduction comes from.
When choosing tools, prioritise what the combined organisation already owns. Introducing new platforms mid-integration adds onboarding work at the moment teams have the least capacity for it.
Managing Business Units Through System Retirements
The hardest part of rationalization usually isn’t technical. It’s telling a sales team their CRM is being replaced, or a finance team their reporting tool is going away in 90 days.
Assign a named business owner to every application in the portfolio. Rationalization decisions made without the people who use a system tend to get reversed or worked around. A business owner involved in the decision means it reflects actual usage rather than assumptions.
A communication sequence that works is: decision announcement with rationale, migration timeline with milestones, training plan for the replacement system, and a defined cutover date with a rollback window. Each step needs to happen in order. Announcing a cutover date before the training plan is ready quickly erodes trust.
Watch for shadow IT when business units feel excluded. Teams that lose a tool they depend on will often find an unapproved replacement within weeks, which then appears in the next inventory as undocumented spend. The fix is inclusion, not enforcement.
Where Rationalization Programs Fail
Rationalizing before the inventory is complete is the most common failure. Decisions made on partial data produce a second wave of problems when undiscovered systems surface months later.
Treating rationalization as a one-time project is the second. Both parts of the business keep buying software after close. Without ongoing governance, the portfolio fragments again within a year or two.
Delay has a cost too. Application maintenance and support already consume a large share of most IT budgets, and a post-merger portfolio that is left untouched doubles much of that spend. Every month of delay means duplicate licensing, redundant support contracts, and engineering time spent maintaining systems that should have been retired.
What a Finished Rationalization Program Produces
The concrete outputs are a single application register with assigned dispositions and owners, a decommission schedule with data migration sign-offs, a reduced and documented integration map, and a licence consolidation report showing where spend was cut and why.
Rationalization isn’t finished when the last system is retired. It’s finished when the governance is in place to stop the portfolio from fragmenting again: a defined intake process for new software purchases, a recurring portfolio review cadence, and clear ownership of the application register.
The core sequence is simple: inventory first, dependency mapping second, decisions third. Reversing that order is where most programs go wrong.
Frequently Asked Questions
What is the first step in rationalizing applications after a merger?
Build a complete inventory of both companies’ applications before making any decisions. Use single sign-on data, software asset management records, and interviews with department heads to surface shadow IT. Decisions made on an incomplete inventory create a second wave of problems later.
How do you decide which applications to keep, consolidate, or retire?
Apply the retain-retire-consolidate-replace model using five criteria: total cost of ownership, active user count, integration depth, vendor roadmap, and regulatory or compliance dependencies. The acquiring company’s preference is not automatically the right answer; let the criteria drive the outcome.
Which applications should be rationalized first?
Start with low-risk SaaS tools that have short contract cycles and no deep integrations. Then consolidate identity and infrastructure systems. Leave core business systems such as ERP and CRM for the third wave, after the inventory and decision framework are validated.
What kinds of tools support application rationalization?
Most programs combine enterprise architecture or dependency mapping tools, SaaS management platforms for subscription visibility, and software asset management tools for licence utilisation. At least two of these categories are usually needed to cover the full portfolio.
Who owns the decision to retire an application?
Assign a named business owner to every application. IT, finance, and the business unit all have a stake, but one person needs to hold the final call to prevent stalemate, and decisions should be made with the people who use the system rather than imposed on them.
David Pisse, a seasoned software developer and AI enthusiast, brings over a decade of experience in innovative technology solutions. With a passion for blending AI with traditional development practices, David offers unique insights into the future of software engineering.
