Microsoft 365 Tenant-to-Tenant Migration in UAE
A Microsoft 365 tenant-to-tenant migration moves agreed users and workloads between separate organisations' tenants. GR IT scopes identity, email, files, collaboration, devices and domain cutover, with a pilot and a written record of what moves and what needs separate work.
- 4Migration scenarios
- WavedBatch approach
- ZeroMail loss target
- UAEData region option
Which migration scenario is yours?
Two companies, two tenants, one future tenant.
An acquisition or merger where both organisations run their own Microsoft 365 tenant and one must absorb the other. The acquired tenant is migrated into the surviving tenant in waves, then decommissioned. The hard decisions are naming collisions (two people with the same first-name address), overlapping SharePoint structures, and how long the two companies coexist before day one.
- Users, mail, files, and Teams move into the surviving tenant
- UPN and email collision mapping agreed before anything moves
- Coexistence options (GAL sync, calendar sharing, mail routing) for long timelines
- Acquired domain joins the surviving tenant at cutover
Every workload in the tenant, each with its own method.
Entra ID identities and groups
Target identities, groups and roles are mapped against the source. We document credential, MFA and application changes for the selected method and validate the user journey in a pilot.
Exchange Online mailboxes
Mailboxes, calendars, contacts, shared mailboxes, and room mailboxes moved with native cross-tenant mailbox migration or proven third-party tooling. Delegate rights, send-as permissions, and auto-mapping rebuilt and verified per wave with reconciliation reports.
OneDrive for Business
OneDrive migration is planned against the selected method, identity mapping and supported data. We test permissions, version history and representative sharing links, then document any user action or resharing needed.
SharePoint Online sites
Site-by-site migration with an owner-confirmed inventory first, so dead sites are archived rather than paying to move digital landfill. Permissions, metadata, and version history preserved where tooling supports it; customisations and workflows rebuilt deliberately in the target.
Teams, with the truth about chats
Teams content is assessed workload by workload against current Microsoft and third-party options. We document supported chats, channels, files and application dependencies, including fidelity limits and acceptance checks.
Devices and Intune
Device transition depends on platform, identity and management method. We pilot enrolment, application and user-profile changes, identify any reset requirement and coordinate the work with user migration waves.
Domain and mail flow cutover
We coordinate domain release, verification, DNS and mail configuration in an agreed change window. The runbook includes continuity arrangements, decision points and mail-flow validation.
Licensing transition
We identify target subscriptions, required migration entitlements and source coverage during transition. Transfer and cancellation options are checked against subscription terms before the source is decommissioned.
Coexistence for long migrations
When waves span months, the two tenants must behave like one company: cross-tenant mail routing, GAL synchronisation, calendar free-busy sharing, and Entra B2B bridging into shared Teams. We stand this up early so the business never feels split while the migration runs.
What moves, what does not, and how.
| Workload | Moves? | How it moves | What to watch | |
|---|---|---|---|---|
| Exchange mailboxes | Yes, high fidelity | Native cross-tenant mailbox migration or third-party tooling | Mail, calendar, contacts, folders, and rules move; recoverable items and some delegate permissions need re-checking after the move | |
| OneDrive for Business | Yes, high fidelity | Native cross-tenant OneDrive migration or third-party tooling | Link continuity depends on the migration method and identity mapping. Test internal and external links and identify which need redirection or resharing. | |
| SharePoint sites | Yes, with planning | Cross-tenant SharePoint migration or third-party tooling, site by site | Check supported link redirection, permissions, customisations and integrations for each site; document any required rebuild or link update. | |
| Teams: teams and channel files | Yes, mostly | Assess current Microsoft and third-party migration support for each Teams workload. | Tabs, apps, and connectors usually need reconfiguring; channel message history migrates with formatting limits | |
| Teams: private 1:1 and group chats | Depends on supported tool and workload | Review current migration support and eligibility; validate the resulting chat history in a pilot. | Record fidelity limitations, exclusions and user steps for the selected method before migration. | |
| Entra ID identities | Recreated, not moved | Accounts are pre-created in the target tenant and mapped to source users | Define target account creation, credentials and MFA requirements for the chosen identity transition. | |
| Groups and memberships | Recreated | Microsoft 365 Groups, security groups, and distribution lists rebuilt from a mapped export | Dynamic membership rules and nested groups need re-validation in the target | |
| Devices (Intune, Entra joined) | Re-enrolled, not moved | Devices leave the source tenant and re-enrol into the target via Autopilot or manual enrolment | Windows devices typically need a reset or profile rebuild; Autopilot hardware hashes are re-registered to the target | |
| Custom domain | Yes, with a cutover window | Removed from the source tenant, then verified and configured in the target | A domain can live in only one tenant at a time, which is why the cutover is a scheduled event, not a background task | |
| Licenses | No | Confirm target subscriptions, migration entitlements and any permitted transfer arrangements with the licensing provider. | Plan required source and target coverage and check cancellation terms before scheduling decommissioning. | |
| Power Platform, Planner, Forms, Bookings | Limited | Power Platform solutions redeploy via export and import; Planner and Forms have limited third-party support and often need manual recreation | Inventory these early; they are the most commonly forgotten workloads and the most common day-two surprise | |
| Audit logs and compliance history | No | Purview audit history, eDiscovery cases, and retention state stay with the source tenant | Export what your regulator or legal team needs before the source tenant is decommissioned |
Four reasons UAE organisations hand us the riskiest week in IT.
Honest scoping before you spend
Our first deliverable is a written what-moves-what-does-not assessment against your actual tenants. If a domain rename or coexistence setup solves your problem without a full migration, we say so, because a migration you did not need is the most expensive kind.
Named UAE engineers through cutover weekend
The engineers who run your discovery run your cutover, on UAE time, reachable during the window. No handing your riskiest weekend to an anonymous offshore queue that has never seen your tenant.
Security baseline built into the target, not bolted on
The target tenant gets Conditional Access, MFA, Intune compliance, and Defender baselines before the first user lands. A migration is the one chance to leave legacy misconfigurations behind instead of importing them.
CSP licensing under the same roof
As a Microsoft Cloud Solution Provider we set up licensing for the target tenant on AED invoicing, manage the overlap period, and cut the source subscriptions at decommission. One partner accountable for the migration and the commercial transition.
The UAE situations that put tenant migration on the board agenda.
Acquisitions and mergers
A Dubai or Abu Dhabi group acquires a company with its own tenant. Legal close is done; now the two email systems, file estates, and Teams need to become one before the integration plan stalls on IT.
Divestitures under TSA deadlines
A business unit is sold and must be off the parent tenant by a contractual date. We carve out exactly the in-scope users and data into a new tenant and produce the evidence that nothing else left with them.
Free-zone restructures
Groups reorganising between free-zone and mainland entities (DIFC, ADGM, DMCC, JAFZA) that need the new legal entity on its own tenant, its own domain, and in some cases its own compliance boundary.
Family and holding groups consolidating
A holding company running many tenants across subsidiaries, each with different partners and security postures, consolidating into one governed tenant with one identity and licensing model.
Regulated entities fixing data residency
Financial, healthcare, and government-adjacent organisations whose tenant data sits in a region chosen years ago. A migration into a new tenant provisioned in the UAE data centre region is a chance to fix residency deliberately.
Rebrands that need a clean break
Companies changing name where the old onmicrosoft.com tenant identity, inherited clutter, or a compromised security history makes a fresh tenant the right call, confirmed by assessment rather than assumption.
Why the domain move is a scheduled event, and how we run it.
- 01Before· Weeks before
Pre-stage everything that does not need the domain.
In the weeks before cutover, target accounts are created on the target tenant onmicrosoft.com addresses, mailbox and file data is pre-synced in the background, and DNS TTLs are lowered so record changes propagate fast. By cutover night, the bulk of the data is already sitting in the target tenant, verified and waiting.
- Target accounts created and data pre-synced
- DNS TTLs lowered on MX, Autodiscover, SPF, and CNAME records
- Cutover runbook rehearsed, rollback criteria agreed in writing
- 02The window· Cutover window
Release, verify, rebind. Usually inside a weekend.
Every reference to the domain in the source tenant is stripped: user addresses, group addresses, and connectors fall back to onmicrosoft.com. The domain is then removed from the source, added and verified in the target, and set as the primary address for the migrated users. MX and Autodiscover records repoint to the target tenant. Inbound mail during the switch is queued and retried by sending servers, which is why a well-run cutover loses no mail even though there is a routing gap.
- Domain removed from source, verified in target
- MX, Autodiscover, SPF, DKIM, and DMARC repointed and re-proven
- Final delta sync of mail and files completed
- 03After· Days after
Monday morning is the real test. We are on it.
Users sign in with new credentials, Outlook and Teams re-profile against the target tenant, and mobile devices re-add accounts. We staff a hypercare desk for the first days: sign-in issues, profile rebuilds, missing shares, and broken links get fixed while the old tenant is kept intact as the safety net until sign-off.
- Hypercare support for sign-in, Outlook, Teams, and mobile
- Mail flow, free-busy, and sharing spot checks on live users
- Source tenant frozen but preserved until formal sign-off
Six phases from discovery to decommission.
- 1
Discovery and assessment
1-2 weeks
Full inventory of both tenants: users, mailboxes, OneDrive and SharePoint volumes, Teams and their owners, licensing, security posture, devices, and the third-party apps wired into each tenant. Output: the what-moves matrix for your estate and a scoped plan with a real timeline.
- 2
Mapping and target build
1-3 weeks
User-by-user identity mapping with UPN collision decisions signed off, group and permission mapping, and the target tenant built to a security baseline: Conditional Access, MFA, Intune, and Defender configured before data arrives. Coexistence (mail routing, GAL sync, B2B bridging) stood up where the timeline needs it.
- 3
Pilot wave
1 week
A representative pilot group (including at least one awkward case: a delegate-heavy assistant, a Teams power user, a mobile-only worker) is migrated end to end. The pilot validates the runbook, the tooling throughput, and the day-one user experience before the business follows.
- 4
Production waves
Size dependent
Users move in scheduled batches, grouped by department or working relationship so teams migrate together. Each wave runs pre-sync, delta sync, verification against item counts, and a per-wave report. Issues found in one wave are fixed in the runbook before the next.
- 5
Domain cutover
A weekend
The rehearsed window: domain released from the source, verified in the target, primary addresses switched, MX and Autodiscover repointed, final delta syncs run, and mail flow re-proven with live tests before Monday. Hypercare desk staffed for the first days after.
- 6
Decommission and closure
2-4 weeks after sign-off
After written sign-off, the source tenant is wound down deliberately: compliance and audit exports taken, backups confirmed, licenses cancelled, and admin access revoked. You get a closure report documenting what moved, what was archived, and what was retired.
How long a tenant migration really takes.
| Organisation size | Typical end-to-end duration | What drives it | |
|---|---|---|---|
| Up to 50 users | 3-6 weeks | Often a single wave plus one cutover weekend; discovery and comms still need their two weeks | |
| 50-250 users | 6-12 weeks | Pilot wave plus 2-4 production waves; Teams and SharePoint complexity matters more than user count | |
| 250-1,000 users | 3-6 months | Multiple waves, coexistence tooling (GAL sync, calendar sharing), and change management become mandatory | |
| Multi-entity group consolidation | 6-12 months | Each source tenant is its own mini-project; sequencing, licensing overlap, and security standardisation set the pace |
How we make a migration boring, in the good way.
Rollback and safety nets
- Source tenant preserved until written sign-offNothing is deleted at cutover. The old tenant stays intact and licensed until you confirm the new one is complete.
- Per-wave rollback criteria agreed before the wave runsIf a pilot or wave misses its verification checks, it rolls back to the source and we fix the cause before retrying.
- Independent backup of source data before migrationA point-in-time backup outside both tenants, so a mapping error can never become a data loss event.
- Item-count and spot-check verification per mailbox and siteEvery wave produces a reconciliation report, not a verbal "looks fine".
Dual-running and coexistence
- Cross-tenant mail routing during long migrationsUsers in both tenants keep emailing each other on the right addresses while waves progress.
- Shared global address list and calendar visibilityGAL synchronisation and cross-tenant free-busy so the two organisations can book meetings during coexistence.
- B2B guest bridging for Teams collaborationEntra cross-tenant access lets not-yet-migrated users work in the target Teams before their own wave lands.
- License overlap planned and budgeted, then cut at decommissionBoth tenants need licenses while both are live; the overlap window is defined up front so it does not drift.
Communications and people
- Named-user wave schedule shared with managers in advanceEvery user knows their migration date, what changes for them, and who to call.
- Day-one instructions in plain languageNew sign-in, MFA re-registration, Outlook and Teams re-profile, and phone re-setup, written for humans, not admins.
- Hypercare desk for the first days after each waveElevated support staffing when it matters, instead of a normal queue absorbing an abnormal day.
- VIP white-glove handling for executives and assistantsDelegates, shared calendars, and mobile devices for the leadership team are migrated and verified by hand.
“We had a hard TSA deadline to get 140 users off the former parent company tenant. GR mapped every user and site, ran three clean waves, and the domain cutover weekend was the least dramatic part of the whole divestiture. Their pre-migration briefing on Teams chat history meant zero surprise tickets about it on Monday.”
The questions every migration buyer asks, answered straight.
Related services and official guidance.
Microsoft 365 Tenant Setup
Building the target tenant right: domains, security baseline, and licensing from day zero.
Microsoft 365 Tenant Management
Ongoing tenant operations after the migration: governance, hygiene, and administration.
Microsoft CSP Dubai
Target tenant licensing on UAE invoicing, with the overlap period managed and then cut.
Microsoft cross-tenant migration
Microsoft's overview of workload support and planning requirements.
Cross-tenant SharePoint migration
Microsoft's guidance on supported sites, identity mapping and link behaviour.
Get a written migration assessment before you commit to anything.
Tell us the scenario and we will map both tenants, produce the what-moves matrix for your estate, and give you a wave plan with an honest timeline. If a smaller intervention solves it, we will tell you that instead.
Related Services
Explore more solutions that work great with this service
Microsoft 365
Complete Microsoft 365 setup, migration & support
M365 Administration
Expert Microsoft 365 tenant management
M365 Licensing
Optimize your Microsoft 365 licensing costs
Microsoft Entra
Identity and access management solutions
Microsoft Intune
Device management and endpoint security
Microsoft CSP
Microsoft Cloud Solution Provider for UAE businesses