The target company’s billing system was flagged as redundant in week three of the integration workstream. The acquirer had its own billing platform, the combined entity would not need two, and the target’s system appeared to duplicate functionality. It was scheduled for retirement at the six-month mark. At month five, the migration team discovered that the target’s billing system did not just generate invoices, it contained forty years of jurisdiction-specific tax calculation logic across sixty-three countries, embedded in COBOL programs that had been maintained by a team of developers who had all accepted severance packages in month two. The acquirer’s billing platform handled eighteen countries. The retirement decision was reversed, the developer team had to be reconstructed at emergency contract rates, and the synergy timeline extended by fourteen months.
The rationalization decision was made on the basis of what the system appeared to do. It should have been made on the basis of what the system actually did. These are different things in every application portfolio, and they are most different in portfolios that include legacy systems with decades of accumulated business logic, undocumented dependencies, and institutional knowledge that exists nowhere except in the code.
Know Before You Rationalize
SMART TS XL extracts the embedded rules, jurisdictional logic, and calculation branches that application labels and owner interviews never reveal.
FIND OUT MORE…Why M&A Creates the Portfolio Rationalization Imperative
When you combine two companies, you are immediately forced to rationalize the applications from each side to create a unified, consolidated holding. In that high-pressure environment, the ability to rapidly merge systems determines how fast the new entity can operate efficiently.
The rationalization is not optional. Two organizations that each ran their own ERP, CRM, HRMS, billing platform, reporting suite, and data warehouse now have two of everything. The combined cost of maintaining parallel systems, licensing, infrastructure, support, and the operational overhead of running two instances of what should eventually be one, is the primary driver of the cost synergies that justified the acquisition price. Integration timelines are written into the deal model. Synergy realization is tracked by the board. Failure to rationalize on schedule does not just miss a financial target, it calls into question the strategic logic of the deal.
Most companies tend to accumulate a large information technology application portfolio over time, especially if they grow through M&A and do not fully integrate operations and assets after each transaction. When viewed holistically, many of these applications may not align with the company’s overall M&A strategy; they were created as point-in-time solutions and do not necessarily support post-deal, enterprise-level business and organizational objectives.
The scale of the problem compounds with each successive acquisition. An organization that has grown through serial acquisition without rigorous post-merger portfolio integration carries the accumulated technical debt of every deal it has not fully digested. The average large enterprise runs over 370 SaaS applications. Between 25 and 30 percent of those licenses are unused or significantly underutilized. Organizations are leaving an estimated $19.8 million in unused licenses on the table annually. Add the legacy application layer, the COBOL programs, proprietary ERP customizations, and mainframe batch systems that do not appear in SaaS license audits, and the portfolio that rationalization must address is substantially larger than the SaaS inventory suggests.
The Three Gaps That Cause Rationalization Failures
The rationalization decisions that produce the fourteen-month timeline extension are not failures of execution. They are failures of information. Three specific information gaps recur in post-merger rationalization programs:
Gap 1: Stated purpose versus real purpose
The application owner describes what the system was designed to do. After years or decades of accumulated customization, the system does substantially more. A CRM that “manages customer relationships” may also run the quarterly commission calculation, handle exception processing for the largest accounts, and maintain the only copy of certain contract terms in a format that downstream reporting depends on. None of this is in the application owner’s description because none of it was in the original requirements. It accumulated one workaround at a time, each solving an immediate problem without updating anyone’s description of the system’s purpose.
The cost of discovering Gap 1 after retirement: rebuild the hidden functions in the replacement system, often at emergency cost, while the business operates without them or with manual workarounds.
Gap 2: Undeclared dependencies
The application appears standalone. Twelve other systems depend on its output. The dependency was never formally documented because it was established through an informal data feed that a developer set up three years ago to solve a reporting problem. The application’s owner does not know about the dependency. The dependent systems’ owners know they receive the data but assume it comes from “the billing system” without knowing which program specifically produces it.
Dependencies the inventory never listed, one application looks disposable because no one mapped what relied on it. The cost of discovering Gap 2 after retirement: twelve systems fail or degrade in ways that trace back to a dependency that should have been in the rationalization analysis but was not.
Gap 3: Data migration scope underestimation
The data migration plan estimates the target system’s schema based on current documentation. The schema has forty-seven variants accumulated over forty years of business rule changes, with three documented and forty-four visible only in the program code that reads and writes the data. The data migration effort is scoped against the three documented variants and completes on schedule. Post-migration, the processes that relied on the forty-four undocumented variants fail silently, producing incorrect outputs that are not detected until a quarterly report or regulatory submission reveals the discrepancy.
The cost of discovering Gap 3 after migration: root cause analysis, data correction, reprocessing, and in regulated industries, regulatory notification and remediation.
The Five Rationalization Decisions
Every application in a combined portfolio maps to one of five rationalization outcomes. The decision framework applies to both legacy and modern applications, though the evidence required to make the decision differs significantly:
| Decision | Definition | When to Apply | Primary Evidence Required |
|---|---|---|---|
| Keep | Retain in current form, operated by the combined entity | Unique functionality, no equivalent in the other portfolio, adequate quality | Business function mapping, dependency analysis |
| Consolidate | Merge functionality from both portfolio versions into one surviving instance | Both organizations run equivalent functions; one instance is superior | Functional overlap analysis, feature gap assessment, migration complexity |
| Modernize | Retain the business function, transform the technical implementation | Function is required, but technical quality is too poor to maintain long-term | Code quality metrics, complexity scoring, technical debt assessment |
| Replace | Retire the application, substitute a commercial or cloud-native alternative | Function is commodity; a standard product serves it adequately | Market availability of alternatives, customization depth assessment |
| Retire | Decommission without replacement | Function is genuinely redundant, no unique logic, no active consumers | Dead code analysis, dependency mapping confirming zero active consumers |
The decision that looks like Retire but is actually Keep: An application with no active users, low transaction volume, and no visible downstream consumers appears to be a Retire candidate. If it contains unique business logic, jurisdictional tax rules, regulatory calculation routines, contractual obligation processing, that has not been replicated elsewhere, retiring it means losing that logic permanently. This is the billing system scenario from this article’s opening. The decision appears obvious from the inventory; it is wrong by the evidence.
The Structural Analysis Prerequisite
Application rationalization during M&A is the keep, migrate, consolidate, or retire decision that belongs in the deal model before close. Parallel licenses, hidden integrations, and retirement sequencing are the real cost.
Making these decisions accurately requires structural evidence that goes beyond what application owners can provide in interviews, what IT asset management systems record, and what SaaS license audits surface. For the legacy application layer, the COBOL systems, custom-built batch programs, proprietary middleware, and database-backed business applications that have been running for decades, the structural evidence exists only in the source code.
Four structural analysis outputs that rationalization decisions require:
Business logic inventory. What rules does the application encode? Not the functional description provided by its owner, but the specific calculations, conditional branches, validation rules, and transformation logic that are implemented in the program code. For COBOL programs, this means parsing the PROCEDURE DIVISION to extract the IF/EVALUATE logic, the COMPUTE statements, and the conditional processing paths that implement the business rules. This inventory is the specification that any replacement or consolidating system must match.
Fan-in analysis. How many other applications, programs, or processes depend on this application’s outputs? Fan-in is the primary predictor of retirement risk: an application with zero fan-in can retire safely; an application with fifty fan-in carries the risk that retirement will break fifty other things. In legacy environments, fan-in includes not just direct API calls but data feed dependencies, shared VSAM file consumers, JCL job streams that invoke the program, and downstream batch processes that read its output datasets.
Dead code percentage. What percentage of the application’s code is unreachable from any production execution path? Dead code that has accumulated through decades of feature additions and bug fixes inflates the apparent complexity of the application and the apparent cost of modernization. Identifying and excluding dead code from the rationalization scope produces a more accurate picture of what must actually be migrated, consolidated, or replaced.
Data migration complexity. What is the record layout structure of every dataset the application manages? How many REDEFINES variants exist? What COMP-3 fields require precision-preserving target type mapping? What business rules govern the data that the application’s consumers depend on? The answers determine whether the data migration is a straightforward schema conversion or a multi-month data transformation program.
The 100-Day Timeline: When Speed Conflicts With Thoroughness
The 100-day integration plan is the industry benchmark for post-merger execution velocity. Investors, board members, and management consultants measure integration success against this timeline. The pressure to demonstrate early synergy realization, to show the market that the deal is working, compresses every workstream, including application rationalization.
The conflict between timeline pressure and analysis thoroughness is where rationalization programs generate their most expensive mistakes. An organization that cannot complete a thorough structural analysis of its combined portfolio within 100 days faces a choice: make rationalization decisions on incomplete information, or miss the timeline and face questions about integration execution.
The resolution that mature acquirers have developed is not to compress the analysis but to sequence the decisions:
Wave 1 (days 1-30): Clear and unambiguous decisions only. Applications that are clearly redundant with zero unique logic, applications that are clearly Keep with no consolidation candidate, applications that are already scheduled for retirement in one organization’s roadmap. These decisions do not require deep structural analysis because the outcome is not in doubt. Making them quickly demonstrates integration momentum without the risk of making wrong decisions on incomplete information.
Wave 2 (days 31-90): Decisions that require targeted analysis. Applications that appear redundant but whose rationalization outcome depends on specific structural evidence: is there unique business logic? What is the fan-in count? How complex is the data migration? The structural analysis is commissioned specifically for the applications in this category, focusing resources on the decisions where analysis changes the outcome.
Wave 3 (days 91+): Decisions that require extended analysis. Applications whose complexity makes 90-day rationalization decisions genuinely inappropriate, legacy systems with decades of accumulated logic, shared data platforms serving both organizations, mission-critical batch programs whose behavior is not fully understood. These are explicitly deferred with documented rationale, not rushed to a wrong answer.
This sequencing approach reconciles the timeline pressure with the thoroughness requirement: early waves demonstrate momentum; later waves protect against the catastrophic wrong decisions that generate the fourteen-month timeline extensions.
Divestiture: The Reverse Problem
Acquisitions create the need to consolidate two portfolios into one. Divestitures create the inverse problem: separating a portfolio that was built as an integrated whole into two independent portfolios that can each operate without the other.
In a divestiture context, the SpinCo often starts its new life with a bloated portfolio consisting of the existing applications used solely by the SpinCo and the applications it shared with the ParentCo, such as HR and ERP. The ParentCo, meanwhile, is frequently left with stranded costs for applications it shed along with the SpinCo.
The divestiture rationalization challenge is fundamentally different from the acquisition challenge because the separability question must be answered first: can this application operate independently, or is it integrated with the remaining organization in ways that make clean separation impractical?
A COBOL program that serves the divested business unit but reads from a shared mainframe database that also serves the remaining business unit is not cleanly separable. The separation options are: replicate the database (with the complexity of maintaining synchronization during transition), migrate the divested program to a new database instance (with the complexity of data migration and the risk of behavioral divergence), or continue the shared access arrangement post-separation (with the governance complexity of two independent entities sharing data infrastructure).
Each of these options has different cost, risk, and timeline implications. None of them can be evaluated without knowing exactly how the program uses the shared database, which tables, which fields, in which access patterns, with what volume and frequency. This is structural analysis of the legacy code, not documentation review.
Legacy Code in M&A: The Dimension Nobody Accounts For
The SaaS rationalization problem, which applications to keep, which contracts to terminate, which vendors to consolidate, is well-served by existing tools and frameworks. The legacy code rationalization problem has no equivalent tooling support in most organizations.
When both the acquirer and the target run mainframe COBOL systems for their core business processing, the rationalization decision requires answering questions that application owner interviews and IT asset management systems cannot answer:
Which COBOL programs are unique to each organization? The acquirer’s mainframe portfolio and the target’s mainframe portfolio may overlap in function (both run account management) while diverging in implementation (each has decades of unique business rule accumulation). Identifying true functional overlap requires parsing the programs, not reading the labels.
Which programs are shared infrastructure versus business-unit specific? A JCL utility program called by forty programs across the combined organization is shared infrastructure. A COBOL calculation routine called by three programs serving a single business unit is business-unit specific. Fan-in analysis across the combined program inventory produces this classification automatically.
cobol
*> Target company's tax calculation -- 40 years of jurisdiction rules
*> 63 countries, 847 tax rule conditions, embedded in this program
*> Not documented anywhere except in this PROCEDURE DIVISION
CALCULATE-TAX.
EVALUATE WS-COUNTRY-CD
WHEN 'US' PERFORM US-TAX-CALC
WHEN 'UK' PERFORM UK-VAT-CALC
WHEN 'DE' PERFORM GERMAN-MWST-CALC
WHEN 'FR' PERFORM FRENCH-TVA-CALC
*> ... 59 more WHEN clauses
WHEN OTHER PERFORM DEFAULT-TAX-CALC
END-EVALUATE.
This program produces a specific, auditable output for every jurisdiction it handles. Retiring it requires either replicating every WHEN clause and every underlying PERFORM target in a replacement system, or accepting that the replacement will produce different outputs for some jurisdictions. Neither outcome is visible from the application inventory. Both are visible in the COBOL source.
What is the data migration scope for each application? The data associated with a legacy COBOL application is defined in FD entries and copybooks that may have accumulated multiple REDEFINES variants, COMP-3 fields requiring precision-aware mapping, and embedded validity constraints captured in 88-level condition names. Data migration scoped against the documentation rather than the actual schema produces the Gap 3 failure.
Which programs contain dead code that can be excluded from migration scope? Dead code in legacy programs inflates the apparent modernization or migration complexity. Programs with 40 percent dead code require the analysis and migration of 40 percent more code than the live production behavior actually demands. Identifying dead code before migration scope is locked reduces effort estimates and improves timeline accuracy.
Application Decision Checklist for M&A Portfolio Rationalization
For each application in scope, the following evidence is required before a rationalization decision can be made with confidence:
Business logic assessment
- Has the application’s actual function been verified through code analysis, not just owner interview?
- Are all business rules embedded in the code documented in a form that a replacement must match?
- For COBOL programs: have all EVALUATE branches, IF conditions, and COMPUTE statements been inventoried?
Dependency assessment
- Has fan-in been measured structurally (not estimated by the application owner)?
- Are all data feed dependencies, JCL-level, file-level, and database-level, enumerated?
- Have dynamic CALL dependencies been traced, not just static call graph edges?
Data migration assessment
- Has the complete record layout been extracted from FD entries and COPY members?
- Have all REDEFINES variants been identified and their discriminating conditions documented?
- Have all COMP-3 and binary fields been mapped to precision-appropriate target types?
Dead code assessment
- Has dead code been identified and excluded from migration scope estimates?
- Are retirement decisions confirmed by dead code analysis (zero fan-in from production execution paths)?
Risk classification
- Has the application’s criticality score been verified against the structural analysis findings?
- Is the retention, migration, or retirement timeline consistent with the dependency complexity?
How SMART TS XL Supports M&A Portfolio Rationalization
SMART TS XL provides the structural evidence layer for the rationalization decisions that cannot be made correctly on the basis of documentation and interviews alone.
The static code analysis capability extracts the business logic inventory from COBOL, JCL, Java, Python, and every other language in both organizations’ portfolios, producing the complete picture of what each application actually does, not just what its label says. For COBOL programs like the tax calculation example above, this analysis enumerates every jurisdiction, every rule condition, and every calculation branch that a replacement must implement to produce equivalent results.
The application dependency mapping provides the fan-in and fan-out analysis that determines retirement risk and consolidation sequencing. For both organizations’ portfolios analyzed simultaneously, the dependency map shows which programs are truly standalone, which are deeply integrated into shared infrastructure, and which carry the hidden downstream dependencies that Gap 2 failures are made of.
The impact analysis capability makes every proposed rationalization decision testable before it is executed: if this program is retired, which other programs lose a dependency? If this dataset is migrated, which programs must be updated to read from the new location? The impact scope of every proposed decision is enumerable from the structural model, converting rationalization decisions from risk estimates into defined, scoped plans.
The legacy modernization analysis produces the complexity scoring and dead code identification that makes effort estimates accurate: programs in the bottom quartile of complexity with high dead code percentage are strong Retire or Modernize candidates; programs in the top quartile of complexity with high fan-in are Keep candidates regardless of apparent redundancy.
The enterprise search capability makes the combined portfolio queryable throughout the rationalization program: find every program that accesses a specific dataset, every program that implements a specific business function, every COBOL program with cyclomatic complexity above a threshold, in seconds, across both organizations’ combined millions of lines of code.
For organizations conducting rationalization under timeline pressure, SMART TS XL’s analysis compresses the structural analysis timeline: the complete dependency map, business logic inventory, and complexity scoring for a combined portfolio can be produced in days rather than the weeks or months that manual code review would require. That compression is what makes the Wave 1 / Wave 2 / Wave 3 sequencing approach viable, the targeted structural analysis for Wave 2 applications can be completed within the 90-day window that the timeline allows.
The Decision You Make Is Only as Good as the Evidence Behind It
Post-merger portfolio rationalization operates under genuine time pressure, genuine financial pressure, and genuine organizational pressure to demonstrate that the deal is working. All of these pressures push in the direction of faster decisions. None of them change the cost of making the wrong decision.
The billing system that was scheduled for retirement and then un-retired at emergency cost is not a cautionary tale about moving too slowly. It is a cautionary tale about moving without the evidence that would have changed the decision. The structural analysis that reveals what a system actually does, its embedded business logic, its hidden dependencies, its data migration complexity, does not make rationalization slower. It makes rationalization accurate. And accuracy, in the context of a post-merger integration program where wrong decisions generate eighteen-month timeline extensions and nine-figure cost overruns, is the most valuable property a rationalization decision can have.
The portfolio rationalization that succeeds is not the fastest one. It is the one that knows what it is rationalizing.
