Integration Architecture in Mergers and Acquisitions: What IT Teams Actually Need to Plan For

Most merger announcements describe a combination of two companies. What they do not describe is the combination of two identity providers, two ERP instances, two HRIS tenants, two API gateways, and somewhere between dozens and thousands of point to point connections that nobody outside IT will ever see in a press release. That gap between the deal narrative and the technical reality is where most post merger integration time and budget actually goes, and it is where IT teams either build credibility with the business or lose it.

Deloitte’s research into technology due diligence found that technology integration issues account for approximately 30 percent of failed mergers, which places IT systems work on a similar level of deal risk as financial or legal due diligence, not below it. Separate industry research compiled from McKinsey, KPMG, Bain, Deloitte, and EY data shows that IT integrations fail or run into major issues 84 percent of the time, while organizations that track integration synergies from day one report a 92 percent success rate. The difference between those two numbers is not luck. It is planning, sequencing, and architecture decisions made in the first 100 days after signing.

This article lays out what a technical integration plan for an M&A event actually needs to cover: identity and access, ERP and HCM consolidation, data migration and mapping, middleware and API strategy, security and compliance carryover, and the operational cutover itself. It is written for IT teams who are either already inside a live deal or building the playbook before one lands on their desk.

Why IT Integration Planning Starts Before the Deal Closes, Not After

The single most common planning mistake is treating IT integration as a Day 1 activity that begins once the deal is signed. By the time signing happens, the technical due diligence window has usually already closed, and any system incompatibilities discovered after that point become integration costs rather than negotiated terms.

Technology due diligence exists precisely to surface these costs before they become someone else’s problem. A target company running an unsupported ERP version, a Workday tenant with years of undocumented custom integrations, or an identity provider with no API for bulk user export is not a minor footnote. It is a line item that should influence deal valuation, timeline, and the retention plan for technical staff who understand the undocumented parts of the environment.

Microsoft’s own guidance on this point is direct: in an M&A transaction, the difference between technology being a speed lever or a source of friction comes down to method, specifically designing the integration around business processes, executing by criticality waves, and securing compliance from day one rather than waiting for a clean slate that never arrives. That sequencing logic, designed around what the business actually needs running on day one rather than around an org chart, applies just as much to ERP and HCM consolidation as it does to email and file sharing.

For IT leaders building this discipline into their own organization’s playbook before a deal happens, the foundational work looks the same as building any integration roadmap: inventorying what exists, sequencing by business criticality, and resisting the urge to treat every system as equally urgent on day one.

Identity and Access: The First System That Has to Work on Day One

Of every system category involved in an M&A integration, identity is the one with zero tolerance for delay. Employees from the acquired company need to authenticate against something on their first day under the new ownership structure, whether that is single sign on into existing applications, a payroll system, or simply their email.

Microsoft’s documentation on Microsoft 365 tenant to tenant migration explicitly identifies mergers, acquisitions, divestitures, and related corporate restructuring as the primary drivers behind this category of migration, and outlines architecture approaches for moving mailboxes, SharePoint sites, OneDrive content, Teams, and the underlying Microsoft Entra ID identities between tenants. The technical detail that trips up IT teams who have not done this before is that Microsoft Entra ID identities are tenant scoped: an identity that exists in the acquired company’s tenant is not automatically recognized or trusted by the acquiring company’s tenant, which is why cross tenant access settings, B2B trust relationships, and a defined identity model have to be established before any data migration begins, not after.

The same constraint applies on the Okta side of the identity landscape. Okta’s developer documentation on planning a user migration is explicit that a migration plan needs to address four areas before execution starts: what data is being migrated, which migration method fits the user population size and security requirements, how the end user experience will be managed during the transition, and how success will be measured. Okta’s guidance also distinguishes between migration approaches by scale, noting that CSV based bulk import works for migrations under roughly 10,000 users but has real limitations around password migration, while larger populations are typically migrated through the Users API to support automation and incremental, department by department migration.

For IT teams managing this inside a live deal, the practical sequencing looks like this. First, decide on the target identity model: does the acquired company’s workforce get migrated into the parent tenant, does the parent stand up a trust relationship for a transitional coexistence period, or is a more gradual federation approach used. Second, inventory every downstream application that depends on the acquired company’s identity provider for single sign on or provisioning, because each of those is a dependency that has to be re-pointed or re-configured during cutover. Third, build the access provisioning and deprovisioning workflow before go live, not during it, because the volume of account changes during an M&A cutover is exactly the scenario where manual provisioning breaks down.

This is also where HR system integration and identity integration intersect directly. When Workday is the system of record for the acquired company’s workforce, identity and access provisioning into platforms like Azure AD, Okta, or ServiceNow needs to be rebuilt or re-pointed against the new organizational structure, role changes, and termination events that the deal itself generates.

ERP and HCM Consolidation: The Slowest, Highest Stakes Workstream

If identity is the fastest moving workstream, ERP and HCM consolidation is usually the slowest, and it is the one where shortcuts taken under deal pressure tend to surface as data integrity problems years later.

The starting question is not technical, it is structural: will the acquired company’s employees, vendors, and financial data be merged into the existing Workday or ERP tenant, or will the two systems run in parallel for a defined coexistence period before a later consolidation. Workday’s own datasheet on tenant strategy explicitly names expected M&A activity as one of the factors that determines how many implementation tenants a customer should provision and how tenant architecture should be planned, alongside subscription type and the volume of third party integrations a customer maintains. That is a direct acknowledgment from the platform vendor itself that M&A activity changes how tenant architecture decisions should be made, not an afterthought bolted onto a generic implementation guide.

In practice, most organizations choose one of three paths. The first is full tenant consolidation, where the acquired company’s workers, positions, and organizational data are migrated directly into the parent’s existing Workday tenant using a combination of the Enterprise Interface Builder for bulk data loads and Workday Studio for any orchestration logic that the standard EIB templates cannot handle. The second is a coexistence model, where the two tenants continue operating independently for a transitional period, connected by point to point integrations that synchronize specific data sets such as a unified employee directory or consolidated headcount reporting, while the harder consolidation decision is deferred. The third is a phased migration by business unit or geography, which spreads the risk and the workload but extends the timeline during which the organization is operating two systems of record simultaneously.

Each path has a different integration footprint. Full consolidation concentrates risk into a single high stakes cutover event but eliminates the ongoing cost of maintaining dual systems. Coexistence reduces the immediate cutover risk but requires building and maintaining synchronization integrations that themselves need monitoring, error handling, and eventually decommissioning once the real consolidation happens. Teams choosing the coexistence path should plan that transitional integration layer with the same rigor as a permanent one, because transitional integrations that get left running past their intended lifespan are a common source of the technical debt that shows up in the next M&A due diligence cycle.

For organizations running Infor rather than Workday, the same structural decision applies but through different tooling. Infor’s own documentation describes ION as a business process management platform that converts data into a common, standardized format so that disparate business systems, including Infor applications, third party applications, and in house developed systems, can share information without each integration being built as a custom one off. For an acquired company running a different ERP, or a different instance of the same Infor product, ION’s document flows and connection points become the mechanism for either consolidating the two environments or building the interim bridges that keep finance, inventory, and order data synchronized while a longer term consolidation plan is executed. Infor’s ION Technology Connectors administration guide specifically addresses connecting to third party applications that do not natively send or receive Infor’s standard Business Object Documents, which is precisely the scenario an acquired company’s non-Infor systems present.

The payroll and finance dimension of this consolidation deserves particular attention because it is where data errors translate directly into compliance exposure and employee trust. HR and payroll integration failure points that already exist inside a single company’s environment do not disappear during an acquisition. They compound, because the acquired company’s payroll feed, tax reconciliation logic, and compensation data structures now need to map onto a different system’s expectations, often under a compressed timeline driven by the next payroll run date rather than by what would be a reasonable testing window.

Data Migration, Mapping, and the Canonical Model Problem

Every M&A integration eventually runs into the same structural problem: two companies almost never define the same business entity the same way. One company’s customer record has a different set of required fields than the other’s. One company’s product SKU format does not match the other’s. One company’s chart of accounts uses a different hierarchy. None of this is exotic, but all of it has to be resolved before data can move reliably between systems, and resolving it after a botched migration is far more expensive than resolving it before one.

This is the exact problem that a canonical data model is designed to solve. Rather than building a direct, custom mapping between every pair of systems being merged, which scales quadratically as more systems get added to the integration landscape, a canonical model defines a single, standardized representation of each core business entity, such as employee, customer, invoice, or order, that every system maps to and from. Adding a new system to the integration landscape, which is exactly what an acquisition does, then requires one mapping to the canonical model instead of a new point to point mapping to every existing system.

Sama’s any to any integration architecture approach uses this canonical, semantic layer specifically because M&A scenarios are one of the clearest cases where the alternative, point to point mapping, becomes unmanageable. When a third, fourth, or fifth company gets absorbed into the same group over time, which is common in private equity backed roll up strategies, an integration landscape built on point to point mappings has to be substantially rebuilt with each new acquisition, while a canonical model absorbs new systems incrementally.

The practical data migration work itself follows a consistent pattern regardless of which systems are involved. Source data needs to be profiled before migration to identify quality issues, duplicate records, and missing required fields, because migrating bad data into a new system at scale is significantly harder to clean up after the fact than before. Field level mapping needs to be documented explicitly, not just executed, because that documentation is what makes the next system change or the next acquisition faster to integrate. And the migration needs a validation step that compares record counts, key field values, and referential integrity between source and target before the source system is decommissioned or before the cutover is declared complete.

Teams that have not built this discipline before tend to underestimate how much of the actual project timeline data mapping and validation consume relative to the integration build itself. A well structured integration requirements document that defines field mappings, data ownership, and validation criteria before development starts is what prevents that underestimation from becoming a missed go live date.

Middleware and API Strategy: Choosing the Integration Layer Before the Pressure Hits

Under deal pressure, the fastest looking option for connecting two systems is almost always a direct, point to point integration: a script or a simple API call that moves data from system A to system B with no intermediate layer. This is also the option that creates the most technical debt, because every point to point integration built during a rushed M&A timeline becomes a maintenance liability that someone has to support, document, and eventually replace.

MuleSoft’s own documentation on API led connectivity describes the alternative as a layered architecture: system APIs that connect directly to backend systems like databases or core applications and insulate their complexity, process APIs that orchestrate and combine those system level connections into reusable business capabilities, and experience APIs that format the resulting data for a specific consumer such as a mobile app, a web portal, or a partner facing channel. The architectural benefit that matters most in an M&A context is reuse: a system API built to expose the acquired company’s customer data once can be consumed by multiple process APIs serving different downstream needs, rather than each new requirement triggering a brand new point to point build.

This matters in M&A specifically because acquisitions rarely happen once. A company that has been through one acquisition is statistically more likely to go through another, whether as an acquirer continuing a roll up strategy or as part of a larger group that itself gets acquired or divested later. An integration architecture built around reusable system and process layers absorbs the next acquisition far more efficiently than a landscape of one off point to point scripts, because the system layer connections to existing platforms like Workday, the ERP, and the CRM already exist and only need a new process layer built to handle the specific orchestration the new deal requires.

For organizations evaluating whether to build this middleware layer internally or bring in outside expertise during a compressed M&A timeline, the calculus is usually about speed and risk tolerance rather than capability. Integration consulting engagements built around Workday, Infor ION, and MuleSoft’s Anypoint Platform exist specifically to compress the timeline between deal signing and a working, tested integration layer, without the organization having to build that specialized expertise internally for what is, for most companies, an infrequent event.

Organizations bringing in outside help during this kind of compressed timeline should also be deliberate about how that vendor relationship is structured, because an M&A integration is exactly the scenario where architecture decisions made under deadline pressure, by a vendor team that will not be around for the next phase, tend to create the most long term lock in and the least documentation.

Security, Compliance, and Audit Continuity During the Transition

An acquisition does not pause an organization’s compliance obligations, and in many cases it expands them, because the combined entity now needs to demonstrate that data flowing between two previously separate environments meets the same standards that applied to each environment independently.

Microsoft’s documentation on cross tenant subscription transfers highlights a specific technical risk that applies broadly across M&A identity scenarios: identities are tenant scoped, so during a cross tenant transfer, identities trusted by the source tenant are not automatically trusted by the target tenant, and any system, including databases or applications that authenticate using those identities, can experience an administrative lockout if this is not planned for explicitly before the transfer happens. This is not a hypothetical edge case. It is a documented failure mode that Microsoft’s own engineering teams have written guidance to prevent.

On the audit and access control side, the acquired company’s existing role based access control structure, audit logging configuration, and any compliance certifications it held, such as SOC 2, HIPAA, or GDPR relevant controls, need to be evaluated against the parent company’s standards rather than assumed to be equivalent. Where the acquired company processes personal data or protected health information through its integrations, the compliance patterns that apply to handling PII under GDPR and HIPAA do not get a grace period during a merger. A data processing agreement or business associate agreement that covered the acquired company’s vendor relationships needs to be reviewed against the parent company’s contractual framework, and any gap between the two needs to be closed before data starts flowing through new integration pathways, not after an audit finds the gap.

This is also the point in the process where access provisioning discipline matters most, because the volume of role changes, terminations, and new account creation during an M&A transition is exactly the scenario where overly broad access grants get created as a shortcut and then never get cleaned up. Scoping integration service accounts and OAuth token grants to the minimum access required for each specific integration, rather than reusing a broad administrative credential across multiple new connections built during the transition, is the difference between an integration layer that can pass a post merger security audit and one that cannot.

Sequencing the Cutover: Waves, Not a Big Bang

The single highest leverage decision an IT team makes in an M&A integration is how to sequence the cutover. Microsoft’s own framing of this, drawn from its tenant to tenant migration guidance, is to migrate in criticality waves rather than by organizational chart, meaning the systems and user groups that matter most to maintaining business continuity move first and get the most rehearsal, while lower risk groups follow once the process has been proven.

A representative pilot wave, run against a non critical business unit or a smaller subset of users, surfaces integration defects, data quality issues, and process gaps while the blast radius of a failure is still small. Each subsequent wave should incorporate what was learned from the previous one rather than repeating the same mistakes at larger scale. And every wave needs an explicit go or no go decision point: if a critical item fails and would impact customers or production operations, the wave gets postponed or redesigned rather than pushed through on schedule, because the cost of postponing one wave is almost always lower than the cost of an outage propagating through a critical business process.

This wave based approach applies as directly to ERP and HCM cutovers as it does to Microsoft 365 tenant migrations. A phased rollout by business unit or geography for a Workday or Infor consolidation follows exactly the same logic: prove the migration pattern on a smaller, lower risk population, fix what breaks, and only then scale the approach to the units where a failure would be most damaging.

Once the cutover waves are complete, the integration landscape does not become static. New connectors get added as the combined organization standardizes on shared tools, existing integrations need ongoing monitoring as transaction volumes shift, and the transitional bridges built for coexistence eventually need to be decommissioned on a deliberate timeline rather than being left running indefinitely. Managed integration services that provide ongoing monitoring, break fix support, and governance over error handling and logging are what keeps a post merger integration landscape from quietly accumulating the same kind of undocumented technical debt that made the acquired company’s environment difficult to assess during due diligence in the first place.

Frequently Asked Questions

How long does a typical IT integration take after an acquisition closes

There is no single standard timeline because it depends heavily on system complexity and the consolidation path chosen. A coexistence model with point to point synchronization between two systems can be stood up in a matter of weeks. A full ERP or HCM tenant consolidation, particularly one involving global multi region operations with localized compliance requirements, more commonly takes several months, and complex enterprise wide rollouts can extend to four to six months or longer. The timeline is driven less by the technology itself and more by data quality, the number of dependent downstream systems, and how much testing and rehearsal each cutover wave is given before go live.

Should we migrate the acquired company into our existing systems or keep them separate at first

This depends on deal structure and integration goals. If the strategic intent is full operational integration, migrating into the existing tenant or ERP instance early reduces the long term cost of maintaining two systems and two sets of integrations. If the acquired entity will operate with some independence, a coexistence period with targeted synchronization integrations, such as a unified directory or consolidated reporting feed, is often the lower risk path, provided that period has a defined end date and is not left open ended.

What is the biggest technical risk in identity migration during an acquisition

Treating identities as portable between systems when they are not. Identities created in one identity provider tenant, whether Microsoft Entra ID, Okta, or another platform, are scoped to that tenant and are not automatically recognized by another tenant. Any downstream system or database that authenticates against those identities can lose access entirely if the trust relationship and access provisioning are not established before the migration, not after.

Why do point to point integrations built quickly during a merger become a problem later

Because they solve the immediate connection need without building reusable infrastructure. Each point to point integration built under deal pressure typically lacks documentation, has no defined owner once the project team disbands, and has to be individually maintained, updated, and eventually replaced. When the same organization goes through a second acquisition, none of that point to point work is reusable, while a layered, API led architecture with reusable system and process level connections absorbs the next integration far more efficiently.

Does our existing compliance posture automatically extend to the acquired company’s data

No. Compliance obligations such as data processing agreements, business associate agreements, and access control standards need to be explicitly reviewed and extended to cover the acquired company’s systems, data flows, and vendor relationships. Assuming equivalence between the two organizations’ compliance postures without verification is one of the more common gaps that surfaces during a post merger audit.

What should happen to the acquired company’s legacy integrations that nobody fully understands

They need to be inventoried and assessed before being either migrated, replaced, or decommissioned, rather than left running unmonitored. Undocumented legacy integrations are a frequent source of both data quality problems and security exposure, and an acquisition is the natural point to catalog what exists, determine what is still business critical, and retire what is not, rather than carrying that technical debt forward indefinitely.