The M&A Data Migration Playbook: A 90-Day IT Integration Guide

The deal closed. Your CIO now has 90 days to merge two IT environments before the Transition Services Agreement (TSA) expires — and every day of delay erodes the value the board paid for.

Most M&A integration playbooks are written by strategy consultants who focus on org charts and skip the data layer entirely. This guide covers the operational reality: what has to happen at the data layer in those 90 days to merge identity and email, consolidate CRM and finance systems, and migrate HRIS and ITSM platforms without causing a business blackout.

Why the First 90 Days Dictate Deal Value

Post-merger integration is not a follow-up workstream. It is the deal. Slow IT integration erodes deal value through redundant licensing, opaque reporting, talent attrition, and compounding integration debt. The clock starts at close, not when your IT team finds bandwidth.

The hard constraint is the Transition Services Agreement (TSA) — the contract that grants the acquiring company continued access to the seller's IT systems, payroll, and shared services for a defined period post-close. TSAs typically run 60–180 days. Miss the deadline, and you lose access to users, data, and infrastructure with no default extension. Every system you haven't migrated off the seller's tenant becomes inaccessible overnight. EPC Group's current carve-out guidance frames Microsoft 365 separations around these same 60–180 day TSA windows. (epcgroup.net)

The 90-day framework below is designed for high-touch integrations — full system consolidation across identity, collaboration, CRM, finance, HRIS, and ITSM. Smaller tuck-in acquisitions may compress this. Cross-border deals with GDPR or multi-entity complexity will stretch it. Calibrate accordingly.

Day 1 to Week 2: Identity, Email, and Tenant Migration

The first thing that breaks in an acquisition is communication. Acquired employees can't find new colleagues in the Global Address List. Calendar free/busy lookups fail. Email between the two organizations bounces or lands in spam. On Day 1, your priority is identity coexistence — making both tenants behave as one from the user's perspective, even though the data hasn't moved yet.

Microsoft 365 tenant-to-tenant migration

Microsoft's native cross-tenant mailbox migration moves mailbox content, but not your whole collaboration layer. Mailboxes on hold are blocked, only user-visible mailbox content moves, Teams chat folder content does not transfer cross-tenant, and signatures must be recreated. (learn.microsoft.com)

Native cross-tenant OneDrive migration is a one-time move — no incremental or delta passes are supported. Target OneDrive sites must not already exist. Legal holds block moves. Accounts over 5 TB, over 1 million items, or with paths over 400 characters will fail. (learn.microsoft.com)

If users keep working in the source OneDrive after their migration batch runs, that new content does not follow them. Plan accordingly.

Third-party tools like BitTitan MigrationWiz and ShareGate fill gaps but have their own constraints:

• Azure Information Protection (AIP): Messages encrypted with AIP will migrate via MigrationWiz but will not be viewable at the destination because the destination tenant lacks the original decryption keys. You must run PowerShell scripts to decrypt these messages at the source before migration, then re-apply the destination's AIP policies post-cutover. (help.bittitan.com)
• EWS access changes: As of April 2025, Exchange Online requires both organization-level and user-level EWSEnabled settings to be True. If either is False, EWS access is blocked — and MigrationWiz migrations will fail silently. Migration accounts require precise Application Impersonation roles, which are heavily restricted in modern Exchange Online environments.
• ShareGate + Teams private channels: ShareGate cannot migrate managed metadata columns within Microsoft Teams private channels. Private channels create separate site collections, and managed metadata term stores don't map across them. You must extract the taxonomy via the Microsoft Graph API, recreate the term store in the destination tenant, and map the metadata programmatically. (help.sharegate.com)
• Sensitivity labels: Microsoft's native tools require sensitivity labels to be removed before migration, since label policies don't transfer between tenants.
• Legal holds: Mailboxes under any type of eDiscovery or compliance hold cannot be moved via Microsoft's native tools unless holds are released first.
• MigrationWiz is not a sync tool. BitTitan states this explicitly. Calendar meeting links usually still point to the source environment, and Teams private chat history is no longer supported in mailbox migrations. (help.bittitan.com)

Microsoft throttles cross-tenant mailbox migration to approximately 500 mailboxes per batch. A 10,000-user organization should plan for 20+ migration batches running over several weeks. Factor this into your TSA timeline from Day 1.

Rollback posture for identity and email: Before each migration batch, export a full backup of the source mailbox and OneDrive state. If a batch fails or corrupts data, you can re-provision the user in the source tenant and restore from backup. Since Microsoft's native cross-tenant OneDrive migration is a one-time move with no delta passes, a failed OneDrive batch means re-provisioning the source site and re-running the move from scratch. Define a per-batch acceptance threshold up front — for example, if more than a defined percentage of items fail validation in a batch, halt the wave, investigate, and re-run rather than proceeding to the next batch.

Google Workspace merge limitations

If one or both sides of the deal run Google Workspace:

• Domain Transfer moves eligible secondary domains into the destination environment, but the primary domain cannot transfer until it is swapped out. Google explicitly states that Domain Transfer does not merge or deduplicate user accounts. (support.google.com)
• Google's built-in data migration service works best for roughly 100 users or fewer. For 1,000+ user moves, Google points you to Google Workspace Migrate, which supports a delta pass before go-live. The data migration service requires IMAP enabled and 2-step verification turned off in the source account. (support.google.com)

If one side of the deal is Google and the other is Microsoft, this is not just a mail project. It is an identity translation and application access project with mail as one workload.

What to execute in Week 1

1. Establish cross-tenant mail routing. Configure send/receive connectors in both Exchange Online tenants so email flows correctly between migrated and non-migrated users. Keep MX records pointing to the source tenant until cutover.
2. Build a unified Global Address List. Surface acquired users as Mail Contacts in the acquiring tenant (and vice versa) using PowerShell. Don't forget distribution lists, shared mailboxes, and room resources.
3. Enable free/busy coexistence. Set up Organization Relationships in both tenants so calendar availability works across the boundary.
4. Audit AIP-encrypted content. Identify and decrypt AIP-protected messages before scheduling mailbox migration batches.
5. Run a pilot batch. Migrate 20–50 non-critical mailboxes. Validate that Outlook profiles reconfigure correctly, calendar items land, and contacts resolve.
6. Confirm the TSA end date and negotiate extension triggers if possible.
7. Map security and access control policies. Export conditional access policies, RBAC role assignments, and permission models from both tenants. Identify conflicts early — profile and permission set differences between source and target environments are a major failure point during user migration, and they cannot be auto-merged.

Day 1 output is not "everything merged." It is "everyone can work." That means mail routing, aliases, SSO, shared mailbox access, admin break-glass accounts, and a published exception list for the items that will not survive a straight tenant move.

Week 1–2: Data Inventory Across Both Organizations

While identity coexistence is being configured, run a parallel workstream: a full data inventory of every system in both organizations. You cannot build a migration plan without knowing what exists. Grant Thornton's M&A case work emphasizes defining the minimum viable scope for TSA exit and building a full inventory of systems, data requests, and contracts first. That is the right order. (grantthornton.com)

Build a system-of-record map that covers:

Count volume, not just systems. Microsoft's OneDrive cross-tenant move has hard limits on item count, size, and path length. If no one knows the largest mailbox, the noisiest shared drive, or the CRM object with the highest association count, your timeline is guesswork.

The inventory phase is also when you should catalog existing integration middleware — iPaaS platforms like Workato, MuleSoft, or Boomi that connect systems on either side. These platforms often serve as the glue between applications during the transition period, and they can be repurposed to bridge source and target systems temporarily. But they also break: if a source system is decommissioned or its API endpoints change during migration, every integration that touches it fails. Document every active integration flow and flag the ones that depend on systems scheduled for migration or decommission.

The output of this phase is a migration priority matrix: what gets consolidated first (identity, email), what runs in parallel (CRM, finance), and what gets deferred (knowledge bases, legacy archives). Not everything needs to merge. Some systems can run in parallel temporarily — but you need to make that decision deliberately, not by default.

Week 3 to Week 6: CRM Consolidation and the Deduplication Problem

CRM consolidation is where most M&A integrations stall. Two organizations almost certainly share customers, prospects, and partners — stored in different formats, with different custom fields, on different CRM platforms. A CRM is a relational database wrapped in a UI. If you flatten that database into CSV exports, you will orphan activity logs, break pipeline stages, and permanently lose the historical context your sales team needs.

Salesforce org merges: governor limits and silent failures

If both companies run Salesforce, you're merging two orgs. Salesforce imposes strict API governor limits that migration projects routinely underestimate. Bulk API 2.0 is the right tool for high-volume loads, but you still need to watch org-wide API usage: paid orgs such as Enterprise Edition start at 100,000 API requests per rolling 24 hours. (developer.salesforce.com)

The most dangerous failure mode is partial successes. Salesforce Bulk API operations can partially complete: 9,800 of 10,000 records insert successfully, while 200 fail silently due to validation rule conflicts or duplicate external IDs. Standard tools handle these limits poorly — they will often mark a batch as "successful" while silently dropping child records such as email attachments or task relationships because the API rejected the nested payload. If you're not monitoring the successful, failed, and unprocessed result sets — not just the success count — you'll ship a partially loaded org with orphaned children and broken automations.

Before any bulk load:

• Audit and disable non-critical validation rules, triggers, and flows in the target org. Re-enable post-migration and run regression tests.
• Enforce parent-before-child load order. Accounts before Contacts. Contacts before Opportunities. Opportunities before Line Items. Break this sequence and your relational links are destroyed.
• Use External ID fields as the join key to maintain referential integrity between source and target records.

Rollback posture for CRM: The external ID crosswalk is your recovery mechanism. If a bulk load batch corrupts data or the target org rejects a load, you can use the crosswalk to identify exactly which records were affected, delete the failed batch from the target using the external IDs, fix the source data, and re-run. This only works if you preserve the crosswalk outside the target system and track batch-level status for every record. If you skip the crosswalk, a failed batch at scale means manual forensics with no reliable way to separate clean records from corrupted ones.

For a deeper technical breakdown of CRM migration pitfalls, see Best Practices for CRM Data Migration in 2026: The Engineer's Guide.

Cross-platform CRM merges (Salesforce ↔ HubSpot ↔ Dynamics 365)

When the acquiring company and target run different CRMs, the migration becomes a schema translation problem. Salesforce uses junction objects and polymorphic fields. HubSpot uses a flexible multi-directional association model with per-object limits and batch caps (1,000 inputs for reads, 2,000 for creates per batch). (developers.hubspot.com) Dynamics 365 has its own entity-relationship paradigm. Flat CSV exports destroy all of these relationships.

Deduplication across two different CRM platforms requires fuzzy matching on company names, email domains, phone numbers, and addresses — because the same customer will have slightly different records in each system. Implement deterministic matching first (exact matches on unique identifiers like DUNS numbers or localized tax IDs), followed by probabilistic matching (fuzzy logic on company names and domains). Retain the acquiring company's record as the master, but append the acquired company's historical activity timeline to the surviving record. Enterprise-scale M&A dedup typically requires custom matching logic that accounts for industry-specific edge cases — subsidiaries that share a parent domain, franchise locations with identical names.

This is also the phase where you should explore running both CRMs in parallel temporarily rather than forcing a hard cutover. A parallel run lets sales teams validate data integrity before the legacy system goes dark. For the argument behind this approach, see Why Running Two CRMs in Parallel Beats a Hard Cutover.

Finance system interoperability

In the same window, finance usually needs interoperability before replacement: chart-of-accounts crosswalks, customer and vendor master alignment, open AR and AP feeds, tax ID handling, bank file formats, and close-calendar sequencing. Define the minimum finance operating model needed for TSA exit, then build interfaces to that model instead of trying to rewrite the whole back office mid-deal. (grantthornton.com)

If the acquisition involves multi-entity or multi-currency structures, the finance integration grows substantially in complexity. Chart-of-accounts crosswalks must account for intercompany elimination entries — transactions between the acquiring and acquired entities that must cancel out in consolidated reporting. Multi-currency environments require agreement on revaluation timing and exchange rate sources before any data moves. These are not post-migration cleanup tasks; they are prerequisites. If the consolidated chart of accounts isn't mapped and the intercompany elimination logic isn't defined before the first GL entry migrates, your finance team will spend months reconciling a ledger that was broken at load time.

The ID crosswalk

Every CRM or finance merge needs a durable ID crosswalk. Keep it outside the target system so you can reconcile, replay failures, and answer audit questions later.

system,object,old_id,canonical_id,target_id,batch,status
salesforce,Account,001A...,CUST-2048,001Z...,wave-2,migrated
hubspot,company,987654,CUST-2048,445566,wave-2,mapped
netsuite,customer,12345,CUST-2048,88991,wave-2,validated

Week 7 to Week 12: Consolidating HRIS, Payroll, and ITSM

HRIS and payroll: the compliance minefield

HRIS and payroll data migration carries the highest regulatory risk of any M&A workstream. Employee PII, compensation data, tax withholding records, and benefits elections are subject to GDPR, CCPA, HIPAA (for health plan data), and jurisdiction-specific labor laws. If the acquisition crosses borders — a US company acquiring a European firm — GDPR compliance requirements around data transfer mechanisms (SCCs, adequacy decisions) must be resolved before a single record moves.

Under GDPR and CCPA, you cannot simply dump employee records into a staging database. Data must be encrypted at rest and in transit, and PII must be masked during the testing phase.

Payroll specifically cannot have a gap. A missed or incorrect payroll run post-acquisition destroys employee trust faster than any other integration failure. A single misaligned decimal in a compensation field or a dropped tax dependency flag will result in failed payroll runs. The safest approach is continuous data sync between old and new HRIS/payroll systems during the transition period, with a planned cutover timed to a payroll cycle boundary — not mid-cycle.

Rollback posture for HRIS and payroll: Keep the source HRIS and payroll system fully operational through at least one complete payroll cycle after cutover. If the target system produces incorrect payroll runs, you need the ability to fall back to the source system and re-run payroll from the last known-good state. This means maintaining active licenses and data sync on the source system past the planned cutover date — budget for this explicitly rather than decommissioning the source the day after cutover.

For the full compliance framework around sensitive employee data moves, see How to Safely Migrate Sensitive Employee & Payroll Data: A Guide to Security & Compliance.

ITSM and helpdesk consolidation

If both companies run separate helpdesks (Zendesk, Freshdesk, Jira Service Management, Intercom), you need to decide: consolidate to one, or keep both running? The answer depends on whether the acquired company's support team is being absorbed or operating independently.

Consolidation means migrating ticket history, customer records, automation rules, macros, SLA configurations, and knowledge base articles. The primary failure mode is the corruption of ticket statuses and SLA timers. If an open ticket is migrated and the SLA timer is reset, support SLAs will breach silently. You must map the exact timestamp of the original ticket creation and the last agent reply.

Automation and workflow migration is consistently the most underestimated workstream — every trigger, macro, and routing rule is platform-specific and must be rebuilt, not copied.

If you're merging Zendesk instances, we've documented the exact process in How to Merge Two Zendesk Accounts: The Technical Migration Guide. For consolidating multiple platforms, see How to Migrate Multiple Help Desks Into One.

Data Governance in the Combined Entity

Once systems are consolidated, a question that rarely gets answered during the migration itself becomes urgent: who owns the merged data?

During the migration, ownership is implicit — the integration team controls the data because they're the ones moving it. After cutover, that implicit ownership must become explicit. Every consolidated system needs a designated data steward in the combined organization: someone accountable for data quality, access control, and ongoing compliance. Without this, the merged dataset drifts within months — duplicate records reappear, field conventions diverge between legacy teams, and nobody knows who has authority to resolve conflicts.

At minimum, establish a RACI for the merged data layer:

• Who can create new records in the consolidated CRM, HRIS, or finance system?
• Who approves changes to shared reference data (chart of accounts, picklist values, territory assignments)?
• Who is accountable for data quality audits post-migration?
• Who resolves conflicts when teams from the two legacy organizations disagree on how a field should be used?

This is not a technical problem — it's an organizational one. But if you don't address it during the integration, the technical work you did to merge the data will degrade as soon as the integration team moves on.

Validation and Testing Across Migration Phases

The phrase "run regression tests" is easy to write and hard to execute. Every migration phase needs a structured validation protocol — not just a final record count comparison.

What validation looks like per system

Identity and email: After each mailbox migration batch, validate that calendar items, contacts, and folder structures are intact in the target. Check that Outlook profiles reconfigure correctly. Test mail flow bidirectionally between migrated and non-migrated users. Verify that distribution list membership resolved correctly.

CRM: After each migration wave, validate record counts at the object level (Accounts, Contacts, Opportunities, Line Items). Then validate relationships — confirm that Contacts are still associated with the correct Accounts, that Opportunities still link to the right pipeline stages, and that activity history (emails, calls, tasks) is attached to the correct parent records. Run a sample audit: pull a random set of records from the source and manually verify their counterparts in the target. Automated reconciliation scripts that compare source-to-target record counts per object and flag discrepancies are not optional at scale.

Finance: Validate that trial balances match between source and target after GL migration. Confirm that open AR and AP balances carried over correctly. Verify that intercompany elimination entries produce the expected consolidated result.

HRIS and payroll: Run a parallel payroll cycle — process payroll in both the source and target systems simultaneously and compare outputs line by line before cutting over. Validate that tax withholding configurations, benefits elections, and direct deposit details all transferred correctly for every employee, not a sample.

ITSM: Verify that migrated tickets retain their original creation timestamps, SLA timers, and status values. Test that automation rules and macros fire correctly in the target system by running them against a set of test tickets before migrating live data.

The "Two Systems Forever" Trap

The most common M&A integration failure isn't a botched migration. It's the migration that never happens. Companies end up running parallel systems indefinitely — two CRMs, two helpdesks, two HRIS platforms — because the fear of data loss or downtime paralyzes the integration team. Every month of dual-system operation compounds costs: duplicate licensing, split reporting, manual data reconciliation, and confused employees who don't know which system is the source of truth.

This trap has a predictable trigger: the TSA expires before migration completes, and the organization loses access to the source system's APIs. The data is locked behind a tenant you can no longer reach, and the migration window has closed.

It also starts with a bad assumption: that the migration tool will handle long-running sync. Standard tools often don't. BitTitan states explicitly that MigrationWiz is not a sync tool. Microsoft's native cross-tenant OneDrive move is one-and-done. If both companies need months of parallel operation, you must engineer that sync intentionally or accept drift as a business decision. (help.bittitan.com)

The engineering solution is to separate the migration from the cutover:

1. Pre-migrate data continuously using delta sync pipelines that keep both systems current throughout the transition period.
2. Validate completeness with automated reconciliation checks — record counts, checksum comparisons, relationship integrity audits.
3. Execute cutover as a config switch, not a data move. By cutover day, the data is already in the target. You're just flipping the pointer.

Write the exit criteria up front: source becomes read-only, final delta window closes, exception queue hits zero, business sign-off clears, legacy routing is removed, and old licenses are shut off.

For the argument behind parallel CRM operation during transitions, see Why Running Two CRMs in Parallel Beats a Hard Cutover.

The 90-Day M&A Data Migration Checklist

Use this as a sequencing guide. Adjust timelines based on deal complexity, organization size, and TSA terms.

Day 1–7: Stabilize and Coexist

• Establish cross-tenant mail routing and free/busy coexistence
• Unify Global Address List across both organizations
• Audit AIP encryption and sensitivity labels on source mailboxes
• Secure admin access to all source and target systems
• Map conditional access policies and RBAC role assignments across both tenants
• Confirm TSA end date and negotiate extension triggers if possible
• Communicate integration timeline to all employees

Week 2: Inventory and Prioritize

• Complete system-of-record map for both organizations
• Document record counts, data volumes, and API constraints per system
• Catalog integration middleware (iPaaS platforms, custom APIs) and flag TSA-dependent integrations
• Build migration priority matrix (identity → email → CRM → finance → HRIS → ITSM)
• Identify compliance requirements by jurisdiction (GDPR, CCPA, SOX)
• Define pass/fail criteria and rollback procedures for each migration phase

Week 3–6: CRM and Finance Consolidation

• Run cross-organization contact/account deduplication
• Map CRM schemas: custom fields, picklists, relationships, automations
• Disable non-critical validation rules in target CRM
• Execute CRM migration in parent-before-child load order
• Validate pipeline integrity: deals, stages, amounts, owners
• Validate relationship integrity: sample audit of parent-child associations across migrated records
• Build external ID crosswalk tables for CRM and finance objects
• Align charts of accounts, map intercompany elimination entries, and begin finance system integration

Week 7–12: HRIS, Payroll, ITSM, Knowledge Base

• Migrate employee records with full PII compliance chain of custody
• Run parallel payroll cycle in source and target before cutover
• Time payroll cutover to cycle boundary — never mid-cycle
• Consolidate helpdesk instances: tickets, automations, SLAs, KB articles
• Validate ticket timestamps and SLA timers post-migration
• Set up 301 redirects for any public-facing knowledge base URL changes
• Run final reconciliation: record counts, relationship audits, user access tests
• Decommission source systems and TSA dependencies

Post-90 Days: Validate and Optimize

• Confirm all users are operating in target systems only
• Retire legacy licenses and close TSA
• Assign data stewards for each consolidated system in the combined organization
• Run adoption audit: are teams actually using the consolidated systems?
• Get business sign-off on exception queues, not just record totals
• Document lessons learned for the next acquisition

Communication at Each Phase

Technical migration without communication creates chaos. Google's identity-merge guidance tells admins to communicate a clear change plan when users will sign in differently or send from an alias. Do this at each phase, not once at kickoff.

• Day 1: Send a clear, honest "what's changing and what's not" email to all employees. Silence breeds doubt and accelerates attrition.
• Week 2: Brief department heads on the migration timeline and what it means for their teams specifically.
• Week 3–6: Give CRM users advance notice of schema changes. Offer training sessions before cutover, not after.
• Week 7–12: HRIS and payroll changes require individual employee communication — not a mass email. People care about their paychecks more than any other system.
• Cutover week: Clarify what is read-only, what is still writable, who owns exceptions, and where users escalate issues.

The common failure is treating integration as a purely technical workstream and then wondering why adoption lags.

When Standard M&A Migration Tools Hit Their Limits

Out-of-the-box tools like MigrationWiz, ShareGate, and Data Loader handle the well-paved paths. They break down in predictable ways during M&A:

• Encrypted or held content that can't be moved without manual intervention
• Complex relational data (Salesforce junction objects, HubSpot multi-associations) that flattens during export
• API rate limits that cause silent partial failures at scale
• Cross-platform schema mismatches that no wizard can auto-resolve
• Zero-downtime requirements that demand continuous sync, not batch migration

BitTitan positions MigrationWiz as an M&A-focused tenant migration bundle. ShareGate markets its tenant-to-tenant tooling for mergers and divestitures. Microsoft FastTrack offers invitation-only cross-tenant services for Exchange, SharePoint, and OneDrive, but explicitly excludes Teams, architecture planning, and post-migration orchestration. (bittitan.com) These are not defects — they are scope boundaries. If your integration sits inside those boundaries, use them.

If you need cross-system dedup, custom object translation, staged coexistence, rate-limit-aware bulk loading, or zero-downtime execution across CRM, finance, HRIS, and support systems, you need custom work at the data layer. ClonePartner is an engineer-led service that writes custom scripts for every migration. We handle the parent-child relationships and metadata that standard tools drop, build rate-limit-aware pipelines that prevent silent failures, and provide continuous data sync that eliminates the hard-cutover blackout. If your M&A integration timeline is tighter than your internal team's bandwidth, that's the problem we solve.