An acquisition, a carve-out, or a change of name. We move the tenant without the business noticing.

Largely no, briefly yes. Data syncs across in the background while everybody carries on working in the old tenant, so the migration itself is invisible to them. The exception is the cutover window, normally a weekend, when mail routing switches and people rebuild their Outlook, Teams and phone profiles. Anything sent to you during the switch queues on the sending server and retries automatically, which is why a well-run cutover loses nothing. What people experience is the first morning after their wave, not the migration itself.

Private chat history, whether one to one or in a group, has no native path between tenants at all. That is a limitation across the whole industry rather than an excuse from any vendor. Some third party tools will export and reimport private chats, at noticeably reduced fidelity: threads can appear as imported archives, and formatting, reactions and timestamps often render differently. Channel conversations inside teams come across far more completely. Before the project starts you get, in writing, exactly what your people will and will not see afterward.

Because a domain can only be verified in one tenant at a time, there is unavoidably a window where it has left one and not yet joined the other. Through that window mail to your domain cannot be delivered immediately. What happens instead is that the sending servers queue it and keep retrying, typically for a day or more, so it arrives as soon as the routing records point at the new tenant. We drop the DNS record lifetimes in advance to keep the gap short, and run live mail flow tests before the window is declared closed.

They sign in with new credentials, since passwords never travel between tenants, register their second factor again, and let Outlook and Teams build fresh profiles against the new tenant. The mail, the calendar and the OneDrive files are already sitting there waiting. Phones need the account adding again. Any old sharing link pointing at the previous tenant stops working and has to be reissued. All of that goes onto a single page per person, and an extra support desk is staffed for the first few days.

Yes, for the overlap period, and anybody telling you otherwise has buried it somewhere in the fine print. Licenses cannot move between tenants, so the destination needs its own subscriptions while the source stays licensed right up to decommission. The overlap is planned explicitly, kept no longer than the wave schedule genuinely requires, and the source cancellation is tied to the decommission date so that the overlap never quietly turns into a permanent arrangement.

Six to ten weeks end to end is normal. One or two weeks of discovery and mapping, a week to build and baseline the destination, a pilot wave, then two or three production waves, then the cutover weekend and the support cover after it. Copying the data is almost never the bottleneck. What sets the calendar is how long decisions take on mapping, how long licenses take to procure, and how long the communications need to land. Squeeze it below that and you pay for it on day one instead.

Sometimes that is genuinely the right answer. Cross-tenant access, guest collaboration, directory synchronization and shared calendars can let two tenants operate as one working company, and for a loosely coupled group structure that can be exactly right. What it costs you is administration done twice, two security postures to keep current, and a user experience that is never quite clean. Coexistence gets assessed honestly as an alternative before any migration is recommended, because it is occasionally both cheaper and correct.

Structurally yes: moving from commercial Microsoft 365 into a GCC High tenant is a tenant-to-tenant migration, with identity recreation, data movement, device re-enrollment, and a domain cutover. Two things differ. First, tooling: migrations into government cloud environments have their own supported paths and constraints, so the tooling selection is part of scoping, not an assumption. Second, feature parity: some commercial features behave differently or arrive later in GCC High, so the discovery phase includes a workload-by-workload check of what your business relies on. If CMMC is the driver, we scope the migration against your compliance advisor's scoping of what actually needs to live in the enclave.

Both, chosen workload by workload. The native cross-tenant capability handles mailboxes and OneDrive well, and SharePoint sits in the same framework. Teams content, rebuilding chat, Planner and anything requiring faithful permission handling all need commercial tooling. Several mature products exist and the choice follows your particular mix of workloads rather than whichever vendor we happen to resell. Tooling licenses appear as line items in the proposal and are never folded into something else.

A device joined to the source tenant and managed from it cannot be transferred. It has to be enrolled again on the other side. For a Windows machine that normally means an Autopilot reset with the hardware hash registered against the destination, scheduled around that person wave. Phones simply have the work account added again and re-enroll into management. Device work is sequenced alongside the waves so that nobody ends up without a working machine.

Audit logs, discovery cases, retention state and sign-in history all stay behind in the source tenant, so anything legal or compliance needs, including anything under litigation hold, gets exported before decommission. Licensing does not travel. Automation flows, low-code applications, Forms and Bookings all need redeploying or recreating by hand. Any third party integration wired to the old tenant identifiers has to be reconnected. Discovery inventories every bit of this at the start, precisely so none of it surfaces as a surprise in week six.

Yes, and the plan is built on that assumption. Background syncing runs continuously, wave cutovers land in the evening or at the weekend, and the domain cutover is a weekend event with engineers working the runbook through the whole window. The aim is that the working week and the migration never meet.

Every wave carries rollback criteria agreed in advance, and the source tenant stays intact and licensed until you sign off, so reversing a wave means pointing people back at a tenant that never went anywhere. An independent backup taken before any of it starts sits outside both tenants as the last resort. In practice, the pilot wave exists specifically so that problems surface while they are still cheap to fix.