Most post-merger IT integration timelines are optimistic by six months and underfunded by roughly 30 percent — not because the teams are incompetent, but because the planning checklists in wide circulation miss the same dozen items every time. This piece is built from notes, post-mortems, and sprint retrospectives across five completed merger engagements handled by the TechGrid NexStream consulting team between 2021 and 2024, covering deals ranging from a 200-person SaaS acquisition to a 4,000-seat cross-border manufacturing merger. The patterns are striking in their consistency. The same steps get deprioritized, the same fires ignite around month four, and the same executives say, with genuine surprise, "nobody told us this would happen." Consider this a corrective document — not a glossy framework, but a practitioner's annotated list of what actually gets skipped and why it matters.
Step 1: Auditing the shadow IT before Day One ¶
In every engagement, the acquired company had between 40 and 120 SaaS subscriptions that did not appear in any asset register. These are tools that department heads bought on a credit card — Notion workspaces, Airtable bases, niche analytics tools, a homegrown Zapier automation touching three critical workflows. The acquiring IT team almost never discovers these until something breaks during the consolidation. In one manufacturing merger, a logistics team was running a custom Google Apps Script that auto-generated purchase orders. It silently stopped working three weeks post-close when Google Workspace tenant migration cut its OAuth tokens. Shadow IT audit should happen in the first two weeks of due diligence access, not during cutover.
Step 2: Mapping data residency before touching a single server ¶
Cross-border deals in particular fall apart here. In a 2023 engagement involving a UK-based acquirer and a German target, the integration team began migrating file servers in week six before anyone had formally documented which data sets were subject to GDPR Article 46 transfer restrictions. The migration had to be paused for 11 weeks while legal counsel and the DPO produced a Transfer Impact Assessment. Data residency mapping — knowing exactly which data lives where, which regulations govern it, and which jurisdictions it may or may not traverse — must be completed before any infrastructure work begins. This is not a legal formality; it is a load-bearing wall.
Step 3: Establishing a single identity authority on day one ¶
Identity is the plumbing of any merged IT environment. The question of which Active Directory or IdP (Okta, Azure AD, Google Workspace) becomes the authoritative source for provisioning is almost always deferred because it feels like a technical detail. It is not. In two of the five engagements, teams ran parallel identity stores for more than five months post-close. The result was a support ticket queue that grew faster than it was resolved, access provisioning taking three to seven days instead of hours, and at least one incident in each case where a departed employee from the acquired company retained system access for over 60 days. Decide on the identity authority before Day One. Document the provisioning workflow. Enforce it from the first new-starter onboarding.
Step 4: Running a software license reconciliation that includes true-ups ¶
Acquiring a company does not automatically transfer its software licenses. Microsoft, Salesforce, ServiceNow, and most major enterprise vendors treat a change of control as a potential license event, and their contracts frequently require notification within 30 to 60 days. In one SaaS-to-SaaS acquisition, the acquiring company assumed it could simply absorb the target's Salesforce org under its existing Enterprise Agreement. The Salesforce true-up conversation six months later revealed a 340-seat discrepancy and a retroactive invoice of roughly $180,000. License reconciliation — including a review of change-of-control clauses in every tier-one contract — belongs on the checklist in the first 30 days, not at the first renewal cycle.
Step 5: Treating the network integration as a security project, not a connectivity project ¶
The typical framing of network integration is: how do we get the two offices talking to each other? The more important framing is: what is the blast radius if an attacker compromises the acquired company's environment after we connect it to ours? In three of the five engagements, the acquired company had materially weaker endpoint protection, no MFA enforcement, and at least one externally exposed RDP port. Connecting that environment directly to the acquirer's network without a staged, segmented approach is a risk that rarely gets priced into the integration timeline. A DMZ or microsegmentation approach, with progressive trust expansion tied to security control milestones, consistently delays the network cutover by four to eight weeks but prevents incidents that would delay everything else by far longer.
Step 6: Interviewing the IT staff who are likely to leave ¶
In every acquisition, there are three to six IT staff members at the target company who hold tribal knowledge that exists nowhere else. They know why the ERP customization was built that way. They know which cron job runs at 2 a.m. on the first of the month and what happens if it fails. They know the vendor contact who actually picks up the phone. These people are also, statistically, the most likely to leave within 90 days of close — either because they feel sidelined, because their role is duplicated, or because they received retention packages that vest at 90 days and then walk out the door. Structured knowledge-capture interviews with key IT staff should begin within two weeks of close. Record them. Document the undocumented. Treat institutional memory as an integration asset.
Step 7: Building a communications protocol for IT-impacting changes ¶
This one sounds bureaucratic and gets cut from the project plan early. The consequence is that end users at the acquired company experience a series of disorienting changes — a new VPN client, a renamed email domain, a forced password reset, a different printer driver — with little to no advance notice, delivered inconsistently by different project workstreams. Trust erodes fast. In a 2022 retail acquisition, the combined IT team tracked a 47 percent increase in IT helpdesk tickets in the six weeks following cutover, with a significant share categorized as complaints rather than technical issues. A simple communications calendar — owned by a named person, with mandatory two-week notice for any user-facing change — costs almost nothing and demonstrably reduces ticket volume and employee friction during the integration window.
Step 8 through 12: The five steps that disappear in the final sprint ¶
When timelines compress — and they always compress — five items reliably get dropped from the integration backlog. First, backup and recovery validation for the newly merged environment: teams assume existing backup jobs cover new infrastructure, and they frequently do not. Second, decommissioning planning for retired systems: the old environment lingers, consuming licensing and support costs for months or years because no one owns the shutdown checklist. Third, a formal vendor renegotiation pass: consolidation creates buying leverage that is almost never used because procurement and IT are not coordinating. Fourth, a post-integration security audit by a party not involved in the integration itself: the team that built it cannot objectively assess it. Fifth, and most consistently skipped of all, a 90-day retrospective that captures what actually happened versus what was planned — the document that would make the next acquisition go better. Four of the five completed engagements reviewed here produced no such retrospective.
The checklist most teams skip is not secret or difficult to find. It is simply the set of items that feel like they can wait until the core migration is stable — and by the time the core migration is stable, the window to do them cleanly has passed. The patterns across these five engagements are consistent enough to treat as close to predictive: skip step three, get an identity incident by month five; skip step five, get a security event by month eight. The good news is that none of these steps are technically hard. They are coordination problems, and coordination problems are solvable if someone is assigned to own them before the pressure of Day One makes everything feel urgent.