Post-Merger IT Integration Checklist Template

Start when the deal is signed. Name the acquired company, the completion date and the six people, bring in what IT due diligence found, and decide what happens to each system. Until completion the two companies are separate businesses, so this phase is planning only. Every due date counts from the completion date, in working days.

• Set up the IT integration — the acquired company, the completion date (Day 1, which every due date counts from), whether the seller will keep providing any IT after completion, whether the acquirer reports to the US SEC, and the six people; later tasks are assigned from these fields
• Bring in the IT due diligence findings — the red flags and how the deal treated each one, the system inventory, licence and contract issues, change-of-control consents still open, any draft transitional services, and the integration cost estimate with its assumptions
• Agree what IT information can be shared before completion — with your lawyers: who on each side may see system details, security reports and user lists before completion, how they are shared, and what waits until Day 1
• Agree the integration approach for each system — for every system in the inventory: keep it as it is, integrate it with yours, replace it with yours, or retire it, with the owner, whether it is needed on Day 1, and a target date
• Build the IT integration plan to Day 100 — milestones, owners and dependencies for each system, the Day 1 must-haves kept apart from what can wait, and the dates lined up with the business integration plan
• Agree the integration budget, people and suppliers — the one-off costs (migration tools, migration licences, contractors, hardware), the running costs that change, who does the work on each side, and any supplier you need to engage

Decide early what must work on Day 1, then make it ready in the four weeks before completion. Keep Day 1 small: email that keeps flowing, the access the integration needs, and a support route. The personal data check and the contract consents come before the Day 1 access is set up, and the first review of any transitional services follows two weeks after completion. Larger changes wait for the security baseline and the go-ahead.

• Agree the Day 1 IT must-haves — what must work on completion day and nothing more: email between the two companies, access to shared channels, the finance and HR data the integration needs, and anything the deal documents require
• Plan email routing and addresses for Day 1 — both companies’ email keeps working on Day 1 with no mailboxes moved, how mail between them is routed and protected, whether shared calendars or a shared address book are needed, and any change to signatures
• Confirm the transitional services the seller will provide — each IT service the seller keeps running after completion, its service level, how long it runs, the charge, how it ends, the contacts on each side, and what the seller’s IT staff can still see of the company’s systems and data
• Check the personal data before any of it is shared or moves — what personal data will be shared on Day 1 or move between the companies later, the purposes it was collected for, the lawful basis for moving it, the record of the move, and whether the people it is about need to be told
• Prepare the Day 1 accounts and access — the named people who need access on Day 1, guest or cross-company accounts set up but not yet switched on, shared channels, and the finance and HR data each person may see, with the least access that does the job
• Confirm the IT contract consents needed by completion — each change-of-control or assignment consent and each notice the IT contracts need by completion, requested, received or with a plan, so no supplier can end a service on Day 1
• Agree the Day 1 support route for acquired staff — who acquired staff call on Day 1, which service desk takes each kind of request, how a ticket passes between the two desks, and the hours each desk covers
• Prepare the Day 1 IT messages for acquired staff — what changes for them on Day 1 (often nothing about how they sign in), who to call for help, and how a genuine IT request from the new owner will reach them, so a fake one is easier to spot
• Confirm Day 1 IT readiness — each Day 1 must-have reported as ready or not, with a workaround for anything that is not, and the result given to whoever runs the whole integration
• Give the agreed Day 1 access on completion day — switch on the accounts and access prepared for Day 1, only for the people approved, and record what was granted and when
• Check Day 1 email, access and support worked — mail flowing both ways, the people who needed access able to sign in, the tickets raised on Day 1 and anything that broke, with a fix and an owner for each
• Review the transitional services each month — the first review about two weeks after completion, then each month: each service against its service level, the charges, problems raised with the seller, and the exit dates still on track

Map both companies’ directories, tenants and domains, then choose how identity will work: one directory, two that trust each other, or a move between platforms. This is a plan: nothing connects until the security baseline is met and the approver says go.

• Map both directories, tenants and domains — each company’s directory (for example Active Directory or Microsoft Entra ID), its email and collaboration tenant (Microsoft 365, Google Workspace or another), the domains and who controls their DNS, the sync tools, the admin roles and the applications that sign in through each
• Choose the identity and tenant approach — whether the acquired company moves into your directory and tenant, keeps its own for now with access between the two, or moves between different platforms, with the reasons, the timing and the licences each route needs
• Plan accounts, sign-in and multi-factor for acquired staff — how each person’s account is matched or created on your side, when they start signing in with it, how multi-factor authentication is set up, and which applications move to your sign-in first
• Plan the domain and email address changes — which domains stay, move or end, the new email addresses and aliases, the DNS records that change (MX, SPF, DKIM and DMARC), and how long the old addresses keep receiving mail
• Plan admin access across both estates — named admin accounts for the integration on each side, what each may do, how long temporary access lasts, and how its use is logged and reviewed

Before anything connects, bring the acquired estate up to your security baseline or record what is still open. This phase applies whatever the approver decides later: the gaps are found and worked on before any network, directory or data is joined to yours. The personal data check was done before Day 1 in Phase 2; the baseline report confirms it still covers what the migrations will move.

• Assess the acquired estate against our security baseline — admin accounts, multi-factor authentication, patching and systems past the end of vendor support, endpoint protection, backups, logging and monitoring, remote access and the findings from due diligence, each gap with its risk, the fix and an owner
• Check for signs of compromise before anything connects — open incidents, recent alerts, accounts and mailbox rules nobody can explain, and any breach the due diligence found, with an outside assessment where the findings give a reason for one
• Remove unknown, shared and former-staff admin accounts — every admin account matched to a named person who still needs it, shared and default accounts removed or secured, and accounts of people who have left switched off
• Turn on multi-factor authentication for every account — staff, admin and service accounts that can sign in from outside, with any exception named, approved and given an end date
• Bring devices under endpoint protection and monitoring — laptops, desktops and servers running endpoint protection that reports to your security team, or to the acquired company’s own tools under an agreed watch until they move
• Fix or isolate unpatched and unsupported systems — critical updates applied, and systems past the end of vendor support replaced or kept on a separate network segment that will not connect to yours
• Confirm the acquired systems’ backups restore — what is backed up and how often, a test restore of the systems the business cannot run without, and a copy that ransomware on the network could not reach

Write down how the networks will connect, report the security baseline to the approver, and get the go-ahead. The go-ahead is the gate: nothing after it can be completed until the approver completes it. A Not yet decision hides the connection and migration work and shows a task to fix the gaps.

• Write the network connection plan — how the networks will connect (a site-to-site link, a shared wide-area network or cloud network peering), the firewall rules limited to the traffic that is needed, any overlapping IP address ranges, DNS between the two, monitoring and how to disconnect fast
• Report the security baseline result to the approver — each gap fixed, accepted with a reason, or still open, the result of the compromise check, the risk that remains if the networks connect now, and confirmation that the personal data check still covers what the migrations will move
• Approve connecting the networks and starting migrations — the approver completes this task with the decision: Go, Go with conditions, or Not yet; nothing after it can be completed until it is done
• Fix the gaps the approver named — each gap in the decision fixed or given a plan the approver accepts, the security baseline table updated, and the result reported back to the approver

Applies only when the go-ahead is Go or Go with conditions: a Not yet decision hides this phase. Connect in stages, apply any conditions the approver set, and remove temporary access once the connection is proved.

• Connect the networks in stages — the agreed link switched on with the firewall rules in the plan, one group of systems at a time, with monitoring watching the traffic and the approver’s conditions applied
• Connect the directories or set up access between tenants — the identity approach from Phase 3 put in place: accounts moved or synchronised, trust or cross-tenant access set to the agreed people and applications, and sign-in tested
• Move acquired devices onto our management — laptops and phones enrolled in your device management, your security settings applied, and the old management tool removed once each device reports in
• Check the connection and remove temporary access — traffic between the networks matches the plan, unused firewall rules closed, temporary admin accounts from Phase 3 ended on their dates, and the change closed

Applies only when the go-ahead is Go or Go with conditions: a Not yet decision hides this phase. Move mail, files and users in the order the plan sets, migrate the data from the systems being replaced, and check each one with its owner.

• Move mailboxes and the email domain — mailboxes moved in batches, the domain moved once the old tenant has released it, the DNS records changed, and mail to the old addresses still arriving
• Move files, sites and teams — shared drives, sites, OneDrive or Google Drive files and team spaces moved with their permissions, and the old copies made read-only
• Move users to the systems that replace theirs — for each system marked replace: the users set up and trained on your system, the switch date agreed with the owner, and the old system made read-only
• Migrate the data from replaced systems — the records that must move, mapped, cleaned and loaded, reconciled against the source, and signed off by the data owner; the rest archived for as long as it must be kept
• Integrate the systems that stay — for each system marked integrate: the interfaces, reports and data feeds it needs with yours, such as the finance figures for the group accounts, built and tested
• Check each migrated system with its owner — each owner confirms their system, mail or files work as expected, problems are logged and fixed, and the system register is updated

This phase goes ahead once the approver has completed the go-ahead, whatever the decision. Move, assign or end each IT contract and licence after completion, bring acquired staff onto your service desk, and, where the seller still provides IT, exit the transitional services.

• Move, assign or end each IT contract — for each software, hosting and support contract after completion, including any consent still open from Phase 2: whether it stays with the company, is assigned or novated to you, or ends, the consents and notice periods that apply, and the date each change takes effect
• Move or end the software licences — the licences each user needs on your side, licences that can transfer under the vendor’s terms, those to end at renewal, and any true-up, so nothing is paid for twice or left uncovered
• Bring the acquired systems into the SOX IT general controls — with your internal controls team and auditor: which acquired systems support financial reporting, when they come into the scope of your Sarbanes-Oxley IT general controls (access, change management and IT operations), and the gaps to close first
• Move acquired staff onto our service desk — the acquired staff’s requests taken by your service desk, their devices and systems in its records, open tickets moved across, and the old desk’s contact details replaced
• Plan and confirm the exit from each transitional service — each service replaced before its end date, the seller’s access to the company’s systems and data removed, the company’s data returned or deleted as agreed, and the seller told in writing

Retire the systems the plan replaced or retired, then review the integration at Day 100 and hand what is still open to its business-as-usual owner. The decommissioning task hides on a Not yet decision, because nothing has moved off those systems.

• Decommission the systems marked retire or replace — each system switched off once its data is moved or archived, its accounts and licences ended, its contract ended on its notice date, and its hardware wiped and disposed of
• Run the 100-day IT review — what was delivered against the plan, the system register’s final state, the cost against the budget, the security gaps still open, user problems, and lessons for the next acquisition
• Hand open items to their business-as-usual owners — each item still open, such as a system still to retire, a transitional service still running or a security gap, given a named owner, a date and the report it will appear in
• Close the IT integration — the plan, the decisions and this checklist archived, the integration budget closed, and both IT teams told the integration is now normal work