Private equity and portfolios
Post-merger application rationalization: decide what to retire and what to archive
By SourceX Editorial · Updated
Short answer
Post-merger application rationalization decides, system by system, whether to retain, migrate, archive or retire each application the combined company inherited. Make two decisions, not one: the application's fate and the data's fate. The working rule is that no application is retired until its full history has been exported, verified and given an owner.
Key takeaways
- Separate the application decision from the data decision; retiring software does not mean discarding its records.
- Vendor data handling after cancellation, not the integration plan, usually sets the real deadline.
- An archive should be readable without the original application, in documented, neutral formats.
- Migrations typically carry open records; closed history needs its own export and verification.
- Hold a system when legal holds, retention duties or possible licensing value are unresolved, and give the hold an owner.
What does post-merger application rationalization decide?#
Post-merger application rationalization decides which of the combined company's applications survive, which are consolidated, and which are switched off. After a merger, the inventory usually shows two of everything: two CRMs, two help desks, two ERPs, two document stores, and tools nobody remembers buying.
Most playbooks score applications on cost, capability overlap, technical health and adoption. Those scores decide the application. They say little about the tickets, orders, projects and messages inside it, which is where rationalization most often destroys value it never measured.
Two decisions for every system: the application and its data#
Every system needs two decisions: what happens to the application and what happens to its data. Treating them as one is how a help desk gets cancelled with its whole history still inside it.
Writing both decisions on the same row of the application register forces the question that usually goes unasked: if this system disappears, where does each record family live afterward, in what format, and who owns that copy?
| Application decision | Possible data decisions |
|---|---|
| Retain as the surviving system | Absorb the other system's open and closed records, or absorb open records and archive closed history |
| Retire | Archive full history in neutral formats, transfer it to a successor entity, or delete it under the retention schedule |
| Keep read-only for a period | Use as a temporary archive while a proper export is built and verified |
| Hold | Freeze changes and deletion while legal holds, retention duties or value review are resolved |
- 01Your work records
- 02Personal details removed
- 03You approve the release
- 04Licensed to AI developers
The decision matrix: retain, migrate, archive or retire#
The decision matrix gives each application one of five outcomes, with the data handling written into the decision itself. Most systems land in the middle rows.
The most common failure is the third row done badly: open records move, the archive is assumed rather than checked, and the subscription lapses. Verification means comparing record counts, attachments and a sample of full records against the source while it is still live.
| Decision | Use when | Data handling | Watch-out |
|---|---|---|---|
| Retain | The system best fits the combined process | Becomes the system of record and absorbs migrated data | Confirm the license covers the merged entity and its users |
| Migrate fully | History is needed in daily work, such as warranties or service contracts | Open and closed records move with attachments and links | Importers often drop comments, field history and attachments |
| Migrate open, archive closed | Daily work needs only active records | Open records move; closed history is exported and verified | The archive becomes the only home of closed history |
| Archive and retire | The capability is duplicated and history is rarely used | Full export in neutral formats, then cancel | Cancel only after the export is verified |
| Hold | A legal hold, audit, dispute or value review is open | Freeze deletion settings and changes | A hold needs an owner and a review date |
Score each application on seven questions#
Scoring each application on the same seven questions makes the matrix repeatable across a merger and across later add-ons. Keep the answers short and factual so the register can be compared side by side.
Unknown answers are recorded as unknown, not guessed. The export and contract-clock questions are the ones most often answered optimistically, so ask the system owner to show the export and the signed agreement rather than describe them.
- Capability: which business process does it support, and does the other company run an equivalent?
- Users: who works in it daily, and who would lose access if it went away?
- Open work: which records are still active, such as open tickets, jobs, orders or projects?
- Obligations: which retention schedules, legal holds, audits or customer contracts require the history?
- Export: can the full history, including attachments, comments and change history, be exported in a documented format?
- Contract clock: when does the term end, what notice is required, and what does the vendor do with data after cancellation?
- Value: does the history hold linked operating records that could matter for analytics, AI projects or licensing?
Vendor clocks that set the real deadline#
Vendor clocks set the real rationalization deadline because each vendor handles data differently after cancellation, and some windows are short. The integration plan sets a target date; the vendor's terms decide how long the records survive after it.
These terms change and differ by plan and contract, so read the current documentation and the signed agreement for each system before setting a cancellation date. Where a window is short or an export is incomplete, keep the subscription until the archive is verified.
| System | What the vendor documents after cancellation |
|---|---|
| Salesforce | Under the Main Services Agreement, customer data is made available for export if requested within 30 days after termination; after that, Salesforce has no obligation to keep it |
| Zendesk | An automated process that permanently deletes the account's service data starts 90 days after cancellation and cannot be reversed |
| Atlassian cloud (Jira, Confluence) | After a cancelled site is deactivated, data is retained for 60 days on Free, Standard, Premium or Enterprise plans, then permanently deleted |
| QuickBooks Online | A cancelled company stays available in read-only mode for one year, during which its data can still be exported |
| HubSpot | The standard record export does not cover activities such as calls and notes, which need a separate export method |
Illustrative: two merged distributors with overlapping stacks#
Illustrative: a fictional industrial distributor merges with a similar regional company. Both run NetSuite, each has its own help desk, the acquirer uses Salesforce and the acquired company uses HubSpot, and the acquired company keeps quote files on a shared drive organized by customer.
The CIO's register gives every system two decisions. The acquirer's NetSuite account is retained and absorbs open orders, while the acquired company's closed transactions are exported and verified. Salesforce is retained; HubSpot contacts and deals migrate, and calls and notes are exported separately because the record export leaves them out. The acquired help desk is archived and retired only after ticket counts and attachments match the source.
The shared-drive quote files go into the hold row for a value review, because they link customer requests to quoted solutions and pricing decisions over many years. Every record family has a home and an owner before any cancellation notice is sent, and the hold has a named owner and review date.
Where licensing value enters the decision#
Licensing value enters at the archive step, not the application step. A retired help desk, CRM or project tool can hold exactly the linked operating records AI developers license: a request, the work done and the outcome, written by practitioners.
Flagging a system for value review should not delay its retirement. Export and verify the full history first, then let the review run on the archive. SourceX runs that review through the SourceX five-step transaction, Supply, Rights, Preparation, Approval and Delivery, starting from metadata only; the archive stays in the company's own storage, and the company keeps ownership of anything later licensed.
Frequently asked questions
Who should own the rationalization decisions?
The CIO or integration lead usually owns the register, but each data decision needs a business owner who knows what the records are for, plus input from finance and counsel on retention and contracts. Operating partners typically review the hold list and any system flagged for value.
Is a database backup the same as an archive?
Not necessarily. A backup usually needs the original application, or a compatible version, to be read. An archive should be readable without it: documented exports in formats such as CSV or JSON, attachments in their original file types, and a data dictionary that explains fields and links.
How long should a retired system stay read-only?
Long enough to verify the archive and finish any audit or close process that depends on the live system, and no longer than the contract and budget justify. Retention obligations attach to the records, not the application, so once the archive is verified they can be met from it.
Can a legal hold be met from an archive?
Often, if the archive is complete and its integrity can be shown. Counsel decides, because a hold may require metadata, audit trails or formats the export does not capture. Until that is settled, keep the system in the hold row of the matrix.
Should we wait for a licensing review before retiring a system?
No. Export and verify the full history, then retire the system on schedule. A licensing review works from metadata first and later from the archive, so it never needs the original application to stay live.
Sources
- Under the Salesforce Main Services Agreement, if the customer asks within 30 days after termination or expiration, SFDC makes Customer Data available for export or download; after that period SFDC has no obligation to maintain or provide it. Source
- Under Zendesk's Service Data Deletion Policy, an automated process that permanently deletes the account's Service Data starts 90 days after the account is canceled or terminated, and once it starts it cannot be reversed. Source
- Atlassian states that after a cancelled subscription period ends, the site stays accessible for 15 more days and is then deactivated; data is retained for 60 days for Free, Standard, Premium or Enterprise plans, then permanently deleted. Source
- Intuit support content says you can still export QuickBooks Online data while a cancelled account is within its one-year read-only period. Source
- HubSpot's export-records article says activities such as calls and notes must be exported with a separate method, not the standard record export. Source
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.