Assess
Inventory tenants, domains, identities, mailboxes, content, teams, applications, volume, and manual dependencies.
Microsoft 365 tenant-to-tenant
Microsoft 365 tenant-to-tenant migration under one program.
Microsoft 365 tenant-to-tenant migration connects tenant readiness, identity mappings, assessed workload scopes, baseline and delta passes, cutover gates, reconciliation, and sign-off. Entra identities, Exchange mailboxes, SharePoint and OneDrive content, Teams structures, and conditional Teams messages each follow the service that owns them. Run it as one Microsoft 365 migration tool for the whole program — an Office 365 tenant to tenant migration executed workload by workload rather than as a single opaque copy. Microsoft 365 was formerly branded Office 365, so teams evaluating an Office 365 migration tool for O365 tenant to tenant migration are looking at the same program.
Supported · Multi-workload Scoped deliveryExchange Online mailbox content and SharePoint/OneDrive content are supported within documented boundaries. Teams structure is supported reconstruction; channel messages require Microsoft protected-API approval. Identity and manual remediation must be ready first.
Program control
Connect workload jobs to shared migration waves.
A tenant move is governed at program level but executed at workload level. BridgeAD records source and destination connections, scope definitions, mapped identities, workload jobs, stage outcomes, cutover evidence, and sign-off so dependencies and unresolved outcomes remain visible.
- Source and destination tenant and workload connection health
- Assessment-backed object, mailbox, site, drive, and team scope
- Cross-workload identity and destination mappings
- Pipeline stages linked to Exchange, SharePoint, and Teams jobs
- Per-workload retries, deltas, reconciliation, and validation
- Audit, exception, completion, and sign-off evidence
Tenant consolidation / Wave 03Representative operational view
4Workloads active
82%Identity ready
11Open decisions
Exchange baseline420 mailboxes / delta state retained
RunningSharePoint scopeSharing-link remediation owner required
ReviewTeams reconstructionWaiting for backing sites and mapped guests
GatedIllustrative values; the interface displays customer-specific migration data.
Workstream scope
Assign every artifact to an owning service.
The program plan states both the automated path and the work that remains with Microsoft-native administration, an application owner, an endpoint team, or another approved tool.
| Workstream | Status | BridgeAD path | Separate decision |
|---|---|---|---|
| Microsoft Entra ID | Supported · core | Create or update supported users, groups, devices, and membership with immutable-ID and UPN collision protection; migrate member users and static security groups tenant-to-tenant with UPN transformation and re-run attribute refresh. | Sync authority, licensing, roles, Conditional Access, MFA, guest governance, application consent, and dynamic-membership rules. |
| Google Workspace directory | Supported · route | Preview and sync users and groups into Entra ID, or provision them directly into on-premises AD through an assigned agent. | Requires domain-wide delegation. Source passwords, Gmail, Drive, and Calendar content are not part of directory migration. |
| Exchange Online | Supported | Migrate mail, folder hierarchy, owned calendars, contacts, tasks, optional rules, selected settings, permissions, delta state, and cutover evidence. | Archives, public folders, delegation, on-premises onboarding, DNS ownership, and final mail-flow changes. |
| SharePoint and OneDrive | Supported · scope | Transfer supported files, folders, bounded versions, metadata, mapped permissions, and generic lists with delta and cutover passes. | Pages, custom forms, workflows, apps, sharing links, Purview controls, and tenant governance. |
| Microsoft Teams structure | Supported · Reconstructed | Create team and channel structure, mapped membership, supported settings, tabs, and tags through Graph. | Guests, shared-channel trust, apps, secrets, connectors, policies, personal chats, and Teams Phone. |
| Teams channel messages | Conditional | Import posts and replies with original author and timestamp through Microsoft migration mode. | `Teamwork.Migrate.All` approval, new destination teams, attachments through SharePoint, and no reaction fidelity. |
| Teams private chats | Conditional | Re-create 1:1 and group chats with mapped members and deliver full history — authors, timestamps, rich content, and inlined images — as self-contained HTML transcripts in each user's destination OneDrive. | Microsoft protected-API approval (`Chat.Read.All`) on the source; native in-chat history injection waits on Microsoft's cross-tenant chat API. |
| Applications and devices | Controlled pilot · Mixed | Recreate selected app definitions and optional service principals; create supported Entra device records; conditionally recreate selected Intune policy definitions. | Credentials, consent, assignments, integrations, device join, enrollment, certificates, apps, scripts, and compliance activation. |
Inside the application
Each workstream has controls, live state, and an output.
Operators do not submit a single tenant-wide copy request. They open the owning workspace, select validated connections and assessed scope, preview write behavior, start a bounded job, and review service-specific evidence. Teams comparing Office 365 migration tools should expect this separation: an Office 365 data migration tool must expose supported, conditional, and manual boundaries rather than imply that every tenant artifact moves through one opaque job. BridgeAD applies that same standard to its Office 365 migration software workflow.
SelectNamed source and destination connections, users, groups, mailboxes, sites, teams, or chats.
PreviewUPN transformations, mappings, collisions, prerequisites, unsupported items, and update mode.
RunSeparate background jobs with frozen options, safe retry state, and workload-owned execution.
MonitorCurrent item, processed and failed counts, warnings, cancellation, and terminal summaries.
CloseValidation, reconciliation, transcripts, exports, migration certificates, audit, and sign-off.
Dependency sequence
Prepare identity before releasing content and collaboration.
Exact overlap depends on the coexistence plan, but dependent workload jobs should not assume that destination identities, groups, mailboxes, drives, sites, or guest trust will appear later.
Prepare identity
Verify domains and sync authority; create or map users and groups; provision licenses, mailboxes, OneDrive, and consent.
Baseline content
Start mailbox and SharePoint/OneDrive baseline passes while source services remain active.
Reconstruct collaboration
Create Teams structures after identities and backing targets are ready; coordinate files, meetings, and conditional messages.
Cut over and prove
Freeze agreed changes, run final deltas, validate DNS and service access, reconcile outcomes, remediate, and sign off.
Program prerequisites
Resolve tenant-wide decisions before workload jobs start.
Most avoidable migration failures come from identity, domain, consent, licensing, destination provisioning, and ownership assumptions rather than from byte transfer itself.
Identity and domains
- Verified domains, UPN and alias rules, and sync authority approved
- Immutable-ID, destination object, group, and guest mappings validated
- Domain removal, attachment, and DNS change sequence owned
Consent and provisioning
- Graph applications and least-privilege roles consented per workload
- Licenses, mailboxes, OneDrive accounts, and destination sites provisioned
- Protected-API eligibility and service limits checked
Cutover and acceptance
- Baseline, delta, freeze, cutover, support, and rollback owners named
- Manual application, sharing, guest, meeting, and device tasks assigned
- Reconciliation thresholds and business sign-off criteria agreed
Cutover control
Use evidence from each service at the decision gate.
A green program status requires more than completed jobs. The cutover owner should know what changed, what is unresolved, what cannot be rolled back automatically, and which user actions are still required.
| Gate | Evidence | Decision |
|---|---|---|
| Identity ready | Mapped users and groups, destination licenses, mailbox and drive provisioning, guest and application exceptions, privileged-access checks. | Allow dependent workload baselines and collaboration reconstruction. |
| Baseline accepted | Mailbox, file, list, and structure outcomes; skipped or unsupported items; delta state retained; service-limit errors reviewed. | Schedule final delta and user freeze only when remediation fits the cutover window. |
| Source freeze active | Approved change restriction, support communication, final-delta start, DNS owner available, rollback threshold monitored. | Proceed with final synchronization and tenant/domain changes or stop. |
| Destination service validated | Sign-in, mail flow, calendars, content access, Teams membership, links, apps, permissions, and representative user tests. | Release users, continue remediation, or invoke the owned recovery plan. |
| Program closed | Reconciliation exports, failures and skips dispositioned, manual tasks accepted, audit retained, and business owner sign-off recorded. | Close the wave and approve the next cohort or decommission plan. |
Program boundaries
Keep tenant configuration and user experience in scope.
Moving supported content does not reproduce every tenant-level policy, application relationship, sharing decision, meeting artifact, endpoint state, or compliance control.
Automated workload scope
- Supported Entra directory objects and mappings
- Exchange mailbox and SharePoint/OneDrive content
- Teams reconstruction and conditional channel messages
Tenant and API dependencies
- Protected Teams message APIs and Graph beta policies
- Licensing, service limits, tenant state, and destination provisioning
- Domain, DNS, sync, cross-tenant access, and coexistence state
Activation and fidelity
- Secrets, certificates, consent, apps, connectors, and assignments
- Sharing links, Purview controls, chats, join URLs, delegates, and archives
- Device re-enrollment, endpoint configuration, and user communications
Frequently asked questions
Tenant-to-tenant migration questions
Can BridgeAD move Exchange and SharePoint content between Microsoft 365 tenants?
Yes, within the documented Exchange Online and SharePoint/OneDrive scopes. Exchange uses a Graph-based mailbox content path; SharePoint and OneDrive use assessed Graph drive and supported-list transfer. Each has explicit exclusions and validation requirements.
Does one job migrate all Teams artifacts?
No. BridgeAD reconstructs supported team and channel structure through Teams Graph APIs. Channel messages use a conditional Microsoft-native migration path. Files and recordings move through SharePoint or OneDrive; calendar meetings move through Exchange; apps and tenant configuration require remediation.
Can a source domain move before all content is complete?
Domain sequencing is an engagement decision tied to identity, mail routing, aliases, applications, and coexistence. Baseline content can often run earlier, but final domain and DNS changes require a documented freeze, final delta, validation, and recovery plan.
How are permissions preserved?
Supported permissions are applied only when source principals resolve through approved destination mappings. Unresolved identities, sharing links, guest state, application assignments, and tenant governance are reported or assigned to manual remediation.
What proves that the migration is complete?
Completion combines workload reconciliation, failed and skipped item disposition, destination service checks, manual remediation acceptance, audit evidence, and business sign-off. A job reaching a terminal state is not sufficient on its own.
Start with the owning workload
Inspect exact capability before approving program scope.
The workload directory links each public claim to its prerequisites, workflow, validation approach, and exclusion boundary.