---
title: "The M&A Data Migration Playbook: A 90-Day IT Integration Guide"
slug: the-ma-data-migration-playbook-a-90-day-it-integration-guide
date: 2026-05-22
author: Raaj
categories: [General]
excerpt: "A 90-day technical playbook for M&A IT integration: tenant migration, CRM consolidation, HRIS cutover, and the tool constraints that break standard approaches."
tldr: "M&A IT integration runs on a hard TSA clock. This playbook sequences identity, CRM, and HRIS migrations with the exact tool constraints and failure modes that catch teams mid-deal."
canonical: https://clonepartner.com/blog/the-ma-data-migration-playbook-a-90-day-it-integration-guide/
---

# 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](https://www.epcgroup.net/services/carve-out-microsoft-365-migration?utm_source=openai))

> [!WARNING]
> TSA extensions are expensive and rarely guaranteed. Sellers prefer hard-stop dates to minimize distraction and liability. If your data migration plan doesn't account for TSA expiry, you're building on a foundation with a ticking clock.

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](https://learn.microsoft.com/en-us/microsoft-365/enterprise/cross-tenant-mailbox-migration?view=o365-worldwide&utm_source=openai))

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](https://learn.microsoft.com/en-us/microsoft-365/migration/cross-tenant-onedrive-migration?view=o365-worldwide&utm_source=openai))

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](https://help.bittitan.com/hc/en-us/articles/360041736314-MigrationWiz-Migrated-and-Not-Migrated-Items?utm_source=openai))
- **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](https://help.sharegate.com/en/articles/10236513-the-migration-of-managed-metadata-columns-is-not-supported-when-migrating-microsoft-teams-private-channels))
- **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](https://help.bittitan.com/hc/en-us/articles/6488570876955-Exchange-Online-Microsoft-365-to-Exchange-Online-Microsoft-365-Mailbox-Migration-Guide?utm_source=openai))

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.

### 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](https://support.google.com/a/answer/10308069?hl=en))
- 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](https://support.google.com/a/answer/7032598?hl=en&utm_source=openai))

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.

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](https://www.grantthornton.com/insights/case-studies/healthcare/2025/ma-it-integration-delights-patients-providers))

Build a system-of-record map that covers:

| Category | Typical Systems | Key Questions |
|---|---|---|
| Identity & Access | Azure AD / Entra ID, Okta, Google Workspace | How many users? Conditional access policies? MFA providers? |
| Collaboration | SharePoint, OneDrive, Teams, Slack, Google Drive | Total data volume? Version history depth? Custom workflows? |
| CRM | Salesforce, HubSpot, Dynamics 365, Pipedrive | Record counts? Custom objects? Integration dependencies? |
| Finance | NetSuite, QuickBooks, Sage Intacct, Xero | Chart of accounts alignment? Multi-entity? Multi-currency? |
| HRIS & Payroll | Workday, BambooHR, ADP, Gusto | PII sensitivity? Regulatory jurisdiction? Payroll schedule? |
| ITSM & Helpdesk | Zendesk, Freshdesk, Jira Service Management | Ticket volume? Automation rules? SLA configurations? |
| Knowledge Base | Confluence, Notion, SharePoint, Zendesk Guide | Article count? URL structure? Internal vs. external? |

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.

> [!TIP]
> Build one integration register with four columns that everyone can understand: `system`, `business owner`, `source of truth`, and `TSA exit dependency`.

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](https://developer.salesforce.com/docs/commerce/salesforce-commerce/guide/b2b-d2c-comm-deploy-object-data.html?utm_source=openai))

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.

For a deeper technical breakdown of CRM migration pitfalls, see [Best Practices for CRM Data Migration in 2026: The Engineer's Guide](https://clonepartner.com/blog/blog/best-practices-for-crm-data-migration-in-2026-the-engineers-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](https://developers.hubspot.com/beta-docs/guides/api/crm/associations)) 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](https://clonepartner.com/blog/blog/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](https://www.grantthornton.com/insights/case-studies/healthcare/2025/ma-it-integration-delights-patients-providers))

### 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.

```csv
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.

> [!CAUTION]
> Do not schedule payroll cutover, helpdesk cutover, and domain cutover in the same week unless you enjoy creating your own incident queue.

For the full compliance framework around sensitive employee data moves, see [How to Safely Migrate Sensitive Employee & Payroll Data: A Guide to Security & Compliance](https://clonepartner.com/blog/blog/payroll-data-migration-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](https://clonepartner.com/blog/blog/how-to-merge-two-zendesk-accounts-the-technical-migration-guide/). For consolidating multiple platforms, see [How to Migrate Multiple Help Desks Into One](https://clonepartner.com/blog/blog/how-to-migrate-multiple-help-desks-into-one/).

## 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](https://help.bittitan.com/hc/en-us/articles/6488570876955-Exchange-Online-Microsoft-365-to-Exchange-Online-Microsoft-365-Mailbox-Migration-Guide?utm_source=openai))

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](https://clonepartner.com/blog/blog/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
- [ ] 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
- [ ] Build migration priority matrix (identity → email → CRM → finance → HRIS → ITSM)
- [ ] Identify compliance requirements by jurisdiction (GDPR, CCPA, SOX)

### 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
- [ ] Build external ID crosswalk tables for CRM and finance objects
- [ ] Align charts of accounts and begin finance system integration

### Week 7–12: HRIS, Payroll, ITSM, Knowledge Base
- [ ] Migrate employee records with full PII compliance chain of custody
- [ ] Time payroll cutover to cycle boundary — never mid-cycle
- [ ] Consolidate helpdesk instances: tickets, automations, SLAs, KB articles
- [ ] 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
- [ ] 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](https://www.bittitan.com/tenant-migration/?utm_source=openai)) 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.

> Facing a post-acquisition data migration? Our engineers have consolidated CRMs, merged helpdesks, and migrated tenant data under TSA deadlines — with zero downtime. Book a 30-minute call to scope your integration.
>
> [Talk to us](https://cal.com/clonepartner/meet?duration=30)

## Frequently asked questions

### What is a Transition Services Agreement (TSA) in M&A?

A TSA is a contract where the seller continues providing IT, HR, payroll, and other shared services to the buyer for a defined period post-close, typically 60–180 days. Missing the TSA deadline means losing access to all systems and data hosted on the seller's infrastructure, with no default extension.

### Why do AIP-encrypted emails fail to open after a tenant-to-tenant migration?

Standard tools like MigrationWiz migrate the encrypted blob, but the destination tenant lacks the original Azure Information Protection decryption keys. Emails must be decrypted via PowerShell at the source before migration, then re-encrypted with the destination tenant's AIP policies.

### What breaks during a Salesforce org merge in M&A?

Salesforce Bulk API operations can partially complete — most records load while some fail silently due to validation rule conflicts or duplicate external IDs. Loading child records before parent records destroys relational links. Disable non-critical automations, enforce strict parent-before-child load order, and monitor the failed and unprocessed result sets after every batch.

### How do you avoid running two CRMs forever after an acquisition?

Use continuous delta sync to keep both CRMs current during transition, validate data completeness with automated reconciliation, then execute cutover as a configuration switch — not a data move. The data should already be in the target system before cutover day. Write exit criteria up front with a dated decommission plan.

### How long does post-acquisition IT integration take?

High-touch M&A IT integration (full system consolidation) typically takes 3–6 months. Most TSAs grant 60–180 days. The first 90 days should cover identity, email, CRM, and HRIS — the systems that directly impact employees and revenue. Cross-border or multi-entity deals will stretch longer.