Why Pharma Rationalization Is Not Like Other Industries

Application portfolio rationalization is a mature discipline in banking, retail, and manufacturing. The playbooks from McKinsey, Deloitte, and the enterprise architecture community translate reasonably well: inventory, score, categorize, decide, execute. What makes pharma and biotech different is not the framework. It is the regulatory memory that attaches to almost every operational system.

A retail bank that decommissions an old loan-origination platform migrates the account records and moves on. A pharma company that decommissions an old LIMS or CTMS is committing to keep those records available, readable, and traceable for the entire product retention period, which for many products spans decades.4 The MHRA and other inspectorates expect audit trails and the ability to reconstruct the original data long after the underlying system is gone. GAMP 5 treats decommissioning as a high-risk lifecycle event precisely because most companies fail this phase: they either unplug the system prematurely or leave the data “somewhere” without a governed archive.5

$106B Biopharma M&A value in H1 2026 across 201 transactions1
25-40% Typical SaaS spend reduction in the first 90 days of merger integration3
85% Of IT leaders name lack of application visibility as a significant threat6

The second complication is scientific continuity. Retail bank rationalization rarely interrupts revenue. In pharma, an in-flight Phase 3 trial with 500 sites and seven thousand patients cannot be paused while you migrate the EDC. Veeva’s much-cited migration of a top-twenty biopharma to Vault EDC moved 55 million data points and five million forms across 25 ongoing studies precisely because most companies had refused to attempt in-flight EDC migration for years.7 If the deal thesis depends on consolidating clinical operations onto a single platform, that constraint has to be planned for in month one, not discovered in month five.

The third complication is the shape of the acquirer’s IT estate. Duplicative pharma systems are not just “two CRMs.” They are often two ERPs with different chart-of-accounts structures, two quality documents systems with different GxP change control records, two pharmacovigilance safety databases (ArisGlobal Argus and Oracle AERS is a common pattern), two regulatory information management platforms, and two document management systems that have both been validated to different qualification specifications.8 The consolidation candidates are almost never in the same architectural state.

SD perspective. The consulting-industry stat that “companies save 10 to 30 percent by reducing their application portfolio” is real, but the pharma-specific version is that most of the savings arrive in months three through nine, not months one and two. The first two months are almost entirely spent understanding what the acquired entity actually uses, versus what its asset register says it uses. Budget accordingly.

Month One: Discovery and Inventory

The first month exists to answer a single question: what applications does the combined organization actually run today? Not what the CIO thinks, and not what the asset management system claims. What is really in production, with real users, real integrations, and real data.

The reality on the ground almost never matches the acquirer’s expectations. McKinsey’s often-cited retail bank case study is instructive: the portfolio assessment surfaced more than fifty unused applications, 150 redundant applications, 800 point-to-point interfaces, and 400 applications ripe for connection to a data integration platform.9 Even in a heavily governed pharma environment, the SaaS sprawl statistics are sobering. Flexera’s 2026 State of ITAM report notes that eight percent of organizations do not track SaaS costs at all, up from five percent the year before, and SaaS wasted spend continues to increase year over year.6

The application inventory template

Every entry in the combined inventory should carry at minimum the following fields. The template is straightforward. The discipline of filling it out honestly for every application is where discovery earns its keep.

Field Purpose Common failure mode
Application name and business function Anchors the record and enables duplicate detection Business function stated too broadly; two “CRMs” turn out to serve different personas
Vendor, version, hosting model Establishes contract and technical footprint SaaS versions understated because minor releases are opaque to procurement
GxP scope and validation status Determines regulatory obligations during migration or sunset Systems that touch GxP data are misclassified as non-GxP because they are “just reporting”
Business owner and IT owner Assigns decision authority Owner has moved on; system has no accountable executive
Active user count (last 30 / 90 days) Reveals dormant licenses and shadow retirement Named-license counts, not active-user counts, are recorded
Annual total cost (license + hosting + support + FTE) Establishes rationalization economics FTE support cost and shared infrastructure are excluded
Upstream and downstream integrations Surfaces dependencies and hidden coupling Only documented integrations are captured; nightly file drops and RPA bots are missed
Data classification (PII, PHI, IP, GxP records) Drives retention, residency, and access decisions Data classification is inherited from parent system and never re-examined
Contract renewal date and termination clause Sets the natural sunset window Renewal is on auto-renew and the notice window is already past

Two operational notes. First, active user counts should come from the applications themselves, not from the identity provider. A Salesforce plan with 2,000 seats often turns out to have hundreds of users who have not logged in for 90 days.3 Second, integration mapping needs both a top-down view (what the enterprise architecture team believes exists) and a bottom-up view from application logs, API gateway telemetry, and ETL job schedulers. Every serious rationalization program has been surprised at least once by a mission-critical nightly job that no one in the CIO’s office remembered existed.

Practical tip. Do not wait for a perfect inventory before starting month-two categorization. Aim for 90 percent coverage of applications that represent 95 percent of spend by the end of week three, then let the last long tail catch up. Perfection here becomes an excuse to delay decisions.

Discovery tooling

Most acquirers have some combination of a ServiceNow CMDB, a SAM (Software Asset Management) tool, and possibly an enterprise architecture platform such as LeanIX. These become the aggregation layer during discovery. LeanIX’s out-of-the-box ServiceNow integration is a common pattern: LeanIX enriches the application portfolio with business, functional, and technical fit data, while ServiceNow provides the operational reality of tickets, changes, and incidents.10 The acquired entity’s data typically has to be manually staged into the acquirer’s tooling; this is a non-trivial two-to-three-week workload.

Interview cadence and business ownership

Tooling alone will not surface the applications that matter most. Every business function of any consequence, commercial, clinical, medical affairs, regulatory, quality, manufacturing, finance, and HR, needs a structured interview during weeks one and two. The interview should cover three questions: what applications does your function actually depend on to do its work, what data flows in and out, and what would break if the acquirer removed each one tomorrow. The answers are rarely a clean match to the inventory produced by IT tooling. Business owners routinely name applications the CMDB missed, particularly departmental SaaS purchased on credit cards, and they omit applications the CMDB is proud of but no one actually uses. The delta between the two views is usually more revealing than either view alone.

The interview process also establishes accountable ownership for every application on the list. An application without a named business owner and a named IT owner cannot be governed through the rest of the six-month program. If a candidate cannot produce owners in month one, that is itself a finding: it either does not matter enough to keep or it is a compliance risk that the governance program needs to correct before it can be rationalized.

Month Two: Categorization Using the TIME Framework

Month two applies the Gartner TIME framework (Tolerate, Invest, Migrate, Eliminate) to the discovered inventory. TIME has been the dominant application rationalization framework for over a decade because it is simple to communicate to non-technical executives and it forces a decision on every application.11

The framework evaluates every application on two axes:

  • Business fit. How well the application supports its intended business function. Assessed via structured interviews with business owners against criteria like strategic alignment, functional completeness, user satisfaction, and criticality to operations.
  • Technical fit. How well the application performs from an IT standpoint. Assessed against standards compliance, technical debt, reliability, performance, security posture, and integration health.
HIGH BUSINESS / HIGH TECH

Invest

Applications that support important business needs and are technically sound. In a merger, these are usually the target of platform-consolidation decisions. Invest in feature extension, integration hardening, and adoption.

HIGH BUSINESS / LOW TECH

Migrate

The business function is essential, but the current application is unfit. Replace with a modern equivalent from the combined portfolio, or a new selection. Migration in pharma often means to a validated cloud platform.

LOW BUSINESS / HIGH TECH

Tolerate

Technically fine but not delivering enough business value to justify investment. Freeze the roadmap, contain spend, and revisit annually. Common home for stable back-office systems whose users tolerate them.

LOW BUSINESS / LOW TECH

Eliminate

Redundant, obsolete, or unused. Sunset in a controlled manner. In pharma, elimination almost always requires a validated data archive plan before the plug can be pulled.

Adapting TIME for pharma M&A

The out-of-the-box TIME model needs a pharma-specific overlay. Three additions are essential.

First, add a validation dimension. Every application should carry a GxP flag and a validation status. An Eliminate decision on a validated system is not a decision to delete data; it is a decision to migrate data to an archive that itself must be validated. This affects both cost and timeline.

Second, add a clinical-continuity dimension. Applications supporting in-flight clinical trials cannot be migrated without disrupting the trial protocol, patient safety commitments, or the regulatory submission path. These systems may need to be Tolerated for the duration of the trial and Migrated only after database lock, even if their technical fit is poor.

Third, add an integration-graph score. An application with fifty inbound integrations is far more expensive to Eliminate than an application with two. Weight the disposition accordingly. This is where dependency mapping tools earn their place in the workflow.

Common categorization traps. Watch for three patterns: acquirer bias (every acquirer-owned system is scored higher than it deserves); champion protection (a departing executive’s favorite platform is kept alive out of political inertia); and the “we’ve always used it” tolerance category, which is often just deferred elimination with better manners. The steering committee’s job is to challenge these instincts, not indulge them.

Month Three: Impact Assessment for Validated Systems

Month three converts the TIME categorization into a decision-ready case for every consolidation candidate. This is where the theoretical portfolio view meets the operational reality of validated systems, integration dependencies, and license contracts. Three streams of analysis run in parallel.

Stream one: validated system impact

For every application flagged as GxP-validated, the impact assessment must specify:

  • Retention obligation. Which regulations (21 CFR Part 11, EU Annex 11, ICH E6, product-specific stability requirements) dictate the retention period, and for how long the data must remain readable and traceable.12
  • Archive strategy. Whether the retirement path will migrate the data to the surviving system, to a dedicated validated archive, or to a legal-hold read-only image. Each option carries different validation and cost implications.
  • Audit trail preservation. How the audit trail metadata, electronic signatures, and change history will be preserved. This is the requirement that most decommissioning projects underestimate. Audit trails must remain intact for the full retention period even after the originating system is gone.5
  • Access commitment. Who is accountable for producing a record from the archive if an inspector asks, and how quickly. If that person cannot demonstrate a working retrieval within a week during month three, the archive design is not ready.

The right outcome, as ISPE GAMP 5 puts it. Records remain accessible, readable, and traceable for the full retention period, with the same meaning they had when created. Anything short of that is a compliance failure waiting for an inspection.5

Stream two: integration dependency assessment

Each consolidation candidate is scored against its integration footprint. A retirement plan needs to answer: what other applications will break when this one goes away, and what is the cost of replacing each interface? For a mid-size pharma post-acquisition, this often surfaces integrations that no one owns: legacy point-to-point connectors, RPA bots that scrape a UI, custom middleware that has outlived its author. Mapping these takes time and requires access to network logs, ETL schedulers, and API gateway telemetry.

For pharma specifically, the integration graph almost always includes an unexpectedly large number of LIMS, MES, SCADA, and EDC connections. A NetSuite deployment integrated with a LIMS via a Boomi middleware layer, or a Veeva Vault Clinical Operations connection into an EDC platform, might look like one interface in the architecture diagram, but the underlying validation package covers half a dozen configured mappings.8 Retiring the source system without a compensating change to the interface, or the destination, breaks a validated state.

Stream three: license and contract consolidation

The financial case for consolidation is built in this stream. For each candidate:

  • Baseline current license spend, including negotiated discounts, over-provisioned seats, and true-up exposure.
  • Model the consolidated-state spend under the surviving contract, including any transactional cost increase from consolidation onto a single vendor.
  • Assess the timing of contract termination or non-renewal. Many SaaS contracts require 60 to 120 days written notice; if the notice window is missed, the savings arrive a full year later than the model assumes.
  • Identify vendors where the merger triggers a favorable renegotiation window. Combined-entity volume often unlocks pricing that neither party could obtain alone.

The savings potential is significant. Companies commonly experience 25 to 40 percent SaaS spend reduction within the first 90 days by streamlining licenses and optimizing contracts, and a 10 to 30 percent reduction across the broader portfolio over the full rationalization horizon.3 Bristol-Myers Squibb’s integration with Celgene, the largest pharmaceutical acquisition since Pfizer-Warner Lambert in 2000, was built on a $2.5 billion annual cost synergy target that BMS confirmed hitting by 2021.13 Applications and IT infrastructure were a meaningful contributor to that synergy pool.

Month Four: Steering Committee Decisions and Decision Authority

Month four exists to close every open decision. The rationalization playbook now has an inventory (month one), a TIME categorization (month two), and an impact assessment for each candidate (month three). What it does not yet have is executive commitment. Month four converts analysis into approved dispositions.

The steering committee model

A properly constituted steering committee for post-merger IT rationalization typically includes two to seven senior executives from both organizations.14 The core composition should include the CIO or IT integration lead, the head of quality, the CFO or a finance representative with M&A synergy accountability, the head of clinical operations (if clinical systems are in scope), the head of commercial operations (if commercial systems are in scope), and the integration management office lead.

1

Direction setting

Approve the rationalization thesis, target-state architecture, and total addressable synergy pool. This should be done once at program start and revisited only if the thesis changes.

2

Disposition approval

For each application, approve the TIME disposition, the target-state, and the sunset or migration timeline. This is where month-four gates happen.

3

Impasse resolution

Break ties between workstreams. If clinical and commercial disagree on the surviving CRM, the committee decides. This is one of the highest-value functions of the committee, and one of the least used.

4

Progress oversight

Monitor sunset execution and synergy realization against the model. Course-correct when actuals diverge from plan.

Decision authority framework

The steering committee should not decide everything. Effective governance publishes a decision-rights matrix that specifies what workstream leads can approve unilaterally, what requires committee endorsement, and what has to escalate.14 A simple framework:

Decision type Workstream lead Integration management office Steering committee
Sunset of application under $500K annual spend, no GxP scope Approve Notify Report
Sunset of application over $500K annual spend, no GxP scope Recommend Approve Notify
Sunset or migration of any validated GxP system Recommend Recommend Approve
Selection of surviving platform across duplicate functional systems Recommend Recommend Approve
Change to target-state architecture or synergy commitment Escalate Recommend Approve
Timeline changes that push into month seven or beyond Recommend Approve Endorse

The point of publishing this matrix is to prevent two failure modes. The first is committee overload, where every trivial decision escalates and the committee becomes a bottleneck. The second is silent divergence, where workstreams make consequential decisions that later collide because no one required visibility.

SD perspective. The most productive month-four committee meetings are the ones where the pre-read arrives four business days early and each candidate has a one-page brief containing the disposition recommendation, the financial case, the validated-system impact if any, the required interfaces, the risks, and the specific decision being asked for. Committees that operate without this discipline drift into open-ended discussion and approve fewer dispositions per hour.

Month Five: Sunset and Migration Execution

Month five is the execution month. All the analytical work of months one through four now converts into signed change orders, migration plans, contract terminations, and validated data archives. This is the month where most of the SaaS savings actually land, and it is the month where compliance risk is highest.

The sunset execution sequence

For every application scheduled for sunset, execution follows a repeatable sequence. The details vary by whether the system is GxP, but the sequence itself is stable.

1

Freeze new work

Stop new configuration, new integrations, and new user onboarding. Communicate the freeze widely enough that shadow demand does not reroute through workarounds.

2

Migrate active work

Move any in-flight processes, active users, and current records to the surviving system. This includes retraining users and cutting over integrations.

3

Extract and archive data

Move historical data to the designated archive. For GxP records, validate the archive against retention, retrieval, and audit-trail integrity requirements before the source is turned off.

4

Retire integrations

Decommission upstream and downstream connections. Repoint dependent systems to the surviving platform or the archive. Confirm no orphan traffic remains.

5

Terminate contracts

File formal termination notices, close licenses, and remove the application from IAM, MFA, and monitoring tooling. Track the actual date of contract exit for synergy attribution.

6

Formal closeout

Publish a decommissioning report signed by the business owner, IT owner, and (for GxP systems) quality. The report certifies that data has been archived and is retrievable, that the system is off, and that no known compliance obligations remain unmet.

Handling the transitional service agreement

Most pharma acquisitions include a transitional service agreement (TSA) under which the seller continues to provide operational services, often including hosting and support for legacy applications, for a defined period. TSAs typically run 12 to 18 months and cover critical services like IT, HR, and accounting.15 A well-designed rationalization plan uses the TSA as a decoupling instrument, not a delay device.

Practically, this means every application under TSA should have an explicit exit plan tied to a specific TSA milestone. The plan should either be to migrate to a buyer-owned platform before the TSA expires, or to renew the TSA for a defined extension with a clear reason. Applications that quietly slide from TSA month twelve to month eighteen to month twenty-four almost always cost the buyer more than the original synergy model.

The Veeva-style in-flight migration pattern

Clinical systems deserve special mention. The industry has historically avoided migrating ongoing studies because of technical challenges, complex data models, and risk concerns. Veeva’s migration of 25 ongoing studies (55 million data points, five million forms) for a top-twenty biopharma demonstrated that in-flight EDC migration is now feasible when the target platform provides proprietary migration tooling and validated migration procedures.7 The pattern applies to CTMS and Vault QualityDocs as well. Jazz Pharmaceuticals, formed through multiple acquisitions, deployed Vault QualityDocs enterprise-wide precisely to achieve a single source of truth across former divisions.16

Execution discipline. The teams that finish month five on plan are the ones that treat each sunset as a mini-project with a named owner, a critical path, and a defined closeout artifact. The teams that miss are usually the ones that treat sunset as a background task that happens between other priorities. If the sunset does not appear on someone’s weekly status update, it will not happen.

Month Six: Measurement and the Steady-State Handoff

Month six converts the rationalization program into a permanent capability of the combined organization. The deliverables are a measurement framework, a synergy attribution report, and a handoff of the ongoing portfolio governance to the standing IT function.

The synergy attribution report

Every application disposition should be reconciled against the financial case built in month three. For each application:

  • Baseline spend at deal close.
  • Committed savings in the M&A synergy model.
  • Actual sunset date and actual contract exit date.
  • Realized savings, calculated on an annualized basis.
  • Variance versus commitment, with narrative explanation.

The report should roll up to the same synergy target the deal was priced on. This is the artifact the CFO and the board will want to see. It is also the artifact that establishes credibility for the next round of rationalization.

The measurement dashboard

A standing dashboard should track, at minimum:

  • Applications retired versus plan.
  • Applications migrated versus plan.
  • Realized annualized savings versus committed synergy.
  • Number of applications under TSA and the TSA exit month for each.
  • Validated system decommissioning status, with archive verification checkpoints.
  • Open decisions, aged by workstream and by decision authority.
  • Any regulatory or audit observations tied to decommissioned systems.

The handoff to steady state

By the end of month six, the rationalization program should transition to a steady-state capability owned by enterprise architecture, IT finance, and quality (for GxP systems). The TIME framework becomes an annual portfolio review discipline rather than a one-time exercise. LeanIX and its peers describe application rationalization as a continuous process, not a one-time exercise, with portfolios reviewed regularly to reflect changes in the applications and in business needs.11 The point of month six is to make that ongoing review self-sustaining rather than dependent on the integration team.

Lessons carried into the next deal

Every rationalization program should conclude with a written retrospective that captures what the operating model got right, what took longer than expected, and what should be done differently the next time. Pharma acquirers who acquire regularly, and many of the large ones acquire two or three companies a year, benefit disproportionately from institutionalizing this learning. Common lessons include: start validated-system planning earlier than you think you need to, treat the TSA as a decoupling deadline rather than a runway, keep the steering committee small enough to make decisions rather than large enough to represent everyone, and be willing to declare a Tolerate disposition rather than pretending every legacy platform is a serious Migrate candidate. The teams that write down these lessons and reuse them across deals compound their integration capability with each successive transaction.

Regulatory Considerations for Retiring Validated GxP Systems

The regulatory considerations for retiring validated GxP systems deserve their own summary, because they are what separates pharma application rationalization from every other industry. Five principles govern the work.

Retention is a lifecycle obligation, not an event

21 CFR Part 11 imposes requirements on any computer system that creates, modifies, maintains, archives, retrieves, or distributes electronic records supporting GxP activities. Records must remain available and readable throughout the entire retention period, which for many products can extend for decades, often the lifetime of the product plus several years.12 Decommissioning does not end this obligation. It transfers it to the archive and to whoever owns the archive.

Decommissioning is a validated change

GAMP 5 treats decommissioning as a lifecycle stage that must be governed like any other validated change. The formal decommissioning plan should include data retention obligations, and data archival or migration must ensure future regulatory retrieval capability.5 Skipping this planning step is one of the most common ways to convert a rationalization win into a compliance finding.

Audit trail integrity survives the source system

Audit trails, electronic signatures, and metadata that establish who did what and when must remain intact even after the originating system is gone. This is not just a technical export of the audit table. It is a demonstrable capability to reproduce the audit trail in an investigation or inspection years later. Most centralized archiving platforms are designed precisely for this outcome; ad-hoc file exports are not.17

Replacement systems must be validated to their intended use

If a Migrate decision moves a business process from an old validated system to a new one, the new system must be validated to its intended use before the old system goes away. This includes the interfaces, the configured workflows, and any data conversion. It is not enough that the new platform is generally compliant; the specific configured use must be qualified.

The inspection question is always the same

An MHRA or FDA inspector asked about a decommissioned system will not care about the elegance of your synergy model. They will ask a straightforward question: can you produce this record from this date, and can you show me it has not been altered? If the answer to either question is no, the rationalization project has failed regardless of what it saved. Building the archive so that the answer is always yes, in under a week, is the design constraint.

Special caution for pharmacovigilance and clinical safety systems. Safety databases (Argus, ArisGlobal, in-house PV platforms) are subject to particularly stringent regulator expectations because they are used to reconstruct product safety histories decades after decommissioning. Include the qualified person for pharmacovigilance (QPPV) in every decision about a PV system, and treat those systems as the last to retire, not the first.

Conclusion

Application portfolio rationalization after a pharma or biotech merger is one of the highest-leverage integration activities available to the combined organization. Done in a disciplined six-month cadence, it removes duplicate spend, unlocks synergy commitments the board is watching, and clears the architectural clutter that would otherwise slow every subsequent transformation. Done without discipline, it becomes a stalled program with two of everything, mounting TSA extensions, and a nervous quality organization worried about what happened to the LIMS data. The difference between those two outcomes is rarely about tools or budget. It is about whether the program treats validation as first-class, whether the steering committee is prepared to make hard consolidation decisions, and whether execution is measured against the same synergy model the deal was priced on.

Sakara Digital works with pharma and biotech organizations navigating this kind of post-merger complexity, particularly where validated systems, GxP obligations, and clinical continuity intersect with commercial and operational consolidation pressure. If your organization is heading into an integration and you want an independent perspective on portfolio strategy, validation-safe decommissioning, or steering-committee design, we are happy to have that conversation.