Day One. The deal has closed. The integration team walks into the acquired company’s office expecting to start the 100-day integration sprint.
Instead, payroll is broken. VPN access for the acquired company’s users is intermittent. The Teams federation between the two companies isn’t working, so teams from both sides can’t collaborate on the first deal synergy project. The marketing team’s Salesforce credentials from the acquired company are being rejected because the SSO configuration is pointing at a domain that no longer exists.
This is not a hypothetical. These are documented failure modes from real post-close integrations.
The Top 10 Day-One IT Failures (Documented)
Failure 1: The Forgotten Service Account Lockout
What happened: A service account used by the acquired company’s on-premises ERP system was set to expire on the first of the month. The integration team didn’t know about it — it wasn’t in any documentation. On Day 1, when the trust relationship between the two AD forests was being reconfigured as part of the integration plan, the service account got locked out. The ERP system stopped processing orders.
Fix: Before Day 1, run the ACQI service account discovery module. Flag every service account whose password expires within 90 days. Extend the expiration dates or rotate the passwords before Day 1.
Failure 2: The VPN Split-Tunnel Misconfiguration
What happened: The acquired company’s VPN was configured to route all traffic through the source company’s data center. After the AD forest migration, the routing tables were updated — but the VPN configuration wasn’t. Remote workers for the acquired company lost access to all internal systems simultaneously.
Fix: The ACQI network discovery module captures VPN configuration during the due diligence phase. Flag any VPN that has routing rules pointing to a single data center or specific subnet — these need to be reviewed before Day 1.
Failure 3: The Teams Federation Break
What happened: Both companies were using Teams. After the M365 tenant cutover, Teams federation between the two companies’ tenants failed. Teams calls between acquired and acquiring company employees returned “Unable to reach the organization.” This happened because the tenant domain verification hadn’t propagated, and the Teams external access policy had been set to “block all external communication” as a security lockdown during integration prep.
Fix: Teams tenant-to-tenant federation requires both tenants to have verified domains, the external access policy to allow external communication, and the meeting invitation policy to accept external meetings. The ACQI M365 discovery module captures the current external access policy state for both tenants — flag this before the integration sprint begins.
Failure 4: The Payroll System Authentication Failure
What happened: The acquired company’s payroll system (a third-party SaaS application) used Azure AD (the acquired company’s tenant) for SSO. The acquirer had migrated all users to their own Azure AD tenant. The payroll vendor required a new SSO integration setup — which required a change request that took 3 weeks to approve and implement. For 3 weeks, payroll ran with manual data entry.
Fix: Before Day 1, identify all SaaS applications that use the target’s Azure AD tenant for SSO. Build a migration plan for each one: either migrate the application to the acquirer’s tenant (preferred) or set up a new SSO integration between the application and the acquirer’s tenant. Use ACQI’s SaaS discovery to find all OAuth-connected applications in the target’s tenant.
Failure 5: The Printer Driver Cascade
What happened: Every printer at the acquired company’s office was mapped to print servers in the source domain. After the AD migration, the print servers were decommissioned before all client machines had been re-mapped. For two weeks, the acquired company’s office had limited printing capability. This sounds trivial. For a company that prints sensitive legal documents and contracts daily, it was a significant productivity hit.
Fix: Capture the full print server inventory during due diligence. Include a print server migration step in the integration checklist with a client-side verification step before decommissioning the source print servers.
Failure 6: The Shared Mailbox Permissions Gap
What happened: The acquired company’s shared mailboxes (for functions like info@, support@, and department-level inboxes) were granted access through the source company’s Azure AD tenant. After migration, the permissions broke. Messages sent to the shared inboxes bounced or disappeared.
Fix: Before the M365 cutover, export all full-access and send-as permissions on all shared mailboxes. The ACQI M365 discovery module captures these. After migration, re-apply the permissions using the exported list.
Failure 7: The Mobile Device Management Enrollment Loss
What happened: The acquired company’s mobile devices (iPhones, iPads, Android devices) were enrolled in Intune under the source company’s Azure AD tenant. After migration, the devices couldn’t receive policy updates, couldn’t be wiped remotely if lost, and were in a state of MDM limbo — enrolled in an environment that was in the process of being decommissioned.
Fix: Identify all MDM-enrolled devices in both companies during due diligence. Determine the MDM enrollment authority for each. Plan a device migration (re-enrollment) as part of the integration checklist — this needs to happen within the first week post-close before devices get out of compliance.
Failure 8: The SSL Certificate Mismatch
What happened: The acquired company’s internal web applications used SSL certificates issued by an internal CA (Active Directory Certificate Services). After the AD migration, the internal CA was decommissioned before the certificates on all internal web apps had been replaced. Internal web apps started returning certificate errors. Some browsers blocked access entirely.
Fix: ACQI’s certificate store discovery module scans all discovered servers and identifies all internal CA certificates. The internal CA should not be decommissioned until all certificates issued by it have been replaced with certificates from a recognized public CA or a retained internal CA.
Failure 9: The Conference Room AV System Dependency
What happened: The acquired company’s conference rooms had AV systems (Crestron, Extron, or similar) that were joined to the source AD domain and used service accounts for authentication. After migration, the conference room systems couldn’t authenticate to the calendaring system (Exchange Online / Google Calendar). Room bookings stopped appearing on the room screens.
Fix: Treat AV systems as discovered endpoints during due diligence. Map their authentication dependencies. For IoT and OT-type devices that use AD credentials, establish a plan for either migrating them to the target domain or creating local accounts before domain decommission.
Failure 10: The BYOD WiFi Network Failure
What happened: The acquired company’s office had a WiFi network that used WPA2-Enterprise with RADIUS authentication against the source AD domain. The IT team knew this — they had planned to change it. They planned to change it on Day 1. On Day 1, they changed it to the target domain — and immediately 200 employee personal devices (that had been connecting to the WiFi network using their AD credentials) dropped off.
Fix: Personal devices should not be connecting to corporate WiFi using AD credentials. Use a separate BYOD WiFi network for personal devices, authenticated via a different mechanism (preshared key, certificate, or cloud identity provider). The corporate WiFi should be reserved for domain-joined corporate devices.
The Pattern
Every one of these failures is preventable with adequate pre-close discovery. The integration team would have known about the service account, the VPN configuration, the MDM enrollment authority, and the SSL certificates — if they had run ACQI’s discovery modules during the due diligence phase.
The pattern in all of them: the integration team found out about a dependency on Day 1, the day they could least afford to find out about it.