What is IT AMC in Dubai and why do businesses need it?

IT AMC (Annual Maintenance Contract) in Dubai is a comprehensive service agreement for maintaining all IT equipment and systems. Businesses need IT AMC for predictable costs, 24/7 support, preventive maintenance, reduced downtime, and expert technical assistance. It's the most affordable way to ensure reliable IT operations.

How much does IT AMC cost in Dubai?

IT AMC pricing in Dubai depends on the number of devices and users, the coverage tier (remote, on-site, or hybrid), the response-time SLA, and whether servers, network, and cybersecurity are included. We scope every contract to your environment and provide a fixed monthly quote on request, so you get predictable costs with no per-incident surprises.

What is included in managed IT services in Dubai?

Our managed IT services in Dubai include complete IT infrastructure management, 24/7 monitoring and support, cybersecurity, cloud services, backup and disaster recovery, help desk support, network management, and proactive maintenance. It's a complete IT department solution with affordable monthly pricing.

What is the response time for IT support in Dubai?

GR IT Services operates a priority-tiered response SLA for managed and AMC clients: 5 minutes for P1 critical issues, 10 minutes for P2 high-priority tickets, and 30 minutes for P3 medium-priority tickets. We provide 24/7 coverage across all Dubai areas.

Which areas in Dubai does GR IT Services cover?

We provide IT AMC and managed IT services across all Dubai areas including Dubai Internet City, Business Bay, Downtown Dubai, DIFC, Dubai Marina, JLT, Sheikh Zayed Road, Dubai Silicon Oasis, Bur Dubai, and Deira. We also serve Abu Dhabi, Sharjah, Ajman, Ras Al Khaimah, and Fujairah with complete IT support.

Why is GR IT Services the best IT company in Dubai?

GR IT Services is the best IT company in Dubai because we offer affordable prices, reliable 24/7 support, a 5-minute response SLA for critical issues (10 minutes for high-priority, 30 minutes for medium), complete IT solutions, certified Microsoft Partner status, continuous service since 2022, and 68+ satisfied clients. We provide the best IT AMC and managed IT services in Dubai with guaranteed SLA.

Microsoft 365 Tenant to Tenant Migration, UAE

Merging, splitting, or rebranding? We move your Microsoft 365 tenant without losing your business.

Tenant to tenant migration moves mailboxes, OneDrive, SharePoint, Teams, and identities from one Microsoft 365 tenant to another. It is the IT backbone of every merger, divestiture, and rebrand. We plan the mapping, run the waves, execute the domain cutover, and tell you honestly what moves cleanly, what needs third-party tooling, and what does not move at all.

Plan your migration What moves, what does not

Microsoft

365

Cloud Solution Partner

4Migration scenarios
WavedBatch approach
ZeroMail loss target
UAEData region option

Four reasons tenants merge or split

Which migration scenario is yours?

Every tenant to tenant project is one of four shapes. The shape decides the identity strategy, the coexistence period, and how the domain cutover is sequenced.

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

Outcome

2 into 1

Tenant consolidation

What we migrate

Every workload in the tenant, each with its own method.

A tenant migration is really nine coordinated migrations that must land in the right order. Identity comes first, data follows in waves, and the domain moves last. Here is each piece and how we handle it.

Entra ID identities and groups

Target accounts pre-created and mapped user by user, with UPN collision resolution agreed in writing. Groups, distribution lists, and admin roles rebuilt to a documented standard. Passwords never migrate between tenants, so credential issuance and MFA re-registration are planned as a user journey, not an afterthought.

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 for every user pre-synced to the target before their wave, with a final delta pass at cutover. Version history and sharing inside the organisation carry over; links shared to external parties are inventoried and re-shared after the move.

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, channels, files, and channel conversations migrated with third-party tooling. Private 1:1 and group chat history is the industry-wide hard part: there is no native migration path, and even the best tools re-import it with reduced fidelity. We tell users exactly what to expect before day one.

Devices and Intune

Entra-joined and Intune-enrolled devices cannot be moved between tenants; they are re-enrolled. We re-register Autopilot hardware hashes to the target, rebuild compliance and configuration profiles, and schedule device resets around each user wave so nobody loses a working laptop mid-week.

Domain and mail flow cutover

The custom domain can exist in only one tenant at a time. We run the removal, re-verification, and MX, SPF, DKIM, and DMARC repoint as a rehearsed weekend runbook with rollback criteria, so the routing gap stays inside the window and no mail is lost.

Licensing transition

Licenses do not transfer between tenants. We plan the subscriptions for the target tenant, the paid overlap period while both tenants run, and the source cancellation at decommission. As a Microsoft CSP we can provision the target licensing on UAE invoicing and trim the overlap to the minimum.

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.

The honest matrix

What moves, what does not, and how.

Microsoft provides native cross-tenant migration for mailboxes and OneDrive, with SharePoint migration expanding under the same cross-tenant framework. Everything else relies on third-party migration tooling or manual rebuild. This table is the truth we plan around; any provider promising a lossless move of everything is not being straight with you.

	Workload	Moves?	How it moves
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	Sharing links to the old tenant URL break; version history moves, but re-share is needed for externally shared files
SharePoint sites	Yes, with planning	Cross-tenant SharePoint migration or third-party tooling, site by site	Site URLs change to the new tenant, so bookmarks, links in documents, and integrations need updating; complex customisations must be rebuilt
Teams: teams and channel files	Yes, mostly	Third-party tooling recreates teams, channels, and moves the SharePoint files behind them	Tabs, apps, and connectors usually need reconfiguring; channel message history migrates with formatting limits
Teams: private 1:1 and group chats	Partially, industry-wide limitation	No native migration; some third-party tools can export and re-import chat threads with reduced fidelity	Expect imported history to look different (timestamps, authorship rendering) or to arrive as an archive; plan user comms around this honestly
Entra ID identities	Recreated, not moved	Accounts are pre-created in the target tenant and mapped to source users	Passwords never migrate; users set new credentials and re-register MFA in the target tenant
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	Licenses cannot transfer between tenants; the target tenant needs its own subscriptions	Plan a paid overlap period covering both tenants during migration, then cancel the source at decommission
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

Why GR for tenant migration

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.

Who needs this

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.

The domain cutover, explained

Why the domain move is a scheduled event, and how we run it.

A custom domain such as yourcompany.ae can be verified in only one Microsoft 365 tenant at a time. To move it, it must be fully removed from the source tenant before the target tenant can use it. That creates a cutover window, usually run over a weekend, and everything about the migration plan is built to make that window short and reversible.

01
Before· 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
02
The 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
03
After· 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

How the migration runs

Six phases from discovery to decommission.

The sequence is fixed because the dependencies are real: you cannot map what you have not discovered, you cannot wave what you have not piloted, and you cannot decommission what you have not verified.

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.

Timeline honesty

How long a tenant migration really takes.

The data copy is rarely the bottleneck. Discovery, mapping decisions, license procurement, user communications, and the coexistence period are what set the calendar. These are honest planning ranges from real projects, not best-case marketing numbers.

	Organisation size	Typical end-to-end duration
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

Risk controls

How we make a migration boring, in the good way.

A tenant migration touches every user, every mailbox, and every file. The controls below are non-negotiable on our projects because each one exists to catch a failure mode we have seen in the wild.

Rollback and safety nets

Source tenant preserved until written sign-off
Nothing 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 runs
If 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 migration
A 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 site
Every wave produces a reconciliation report, not a verbal "looks fine".

Dual-running and coexistence

Cross-tenant mail routing during long migrations
Users in both tenants keep emailing each other on the right addresses while waves progress.
Shared global address list and calendar visibility
GAL synchronisation and cross-tenant free-busy so the two organisations can book meetings during coexistence.
B2B guest bridging for Teams collaboration
Entra 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 decommission
Both 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 advance
Every user knows their migration date, what changes for them, and who to call.
Day-one instructions in plain language
New 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 wave
Elevated support staffing when it matters, instead of a normal queue absorbing an abnormal day.
VIP white-glove handling for executives and assistants
Delegates, 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.”

IT Director

Divested business unit · Trading group, Dubai

140 users carved out ahead of the TSA deadline

Tenant migration FAQ

The questions every migration buyer asks, answered straight.

Mostly no, briefly yes. Data pre-syncs in the background while users keep working in the source tenant, so the migration itself is invisible. The exception is the domain cutover window, usually a weekend, when mail routing switches and users re-profile Outlook, Teams, and mobile devices. Inbound email sent during the switch is queued and retried automatically by sending mail servers, so a well-run cutover loses no mail. Users feel the change on the first morning after their wave, not during it.

Private 1:1 and group chat history has no native Microsoft migration path between tenants, and that is an industry-wide limitation, not a vendor excuse. Some third-party tools can export and re-import private chats, but with reduced fidelity: threads may appear as imported archives, and formatting, reactions, and timestamps can render differently. Channel conversations inside teams migrate more completely via tooling. We state exactly what your users will and will not see before the project starts, in writing.

A custom domain can be verified in only one tenant at a time, so there is a window where it leaves the source and joins the target. During that window, mail to your domain cannot be delivered instantly, but internet mail servers queue and retry undeliverable mail, typically for 24 hours or more, so messages arrive once MX records point at the target. We lower DNS TTLs in advance to shrink the gap and run live mail-flow tests before the window closes.

They sign in with their new credentials (passwords never migrate between tenants), re-register MFA, and let Outlook and Teams build fresh profiles against the target tenant. Mail, calendar, and OneDrive files are already there. Mobile devices need the account re-added. Old sharing links pointing at the previous tenant stop working and need re-sharing. We put all of this in a one-page day-one guide per user and staff a hypercare desk for the first days.

Yes, for the overlap period, and anyone who tells you otherwise is hiding it in the fine print. Microsoft licenses cannot transfer between tenants, so the target needs its own subscriptions while the source stays licensed until decommission. We plan the overlap window explicitly, keep it as short as the wave schedule allows, and as a CSP we can align the source cancellation to the decommission date so the overlap does not quietly become permanent.

Typically 6-10 weeks end to end: one to two weeks of discovery and mapping, a week to build and baseline the target tenant, a pilot wave, two to three production waves, then the domain cutover weekend and hypercare. The data copy itself is rarely the constraint; decision-making on mapping, license procurement, and user communications set the calendar. A migration squeezed below that usually pays for it in day-one chaos.

Sometimes, yes. Entra cross-tenant access, B2B collaboration, GAL synchronisation, and cross-tenant calendar sharing let two tenants coexist as one working organisation, and for loosely coupled group structures that can be the right answer. It costs you duplicated administration, two security postures to maintain, and a messier user experience. We assess coexistence honestly as an alternative before recommending a migration, because it is sometimes the cheaper correct answer.

Data residency for the target tenant is set by the country selected when it is created, and Microsoft operates a UAE data centre region for Microsoft 365. A migration into a new tenant is therefore the natural moment to land Exchange, SharePoint, and OneDrive data in the UAE region if residency matters for your regulator or contracts. For an existing target tenant in another region, we tell you what its residency actually is before you commit, not after.

Both, chosen per workload. The native Microsoft cross-tenant migration covers mailboxes and OneDrive well, and cross-tenant SharePoint capability sits in the same framework. Teams content, chat reconstruction, Planner, and complex permission fidelity need commercial third-party migration tooling; several mature products exist and we select based on your workload mix rather than pushing one vendor. Tooling licenses are itemised in the proposal, never hidden.

Devices joined to Entra ID in the source tenant and managed by Intune cannot be transferred; they must be re-enrolled into the target tenant. For Windows devices this usually means an Autopilot reset with the hardware hash re-registered to the target, scheduled around each user wave. Mobile devices re-add the work account and re-enrol into management. We sequence device work with the user waves so nobody is left without a working machine.

Purview audit logs, eDiscovery cases, retention state, and sign-in history stay with the source tenant, so anything your legal or compliance team needs is exported before decommission. Licenses do not transfer. Power Automate flows, Power Apps, Forms, and Bookings need redeployment or manual recreation. Third-party app integrations wired to the old tenant IDs must be reconnected. The discovery phase inventories all of this so nothing surfaces as a surprise in week six.

Yes, and the plan assumes it. Background syncs run continuously, wave cutovers land on evenings or weekends, and the domain cutover is a weekend event with engineers on the runbook through the window. The goal is that the working week never meets the migration mid-move.

Every wave has pre-agreed rollback criteria, and the source tenant remains intact and licensed until you sign off completion, so reverting a wave means pointing users back at a tenant that never stopped existing. An independent backup taken before migration sits outside both tenants as the final safety net. In practice the pilot wave exists precisely to surface problems while they are cheap.

Related Microsoft services

Before, during, and after the move.

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.

Merging, splitting, or rebranding?

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.

Plan your migration See our Microsoft services

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

Merging, splitting, or rebranding? We move your Microsoft 365 tenant without losing your business.

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	Sharing links to the old tenant URL break; version history moves, but re-share is needed for externally shared files
SharePoint sites	Yes, with planning	Cross-tenant SharePoint migration or third-party tooling, site by site	Site URLs change to the new tenant, so bookmarks, links in documents, and integrations need updating; complex customisations must be rebuilt
Teams: teams and channel files	Yes, mostly	Third-party tooling recreates teams, channels, and moves the SharePoint files behind them	Tabs, apps, and connectors usually need reconfiguring; channel message history migrates with formatting limits
Teams: private 1:1 and group chats	Partially, industry-wide limitation	No native migration; some third-party tools can export and re-import chat threads with reduced fidelity	Expect imported history to look different (timestamps, authorship rendering) or to arrive as an archive; plan user comms around this honestly
Entra ID identities	Recreated, not moved	Accounts are pre-created in the target tenant and mapped to source users	Passwords never migrate; users set new credentials and re-register MFA in the target tenant
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	Licenses cannot transfer between tenants; the target tenant needs its own subscriptions	Plan a paid overlap period covering both tenants during migration, then cancel the source at decommission
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

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

Sharing links to the old tenant URL break; version history moves, but re-share is needed for externally shared files

SharePoint sites

Yes, with planning

Cross-tenant SharePoint migration or third-party tooling, site by site

Site URLs change to the new tenant, so bookmarks, links in documents, and integrations need updating; complex customisations must be rebuilt

Teams: teams and channel files

Yes, mostly

Third-party tooling recreates teams, channels, and moves the SharePoint files behind them

Tabs, apps, and connectors usually need reconfiguring; channel message history migrates with formatting limits

Teams: private 1:1 and group chats

Partially, industry-wide limitation

No native migration; some third-party tools can export and re-import chat threads with reduced fidelity

Expect imported history to look different (timestamps, authorship rendering) or to arrive as an archive; plan user comms around this honestly

Entra ID identities

Recreated, not moved

Accounts are pre-created in the target tenant and mapped to source users

Passwords never migrate; users set new credentials and re-register MFA in the target tenant

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

Licenses cannot transfer between tenants; the target tenant needs its own subscriptions

Plan a paid overlap period covering both tenants during migration, then cancel the source at decommission

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

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

Why the domain move is a scheduled event, and how we run it.

	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

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

Merging, splitting, or rebranding? We move your Microsoft 365 tenant without losing your business.

Which migration scenario is yours?

Two companies, two tenants, one future tenant.

Every workload in the tenant, each with its own method.

Entra ID identities and groups

Exchange Online mailboxes

OneDrive for Business

SharePoint Online sites

Teams, with the truth about chats

Devices and Intune

Domain and mail flow cutover

Licensing transition

Coexistence for long migrations

What moves, what does not, and how.

Four reasons UAE organisations hand us the riskiest week in IT.

Honest scoping before you spend

Named UAE engineers through cutover weekend

Security baseline built into the target, not bolted on

CSP licensing under the same roof

The UAE situations that put tenant migration on the board agenda.

Acquisitions and mergers

Divestitures under TSA deadlines

Free-zone restructures

Family and holding groups consolidating

Regulated entities fixing data residency

Rebrands that need a clean break

Why the domain move is a scheduled event, and how we run it.

Pre-stage everything that does not need the domain.

Release, verify, rebind. Usually inside a weekend.

Monday morning is the real test. We are on it.

Six phases from discovery to decommission.

Discovery and assessment

Mapping and target build

Pilot wave

Production waves

Domain cutover

Decommission and closure

How long a tenant migration really takes.

How we make a migration boring, in the good way.

Rollback and safety nets

Dual-running and coexistence

Communications and people

The questions every migration buyer asks, answered straight.

Will users have downtime during the migration?

Does Teams chat history really not migrate?

What happens to mail flow during the domain cutover?

What do users actually experience on day one?

Do we pay for licenses in both tenants during the migration?

How long does a migration take for around 100 users?

Can we keep both tenants and not migrate at all?

Where does our data live after the migration? Can we choose the UAE?

Do you use Microsoft native tools or third-party migration software?

What happens to our laptops and mobile devices?

What does not come with us at all?

Can you run the migration outside UAE business hours?

What if something goes wrong mid-migration?

Before, during, and after the move.

Microsoft 365 Tenant Setup

Microsoft 365 Tenant Management

Microsoft CSP Dubai

Get a written migration assessment before you commit to anything.

Related Services

Microsoft 365

M365 Administration

M365 Licensing

Microsoft Entra

Microsoft Intune

Microsoft CSP

Merging, splitting, or rebranding? We move your Microsoft 365 tenant without losing your business.

Which migration scenario is yours?

Two companies, two tenants, one future tenant.

Every workload in the tenant, each with its own method.

Entra ID identities and groups

Exchange Online mailboxes

OneDrive for Business

SharePoint Online sites

Teams, with the truth about chats

Devices and Intune

Domain and mail flow cutover

Licensing transition