IT Integration in Post-Merger Integration

Executive summary

Post-merger IT integration is the work of deciding which systems stay, which merge and which retire, then moving data and users in an order that does not interrupt the close, payroll, billing or customer service. It matters financially because many synergies in the investment case, such as shared finance, one ERP or fewer licenses, depend on a technology change before any saving appears.

The central discipline is a per-application decision. For each system, choose absorb (move the acquired business onto the acquirer's system), coexist (keep both and connect them), replace (move both to a new system) or retire (switch it off). The choice sets the one-time cost, the run-rate saving, the risk and the date. Without that decision, IT integration becomes a stream of requests handled in the order they arrive.

The first move is to build a system inventory with owner, cost, users, contract end date and data it holds. This guide gives the inventory, a decision method, a sequencing approach, a worked payback example and the mistakes that delay savings. It is a management guide, not security, legal or vendor advice; your contracts and your security team decide what is permitted.

When to use this

Use this guide when:

• You have closed an acquisition and the two companies run overlapping systems for finance, CRM, HR, billing or reporting.
• The synergy case includes IT or finance consolidation and no application-level plan exists.
• The TSA lists IT services and you need to know when each can end. See TSA management.
• Leadership wants one view of customers, revenue or inventory and the data is in two places.
• You are planning an ERP move and need to sequence it with the rest of the integration.

Do not start with a full platform migration if you have not yet confirmed what each system does and who uses it. If the deal is a small add-on that will remain a standalone business unit, coexist with reporting integration may be the right answer. The decision is about the thesis, not about tidiness.

Diagnostic questions

1. Is there a complete application inventory for the acquired company, with owner, vendor, annual cost, users and contract end date?
2. Which systems hold financial data, customer payments, personal data of employees or customers, or regulated data?
3. Which contracts have change-of-control, assignment or consent terms, and who is reviewing them with counsel?
4. What does each application do that the acquirer's equivalent cannot, and who confirmed that?
5. How many interfaces connect each application to others, and are they documented?
6. What manual workarounds, spreadsheets and shadow systems carry essential processes?
7. What is the quality of master data (customers, items, vendors, chart of accounts), and who owns it?
8. What are the identity and access arrangements, and how will users get access to what they need on Day 1?
9. What does the security assessment say about the acquired environment, and what must be fixed before connecting networks?
10. Which IT staff and vendors hold knowledge that exists nowhere else, and are they covered by retention plans?
11. Which synergy initiatives in the register depend on an IT change, and by what date?
12. What is the budget for one-time IT integration costs, and who approves changes?

Questions 3 and 9 can stop the plan: a consent requirement or a security finding changes the sequence. Raise both with counsel and your security lead in the first two weeks.

The framework: inventory, decide, sequence, migrate

The four options differ in what they cost and what they release:

Coexist is a legitimate answer, but it should be a decision with an end date or a stated reason, not a default.

Step-by-step process

1. Build the application register. Include system name, owner, vendor, annual cost, contract term, users, interfaces, data held and business process supported. Owner: acquirer IT lead with the target's IT lead. Output: register. Time-box: first two weeks.
2. Run a security and access baseline. Assess identity, endpoints, network and third-party access before connecting environments. Owner: security lead. Output: findings list and conditions for connection.
3. Review contracts for consent and exit terms. Identify change-of-control, assignment, minimum term and termination terms. Owner: counsel and procurement. Output: contract table with dates.
4. Plan Day 1 minimums. Email, directory access, intranet, approved payments and payroll continuity, and a clear help channel. Owner: IT lead. Output: Day 1 IT checklist, linked to the Day 1 readiness checklist.
5. Decide per application. Compare absorb, coexist, replace and retire using one-time cost, run-rate saving, risk and the date the saving is needed by the synergy plan. Owner: IT lead with the functional owner. Output: decision table.
6. Estimate the cost and the payback. Build the one-time cost bottom-up from vendor quotes and internal time. Owner: IT lead with finance. Output: cost and payback by application.
7. Clean the data before moving it. Deduplicate customers and vendors, align charts of accounts, and agree on the master-data owner. Owner: functional data owners. Output: cleaned extracts with reconciliation.
8. Sequence the cutovers. Avoid period-end and peak operational weeks, and avoid moving finance, payroll and billing in the same window. Owner: IMO and IT lead. Output: calendar.
9. Test with real transactions. Run parallel cycles for finance and payroll, reconcile totals and have business users sign off. Owner: application owner. Output: reconciliation and sign-off.
10. Cut over with rollback. Define the point of no return, who decides, and how to revert. Owner: application owner. Output: cutover plan with decision criteria.
11. Retire and archive. Switch off systems, terminate contracts in the form required, archive data in an accessible form for audit and legal needs. Owner: IT lead with counsel. Output: contracts ended and archive confirmed.
12. Report savings against the baseline. Link each retired contract to the P&L line. Owner: controller. Output: realized saving tracked in the synergy model.

Templates

Application register (copy into a spreadsheet)

Decision record per application

Cutover checklist

Metrics and KPIs

Setting targets without invented benchmarks. Do not apply a typical IT integration timeline or cost percentage from a general source. Set targets from your own anchors: the contract end dates and notice periods that set when each saving can start, vendor quotes for implementation, and the longest similar migration your team has completed. For payback, use the one-time cost and saving of each decision, and require the sponsor to approve any application where payback is longer than the period the synergy plan assumes.

Common mistakes

1. Choosing the platform before the process. Symptom: a migration plan with no one confirming that the target system supports the acquired business's workflow. Confirm functional fit first.
2. Ignoring contract notice periods. Symptom: you pay another year for a system you have replaced. Calendar every notice date.
3. Moving dirty data. Symptom: duplicate customers and mismatched accounts in the new system. Clean and reconcile before cutover.
4. Cutting over finance, payroll and billing together. Symptom: a failure affects several external cycles at once. Sequence them.
5. Forgetting shadow IT. Symptom: a critical spreadsheet or tool is discovered after the source system is off. Interview users.
6. Under-protecting key technical people. Symptom: the person who knows the interfaces leaves mid-project. Include them in the retention plan.
7. Connecting networks before a security review. Symptom: an unmanaged environment gains access to the acquirer's systems.
8. No link between retirement and the P&L. Symptom: the saving is claimed and never seen. Tie each contract to a GL line.

Worked example (Illustrative)

The numbers below are made up to show the method. They are not benchmarks.

An acquirer decides to absorb six overlapping applications of the acquired company. The annual cost of each and the one-time cost to migrate it:

Payback for the program is $467,000 ÷ $700,000 × 12 = 8.0 months, measured from the point when every contract has ended. That is a simplification: the savings start as each contract ends, not all at once.

By application, the ERP is 60% of the saving ($420,000 of $700,000) and 66% of the one-time cost ($310,000 of $467,000). Its payback is $310,000 ÷ $420,000 × 12 = 8.9 months, and it also carries the most risk. The other five together cost $157,000 and save $280,000, a payback of 6.7 months.

What the operator does with this: the five small applications go first because they pay back fast and fail safely. The ERP moves in a separate window away from quarter-end, with a parallel close and reconciliation before the old contract is terminated. The notice date for the ERP contract determines the earliest date the saving can start, so the IMO checks it before choosing the cutover date. Realized savings are reported only when the contract has ended and the P&L shows the lower cost.

AI prompt assistance

Use AI to organize and draft. Do not paste confidential data into tools that your policies do not allow, and do not use AI output as a security assessment.

1. Build an application register from contract summaries.

I will paste summaries of IT contracts. For each, extract vendor, product, annual cost, term end date, notice period and any change-of-control or assignment clause. Return a table. Flag any field that is missing.

Check: verify five rows against the source contracts, and have counsel review any flagged consent clause.

2. Draft a decision record.

Using this application description and the acquirer's equivalent system (paste both), draft a decision record comparing absorb, coexist, replace and retire. List the assumptions you made and the questions a business user should answer.

Check: the functional owner confirms every functional claim before the record is used.

3. Check data mapping.

Here are two chart of accounts extracts (pasted). Propose a mapping from the acquired accounts to the acquirer's accounts and list any accounts with no clear match.

Check: the controller reviews every mapping and reconciles trial balance totals before and after.

Implementation guide

Governance: the sponsor approves the one-time budget, the IT lead owns the plan, each application has a business owner who signs off functional fit, and the controller owns measurement of savings. Report progress in the IMO's weekly cadence; see IMO setup for the structure.

What to expect: the first month is discovery, and the inventory is always incomplete. The largest delays come from contract terms and data quality, not from technology. Phase the work so that early retirements fund confidence for the harder moves.

Downloadable assets

The application register, decision record and cutover checklist above are designed to be copied into a spreadsheet.

Related resources

• Post-merger integration hub: all integration guides in one place.
• PMI playbook: Day 1 to Day 365: where IT sits in the full plan.
• Day 1 readiness checklist: the IT minimums for close.
• Transition services agreement management: exiting seller-provided IT services.
• Synergy tracking: from model to realized EBITDA: proving the savings.

Frequently asked questions

What is IT integration in a merger?

IT integration is the work of combining or aligning the systems of two companies after a deal: deciding which applications stay, merge or retire, then migrating data and users in a safe order. Its financial purpose is to unlock synergies that depend on shared systems, and its operational purpose is to avoid disrupting the close, payroll or customers.

Should you consolidate ERP systems after an acquisition?

Consolidate the ERP when the acquirer's system fits the acquired business and the synergy plan depends on shared finance, reporting or purchasing. Keep systems separate when the business will remain standalone or the timing is wrong. Decide per application, with one-time cost, saving, risk and contract dates written down.

What should be done on Day 1 for IT?

On Day 1, make sure people can work: email, directory and system access, payroll and payments continuity, and a clear support channel. Do not attempt a large migration on Day 1. Keep the acquired systems running, assess security before connecting networks, and put the heavier moves in the sequenced plan.

How long does post-merger IT integration take?

Duration depends on the number of applications, their contracts, data quality and the replacement path, so it cannot be read from a general number. Build the timeline from your own contract notice dates, vendor quotes and the longest comparable migration your team has completed, and sequence moves to avoid period-end.

How do you measure IT integration savings?

Measure savings by tying each retired application or contract to a P&L line and a baseline, and count them as realized only when the contract has ended and the cost has dropped in the ledger. Report one-time cost against budget and payback by application. Announced savings that are not visible in the P&L are still forecasts.

How this works in a System of Performance

IT integration produces savings only when the contract ends and the cost line falls, and those facts sit in different places: the application register, the vendor contract and the ledger. A Performis routine can take on a recurring job like this, with the scope and fit agreed with you: it works from the records your team supplies, prepares the work for your named reviewer, and keeps each approval on record. If you want to see which systems in your own stack overlap and what they cost, bring it to us as a launch partner.