Day 1 of a merger is a business event, not a migration event. EPC Group's 5-Gate Cutover Model sets explicit entry and exit criteria for deal certainty, environment truth, business readiness, cutover authorization and stabilization — so the go/no-go is a documented decision, not a Friday-night judgement call.
Last updated: 2026-07-31
EPC Group is a Houston-based Microsoft consulting firm operating since 1997, with six Microsoft Solutions Partner designations and 216+ M&A tenant migrations covering 1.83M users. Governed Microsoft AI, Data & Cloud — since 1997.
Key facts
- Day 1 is fixed by the deal, not by IT. It is the first business day after legal close. The date does not move because a migration wave slipped.
- Microsoft's cross-tenant tooling moves content, not identities. Microsoft: "This migration moves content, not identities. Customers are responsible for correctly creating and configuring users." Target user creation is an HR and identity workstream, not a migration task.
- Mailboxes on any type of hold are blocked from native cross-tenant migration, as are OneDrive accounts under a hold policy. Holds are Legal's, and Legal is usually not in the IT project plan.
- The domain move is the longest-lead cutover item. A custom domain cannot be removed from the source tenant while any user, group, distribution list, team, shared or resource mailbox or admin sign-in still uses it, and cannot be verified in the target until released. Never schedule it for cutover night.
- Coexistence is a product capability, not an improvisation. Cross-tenant synchronization, cross-tenant access settings and the Microsoft 365 multitenant organization deliver cross-tenant people search, Teams chat, calling and meeting scheduling before any data moves.
- Teams collaboration across a multitenant organization is a mutual setting — every participating tenant must enable it, so it needs the other company's cooperation on a date.
- The Migration Orchestrator's Tenant Move/Split model exists for divestitures. Microsoft names mergers, acquisitions, divestitures and internal reorganizations as supported contexts.
Quick facts
| Question | Answer |
|---|---|
| What is Day 1? | The first business day after legal close |
| Who owns the Day-1 date? | Corporate development and the deal team, not IT |
| What must work on Day 1? | Sign-in, payroll and HR access, correct mail routing, a way to find and message colleagues, revenue-critical systems |
| Biggest single Day-1 failure cause | Target identities created wrong or late |
| Longest-lead technical item | Custom domain release from the source tenant |
| Does Microsoft's native tooling move identities? | No |
| What blocks a mailbox from native migration? | Any type of hold |
| What is a TSA? | Transition services agreement — the seller runs services for the buyer for a fixed term at a fixed cost |
| Who signs the go/no-go? | A named executive, per gate, in writing |
Why M&A IT integration fails, and it is rarely the migration
Across EPC Group's M&A delivery history, the programmes that hurt did not fail on throughput. They failed because a decision that was not IT's to make had not been made, and IT found out at cutover.
Four patterns repeat. Nobody wrote down what Day 1 means, so every function assumed its own scope was in it. Identity was treated as a migration task rather than an HR data problem, so target accounts came from a stale employee list. Legal holds surfaced two weeks out, blocking mailboxes the plan assumed would move. And the domain move was scheduled for cutover weekend — the one item that cannot be compressed. Each is a business-readiness failure with a technical symptom, which is why this model gates on business readiness first.
The 5-Gate Cutover Model
The 5-Gate Cutover Model is EPC Group's framework for M&A Microsoft 365 integration. Each gate has explicit entry criteria, exit criteria and a named executive owner who signs. A gate cannot be exited on partial evidence, and none may be skipped because the timeline is tight — if the timeline is tight, you reduce Day-1 scope, not gate rigour.
Gate 1 — Deal Certainty
| Entry | Signed purchase agreement or definitive agreement; IT named in the integration management office; NDA and clean-team protocol in place |
|---|---|
| Work | Establish the integration management office cadence. Confirm the deal structure: merger, asset purchase, carve-out or divestiture. Identify regulatory approvals that could move close. Determine whether a TSA exists and what IT services it covers. Agree the target-state tenant: consolidate into buyer, into seller, or stand up new |
| Exit | A written, executive-approved target-state tenant decision; a confirmed or bounded close date; a named business owner per function; written clean-team rules |
| Owner signs | CIO and Head of Corporate Development |
Gate 1 is where most programmes lose two months. Pre-close, competition law restricts what the parties may share. Agree the clean-team protocol early — what data, by whom, seen by whom — or discovery will not start until after close and Day 1 arrives with no inventory.
Gate 2 — Environment Truth
| Entry | Clean-team protocol agreed; read access granted to both tenants at the agreed scope |
|---|---|
| Work | Full inventory of both estates: users, mailboxes and sizes, shared and resource mailboxes, distribution lists, delegate chains, OneDrive and SharePoint volume, teams and channels, guest and service accounts, custom domains, conditional access, sensitivity labels, retention and legal holds, licence entitlements, line-of-business integrations, on-premises remnants and devices. Reconcile the IT user list against the HR system of record |
| Exit | A signed inventory both sides agree is accurate; a written hold register from Legal; a licence gap analysis; a named list of every Day-1-critical system; the tooling decision |
| Owner signs | IT integration lead and both tenant administrators |
Two exit criteria carry disproportionate weight. The HR reconciliation — the IT user list is always wrong, and the gap between it and the HR record is your Day-1 identity error rate. The hold register — Legal must state, per user, whether a hold exists and can be released, migrated and reapplied. If not, that population needs a different plan, and you need to know at Gate 2.
Gate 3 — Business Readiness
| Entry | Signed inventory from Gate 2 |
|---|---|
| Work | Every non-IT dependency resolved. HR confirms the Day-1 roster, the UPN standard and the payroll access path. Legal confirms holds, retention obligations and data-residency constraints. Finance confirms entity codes, cost centres, expense and procurement access, and who pays for licences from close. Security confirms conditional access, MFA enrolment, privileged access and the cross-estate incident-response bridge. Comms confirms the Day-1 message set, the email addressing decision and support routing |
| Exit | A signed Day-1 Minimum Viable Integration definition; a completed RACI; the licence purchase order raised; comms approved; the identity naming standard published |
| Owner signs | CHRO, General Counsel, CFO, CISO and Head of Communications — five signatures, not one |
Gate 3 decides the programme. If you take one thing from this model: do not enter technical execution until five business functions have signed.
Gate 4 — Cutover Authorization
| Entry | Gate 3 signed; migration tooling procured and configured; coexistence live |
|---|---|
| Work | Pilot wave executed and validated, including a representative delegate chain, a shared mailbox, a hold-released mailbox and a licensed target user. Domain release sequence started. Full dress rehearsal of the cutover runbook with the actual on-call roster. Rollback path documented and tested. Hypercare staffing confirmed with names and shifts |
| Exit | Pilot reconciliation clean; rollback tested, not just written; hypercare rota published; a named individual holds the abort decision; comms queued |
| Owner signs | CIO |
The exit criterion people skip is rollback tested, not just written. A rollback plan never executed is a document, not a control.
Gate 5 — Day-1 Stability and Handover
| Entry | Cutover executed |
|---|---|
| Work | Hypercare runs to the published rota. Ticket volume and category tracked hourly for 48 hours, then daily. Reconciliation evidence assembled per workload. Deferred scope moved into the Day-100 backlog with owners and dates. Source tenant decommission planned, not executed |
| Exit | Ticket volume back to baseline; reconciliation signed by the business owner per workload; Day-100 backlog accepted with named owners; TSA exit or extension decision made; decommission date set |
| Owner signs | CIO and the business owner of each migrated function |
Programmes are declared successful too early here. The exit criterion is the business owner signing reconciliation — not IT declaring the batch complete.
Aligning the gates to the deal timeline
The deal has four fixed dates. The gates map onto them, and the mapping is what makes this fundable.
| Deal milestone | What is legally true | Gates in flight | The IT question that must be answered |
|---|---|---|---|
| Signing | Agreement executed; close is conditional. Parties remain competitors and clean-team rules apply | Gate 1; Gate 2 begins under clean-team constraints | What is the target-state tenant, and what may we look at before close? |
| Pre-close | Regulatory review; the close date may move | Gate 2 completes; Gate 3 runs | Are the five business functions ready, and what does Day 1 mean? |
| Close | Ownership transfers. Employees legally transfer. TSA, if any, starts | Gate 4 | Can people sign in, get paid and be reached on the right address tomorrow? |
| Day 1 | First business day under new ownership | Gate 4 exits, Gate 5 begins | Does the minimum viable integration work, and is hypercare staffed? |
| Day 100 | Savings begin to be measured | Gate 5 exits; deferred backlog executes | Is the estate consolidated enough to retire duplicate cost? |
Two scheduling rules follow. Gate 3 must complete before close — the decisions it captures require people who are unavailable in close week. And never plan Day 1 as the largest technical event of the programme. That should be a rehearsed wave weeks earlier. Day 1 should be an anticlimax.
Day-1 Minimum Viable Integration: what genuinely must work
This is the artefact that ends most arguments. Write it, get it signed at Gate 3, and defend it.
| Capability | Day 1 | Day 100 | Why |
|---|---|---|---|
| Sign-in to a corporate identity | Required | — | Nothing else works without it |
| Access to payroll, benefits and HR self-service | Required | — | A missed pay run is a board-level incident |
| Inbound mail reaching the right person | Required | — | Customers and regulators write to the address on file |
| A way to find and message any colleague | Required | — | Cross-tenant sync and the multitenant organization deliver this without migrating anything |
| Revenue-critical line-of-business systems | Required | — | Deal-specific: order entry, claims, dispatch, clinical, trading |
| Security monitoring across both estates | Required | — | Day 1 is the highest-risk phishing window a company ever has |
| A support route with known capacity behind it | Required | — | Hypercare capacity is the difference between a wobble and an outage |
| Mailbox, OneDrive and SharePoint content migrated | — | Deferred | Coexistence handles mail flow and access; history can follow |
| Teams channels and team structure consolidated | — | Deferred | Native tooling does not move channels at all; plan it as a project |
| Duplicate licence and tenant cost eliminated | — | Deferred | This is the savings line, and it depends on decommission |
| Intranet, branding and portal consolidation | — | Deferred | Visible, emotive, almost never urgent. See SharePoint migration services |
The pattern is consistent: Day 1 needs access and reachability. Day 100 needs consolidation. Anyone arguing that content history must migrate by Day 1 is solving for comfort, not risk. Coexistence — cross-tenant synchronization for directory presence, cross-tenant access settings for authentication, and the multitenant organization for Teams search, chat, calling and meetings — is what buys the right to defer.
The business-readiness dependency map and RACI
Six functions, one integration. The failure mode is each assuming another owns the decision.
| Decision or dependency | Accountable | Responsible | Consulted | Informed |
|---|---|---|---|---|
| Target-state tenant decision | CIO | IT integration lead | CFO, General Counsel | All functions |
| Day-1 employee roster and effective date | CHRO | HR operations | IT, Finance | Managers |
| UPN, display-name and email addressing standard | CIO | Identity lead | CHRO, Communications, Marketing | All employees |
| Legal holds, data residency and regulatory constraints | General Counsel | Records / eDiscovery / Compliance | CISO, IT | IT integration lead, deal team |
| Licence entitlement, purchase, cost-centre and entity mapping | CFO | IT procurement and Finance systems | CIO, HR, IT | Vendor management, business owners |
| Conditional access, MFA and privileged access | CISO | Security engineering | IT, HR | All employees |
| Day-1 communications and support routing | Head of Comms | Internal comms | CIO, CHRO, service desk | Employees, customers |
| TSA scope, cost and exit dates | CFO | Legal and IT | CIO, General Counsel | Deal team |
| Go / no-go per gate, and Day-100 backlog acceptance | Named gate owner, then CIO | IT integration lead | Gate contributors, business owners | Board and deal team |
Two rules make a RACI survive contact with a deal. One accountable name per row, never a committee. And the accountable name is a person, not a role title — in an M&A, roles are what is changing.
TSA implications — where the clock and the cost live
In a carve-out or divestiture, a transition services agreement has the seller running IT services for the buyer for a defined term at a defined price. It buys time. It also creates four obligations most IT plans underweight.
The TSA sets the real deadline. The exit date, not Day 1, is when the buyer must be independent, and every deferred item in the Day-100 backlog has to land before it. Model the schedule backwards from TSA exit.
TSA service costs usually escalate. Extension pricing is typically punitive by design, because the seller wants separation. Slipping the migration therefore carries a direct contractual monthly cost — the single most effective way to get an integration programme funded properly. Put the escalation schedule in the business case.
TSA scope is negotiated before IT sees it. If the agreement says "email services" without specifying archive access, eDiscovery support, mailbox delegation or hold preservation, you will be arguing in month three. Get IT into the drafting at Gate 1 and require a service catalogue with named systems, service levels and data-extraction obligations.
Data separation is a legal obligation, not a tidy-up. At exit, neither party may still hold the other's data — a documented decommission with evidence, not a tenant that quietly stays alive. Our SOC 2 compliance guide covers the control mapping. Where no TSA exists, the equivalent forcing function is the source tenant's renewal date. Find it at Gate 1.
The communications plan
Day-1 comms are a leadership instrument, and from IT's side the cheapest ticket-deflection tool available.
| Audience | When | Message | Owner |
|---|---|---|---|
| Acquired-company employees | Announcement day | What stays the same. Explicitly: your laptop, email address and login are unchanged for now | CEO + CHRO |
| All employees, plus a manager briefing pack | Close minus 2 weeks | What changes on Day 1, what does not, the one place to ask questions, and answers on pay, benefits, email and access | Head of Comms + CHRO |
| Service desk (both sides) | Close minus 1 week | Known issues, scripted answers, escalation path, hypercare rota, who authorizes exceptions | IT integration lead |
| Customers and partners | Per legal guidance | Which email address to use, and when that changes | Marketing + General Counsel |
| Users in a migration wave | Wave minus 5 days | Your content moves on date. What to close, what not to edit, what changes afterwards | IT integration lead |
| All employees | Day 1, 08:00 | We are live. How to get help. What is still coming | CIO + CEO |
| Executive committee | Day 1, 3 and 7 | Ticket volume by category against baseline, open risks, decisions needed | CIO |
Two details deflect most tickets. **Say what is not changing — unchanged sign-in and email addressing is the reassurance people actually want. And give one route for questions**, not three. Microsoft's own guidance makes the same point for content moves: tell users when the migration starts, how long it lasts, what the new URLs are, and to close their files during the window. Our Teams Premium guide covers what changes in the client.
What breaks — failure modes
| Symptom | Root cause | Fix |
|---|---|---|
| Transferred employees cannot sign in on Day 1 | Target accounts built from an IT user list rather than the HR system of record | Reconcile against HR at Gate 2 and again 72 hours before close. Identity is an HR data problem |
| Mailboxes fail to move; batch blocked | Mailboxes on a legal hold; Microsoft blocks the move for any type of hold | Get a hold register from Legal at Gate 2. Release, migrate, reapply on target — or route that population to a tool that supports it |
| Migration starts, then fails per user | Target user already has a mailbox or OneDrive provisioned | Run identity mapping before licensing; restrict OneDrive and site creation in the target tenant |
| Ticket volume overwhelms the service desk on Day 1 | Hypercare sized from migration effort, not from population and change magnitude | Size hypercare from the number of people whose sign-in or address changed. Publish a named rota before Gate 4 exits |
| Executives lose assistant access to calendars and mailboxes | Cross-tenant mailbox and calendar permissions are not supported; principals and delegates moved in different batches | Map delegate chains at Gate 2; move every principal with their delegates in one batch |
| External mail bounces or reaches the wrong entity after cutover | Domain moved before all objects were cleared, or routing changed without a mail-flow rehearsal | Start domain release weeks ahead; clear every user, group, DL, team, shared and resource mailbox first; rehearse mail flow |
| Nobody can find or message anyone across the two companies | Coexistence never configured — no cross-tenant sync, no multitenant organization, Teams collaboration not mutually enabled | Stand up coexistence at Gate 3. Teams collaboration requires both tenants to enable it |
| The programme stalls two months in with no inventory | Clean-team protocol never agreed, so pre-close discovery could not legally begin | Make the clean-team protocol a Gate 1 exit criterion, in writing |
| TSA costs escalate and nobody forecast it | Schedule built forward from Day 1 instead of backward from the TSA exit date | Rebuild the plan backwards from TSA exit; put the escalation schedule in the business case |
| Two tenants still running at Day 200 and the savings case is missed | Decommission treated as cleanup rather than the deliverable that releases the savings | Make source-tenant decommission a dated, owned Gate 5 exit item with a Finance owner |
What changed in 2026
- The Migration Orchestrator entered public preview, coordinating Exchange mailboxes, OneDrive, Teams chats and meetings in dependency-ordered batches across three models — Single-Event, Phased, and Tenant Move/Split. The last is aimed squarely at divestitures.
- Cross-Tenant Identity Mapping became a required step for orchestrated migrations, formalising what this model has always argued: identity preparation is a gate, not a task inside migration.
- A Cross-Tenant User Data Migration per-user add-on licence now applies to orchestrated Exchange and OneDrive moves, assignable on either side. Your Gate 3 purchase order must carry it.
- Microsoft published a consolidated tenant-to-tenant planning page naming mergers, acquisitions, divestitures and internal reorganizations as first-class scenarios.
- Multitenant organization capabilities matured, including per-tenant user labels in Teams so people can tell which company a colleague belongs to during coexistence.
- Microsoft's Teams collaboration setting for multitenant organizations is explicitly mutual, making cross-tenant Teams a negotiated date with the other party rather than a unilateral IT change.
Where to go next
If your close date is set and nobody has written down what Day 1 means, that is the first deliverable — not the migration plan. EPC Group runs Gates 1 through 3 as a fixed-scope engagement and hands the executive committee a signed Day-1 Minimum Viable Integration definition, a completed RACI, a hold register and a costed cutover plan. Start with Microsoft consulting or Azure cloud migration consulting.
Related: Exchange to Office 365 migration · Microsoft 365 E3 vs E5 · E3 vs E5 · Copilot pricing and licensing · Azure Virtual Desktop deployment · SharePoint consulting Dallas · Data governance firms · Power Platform firms · Microsoft Frontier Company · CFO AI governance · Delivery partner vendor risk · EPC Group
Frequently asked questions
What is Day 1 in an M&A IT integration?
Day 1 is the first business day after legal close, when the acquired employees are legally yours. The date is set by the deal, not by IT, and does not move because a migration wave slipped. IT's job is to define and deliver the minimum capabilities that must work that morning.
Does everything have to be migrated by Day 1?
No, and attempting it is the most common cause of a bad Day 1. Day 1 needs access and reachability: sign-in, payroll and HR access, correct mail routing, a way to find and message colleagues, revenue-critical systems and security monitoring. Content, Teams consolidation and cost elimination belong to the Day-100 backlog.
Why does business readiness get its own gate?
Because most Day-1 failures are business-decision failures with technical symptoms. The employee roster is HR's. Holds are Legal's. Entity and cost-centre mapping is Finance's. Access policy is Security's. Addressing is Communications'. Gate 3 requires all five to sign before technical execution starts.
Does Microsoft's native tooling migrate user accounts?
No. Microsoft states the migration "moves content, not identities" and that customers are responsible for creating and configuring users correctly. Target accounts must be created and attribute-stamped before any content moves, which is why identity preparation sits in a gate of its own.
What is the longest-lead item in a tenant cutover?
The custom domain. It cannot be removed from the source tenant while any user, group, distribution list, team, shared or resource mailbox or admin sign-in still references it, and cannot be verified in the target until released. Start it weeks ahead; never schedule it for cutover night.
How does a TSA change the IT plan?
It sets the real deadline. The TSA exit date, not Day 1, is when the buyer must be independent, and extension pricing is usually punitive. Build the schedule backwards from TSA exit, get IT into the drafting so the service catalogue names actual systems, and treat data separation at exit as a documented obligation with evidence.
What does coexistence give us before migration?
Cross-tenant synchronization provisions B2B users into the other tenant so people appear in directories and address lists. Cross-tenant access settings govern authentication. A Microsoft 365 multitenant organization enables people search, Teams chat, calling and meeting scheduling across both. Together they deliver Day-1 reachability with no data moved.
Who signs the go/no-go?
A named individual per gate, in writing. Gate 1 is the CIO with Corporate Development. Gate 2 is the IT integration lead with both tenant administrators. Gate 3 requires five signatures — CHRO, General Counsel, CFO, CISO and Head of Communications. Gate 4 is the CIO. Gate 5 is the CIO plus the business owner of each migrated function. Assume the close date will move: complete Gates 1 to 3 against the earliest credible date, not the expected one.
Sources and verification
- Microsoft Learn — Plan a Microsoft 365 tenant-to-tenant migration
- Microsoft Learn — Tenant-to-tenant migration with orchestrator: overview
- Microsoft Learn — Orchestrator: planning and prerequisites
- Microsoft Learn — Cross-Tenant Identity Mapping
- Microsoft Learn — Cross-tenant mailbox migration
- Microsoft Learn — Cross-tenant SharePoint migration
- Microsoft Learn — Cross-tenant OneDrive migration
- Microsoft Learn — Microsoft 365 migration overview
- Microsoft Learn — Cross-tenant synchronization overview
- Microsoft Learn — Configure cross-tenant synchronization
- Microsoft Learn — Plan for multitenant organizations in Microsoft 365
- Microsoft Learn — Manage multitenant org settings
- Microsoft Learn — Microsoft 365 multitenant organization people search
- Microsoft Learn — Cross-tenant access settings for B2B collaboration
- Microsoft Learn — Remove a domain from Microsoft 365
- Microsoft Learn — FastTrack: Cross-Tenant Migration
- Practical365 — Microsoft 365 Tenant-to-Tenant Migration Assessment Version 2 (Sean McAvinue, 9 May 2024)
- Petri — Microsoft 365 Tenant-to-Tenant Migration Orchestrator (Rabia Noureen, 22 December 2025)