Kloudeal Journal · Business guide
A tenant-to-tenant migration service must define the information and services being moved and how the change will be verified. This guide explains what to request during assessment, proposal and handover for a Microsoft 365 consolidation or separation project.
Scope, exclusions and responsibilities.
Preparation, pilot, transfer and service transition.
Agreed testing, documentation and support.
Contents of this guide
Service overview
We assess source and destination tenants before migration; define what moves, what is excluded and what requires manual review; work with Exchange Online, OneDrive, SharePoint, Microsoft Teams, domains, users, permissions and licences; review DNS, UPN, MX, SPF, DKIM, DMARC, Autodiscover and domain dependencies; select Microsoft native tools or specialist solutions such as Quest, BitTitan, Cloudiway or ShareGate according to the circumstances; and include subsequent validation and assistance to reduce post-cutover incidents.
What to agree before commissioning a tenant-to-tenant migration
A tenant-to-tenant migration service should describe the destination experience for each user group. The client needs to know which account employees will use, where they will find email and documents and which changes affect devices or applications. This is more precise than a general promise to move Microsoft 365 without distinguishing its components.
In a business separation, for example, not all data belonging to a person or team necessarily moves. The business must decide which information belongs in the new environment and which collaboration with the previous organisation remains necessary. The provider turns these decisions into a technical plan, while information and project owners approve the scope.
The proposal should identify dependencies that may alter the schedule: domain release, authorised access to both tenants, identity preparation, tool compatibility and validator availability. Record an owner and closure condition for each dependency. This prevents the cutover date becoming a substitute for decisions that have not yet been made.
How to assess the quality of handover and support
Service quality is demonstrated through results tied to scope. Each workload needs transfer reports, explained differences and functional tests. A successful tool status alone does not establish that people can open a delegated mailbox, work on a site or use an application with the new account.
Support needs an agreed channel and coverage for the initial period of use. Classify incidents by impact and assign them to the appropriate resolver, distinguishing project errors from additional requirements. At closure, deliver decisions, relevant configuration, outstanding matters and operational responsibilities so the client’s team has sufficient information to administer the destination.
How to prepare acceptance with departmental owners
Functional owners should participate before cutover, while tests and scope can still be adjusted. They do not need to validate internal tool parameters; they need to confirm that users can perform agreed actions. For administration, this might mean opening a shared mailbox and replying to a supplier; for a project team, opening documents and working with an external collaborator. Record each case with the accounts and resources to be used.
The acceptance report should explain differences users will notice. A replacement meeting invitation, a link requiring an update or an application needing another sign-in should not become a first-day surprise. Where the pilot identifies these changes, prepare instructions and owners. If an essential function is affected without an accepted alternative, review the decision to proceed before expanding the batch.
This agreement also supports consistent incident closure. The technical team demonstrates correction by repeating the test, and the department confirms the process outcome. Document the reason and follow-up for accepted exceptions, distinguishing them from failures that still prevent handover being considered complete.
What a Microsoft 365 tenant-to-tenant migration service involves
A Microsoft 365 tenant is the environment in which an organisation manages users, licences, domains, email, files, Teams, SharePoint, OneDrive, policies and cloud services. A tenant-to-tenant migration moves some or all of those users, data and services from a source tenant to a destination tenant. It can affect users and groups; Exchange Online mailboxes; calendars, contacts and shared mailboxes; user OneDrive accounts; SharePoint Online sites and libraries; Teams teams, channels, files and permissions; custom domains; licences and active services; Microsoft Entra ID; enterprise applications; Power Platform, Power BI and connectors; and security and compliance configurations.
Microsoft documents these migrations for mergers, acquisitions, divestitures and internal reorganisations. Its official documentation covers planning Microsoft 365 tenant-to-tenant migrations.
When a business needs to migrate between tenants
Tenant migrations commonly arise when a company’s structure changes or its Microsoft 365 environment needs consolidation. Mergers and acquisitions. When one business acquires another, users, email, files, Teams and collaboration may need integration into the main corporate tenant. Business or business-unit separations. A division that is separated, sold or becomes independent may need its own tenant with separate users, data and domains.
Tenant consolidation. Some organisations have several tenants following growth, acquisitions, subsidiaries or historical decisions. Consolidation may simplify administration, licensing and governance. Domain or brand changes. Rebranding can involve new domains, email addresses, UPN changes, DNS adjustments, signatures, applications and internal communication. Internal reorganisation. Migrations may also result from structural changes, centralised IT, compliance needs, service integration or reduction of duplicate environments.
What can be migrated in Microsoft 365
Scope varies by business. Before migration, we review services actually used, data volumes and the limitations of each workload.
| Area | What can be included | What we review beforehand |
|---|---|---|
| Users and groups | Users, Microsoft 365 groups, security groups, distribution lists and owners. | UPNs, duplicates, inactive users, hybrid identity, roles and licences. |
| Exchange Online | Mailboxes, calendars, contacts, online archives, shared mailboxes, rooms and resources. | Domains, MX records, aliases, delegations, rules, connectors, sizes and permissions. |
| OneDrive | Users’ personal work files and shared content. | Volume, permissions, links, inactive users, synchronisation and retention. |
| SharePoint Online | Sites, libraries, documents, permissions, structure and metadata according to the tool. | Obsolete sites, owners, unique permissions, versions, links and external access. |
| Microsoft Teams | Teams, channels, members, owners, files and some conversations according to the tool. | Private channels, guests, chats, tabs, apps, Planner, OneNote and permissions. |
| Domains | Custom domains, UPNs, email, DNS, MX records, SPF, DKIM and DMARC. | Dependencies, objects using the domain, cutover window and validation. |
| Applications | Enterprise applications, SSO, app registrations, connectors and automation. | API permissions, secrets, certificates, owners, Power Platform and dependencies. |
Exchange Online: email, calendars and shared mailboxes. Email is often the most visible service for users. We therefore review mailboxes, calendars, contacts, shared mailboxes, rooms, resources, delegations, permissions, rules, connectors and DNS. Microsoft documents cross-tenant mailbox migration, including requirements, licensing and configuration. OneDrive: personal and shared files. OneDrive needs particular attention because personal work files are often shared with colleagues or external users. We review owners, permissions, links, inactive users, volumes and information subject to retention.
Microsoft documents cross-tenant OneDrive migration and its requirements. SharePoint Online: sites, libraries and permissions. SharePoint often contains critical departmental, project and team documentation. Before migration, review active sites, permissions, critical libraries and content suitable for clean-up. In some scenarios, Microsoft native capabilities can be assessed for cross-tenant SharePoint migration.
Microsoft Teams: collaboration, channels and files. Teams depends on SharePoint, OneDrive, Exchange Online, Microsoft 365 groups, applications, permissions and guests. It therefore needs more than a simple team copy. We review active teams, owners, members, guests, private and shared channels, files, conversations, tabs, Planner, OneNote, applications and user expectations. Domains, UPNs and DNS. Custom domains are a critical migration component. They affect sign-in, email, Autodiscover, SPF, DKIM, DMARC, applications, Outlook and mobile devices.
Before cutover, we review objects using the domain, how it will be released from the source, when it will be added to the destination and which DNS records must change.
Promises to avoid in a tenant-to-tenant migration
A professional migration service must explain what is possible and what depends on tools, licences, Microsoft limits, permissions, APIs and environment configuration. We avoid absolute promises of “no data loss”, “zero interruption” in every scenario, identical results for everything, complete migration of every Teams chat, unchanged operation of all applications, working historical links or preserved permissions without review.
The appropriate approach is to define scope, validate tools, run a pilot, communicate limitations and verify outcomes with users and critical services.
Our migration process, step by step
Every business has a different environment. We organise migration into phases, adapting the plan to tenant size, services used and risk level.
1. Initial environment assessment
Before proposing a tool or cutover date, we review the source environment and project objective. We analyse user numbers, custom domains, current licences, active and inactive users, user and shared mailboxes, rooms and resources, email and online archive volumes, OneDrive accounts, SharePoint sites, Teams teams and channels, external guests, sensitive permissions, connected applications, Power Platform, Power BI, automation and hybrid identity where on-premises Active Directory exists.
This phase provides a clearer view of scope, risks and the actual project effort.
2. Destination tenant preparation
Data copying should start only once the destination tenant is prepared. We can help prepare users and groups, required licences, temporary or final domains, baseline Exchange Online settings, initial security policies, Microsoft Entra ID, Conditional Access, MFA and administrator accounts, SharePoint and OneDrive, Teams and required policies, and administrative permissions for migration tools.
We also review whether the primary domain must move during cutover or whether temporary domains are appropriate until the final change.
3. Tool and strategy selection
Tool selection varies with scope and included workloads. Options we can assess include: Microsoft native tools: Migration Orchestrator, cross-tenant mailbox migration and cross-tenant OneDrive or SharePoint where suitable, Quest On Demand Migration: for broad tenant-to-tenant projects involving several Microsoft 365 workloads, BitTitan MigrationWiz: particularly useful for email migrations and certain Microsoft 365 scenarios, Cloudiway: for cross-tenant and multi-workload scenarios, ShareGate: particularly relevant to SharePoint, OneDrive, Teams and content governance, and PowerShell and Microsoft Graph: for inventory, automation, preparation and validation.
Microsoft documents Migration Orchestrator as a capability for moving data and workloads between separate tenants in specific scenarios.
4. Pilot testing
Before migrating the whole organisation, we recommend a representative pilot. It may include a standard mailbox, a large mailbox, a shared mailbox, a OneDrive containing shared data, a SharePoint site with significant permissions, a team with channels, files and guests, a user with mobile and Outlook access and a delegated permission case. The pilot checks actual timings, errors, tool limitations, migrated data quality and user experience.
5. Phased migration
Most projects use phases to reduce risk. Work can be grouped by department, user group, business unit, workload, critical and non-critical users or quieter business windows. Where supported by the tool, initial migrations and incremental synchronisation take place before final cutover.
6. Cutover, domains and DNS
Cutover is one of the project’s most important stages. It can change DNS, domains, mail flow, sign-in, Outlook, mobile devices and service access. We pay particular attention to MX records, Autodiscover, SPF, DKIM, DMARC, user UPNs, aliases and SMTP addresses, shared mailboxes, mail connectors, sending applications and access to Teams, OneDrive and SharePoint.
The objective is to execute the change with a checklist, assigned owners and subsequent tests.
7. Validation and subsequent support
A migration is complete when users can work, following verification of the tool’s completed jobs. Checks include sign-in, assigned licences, incoming and outgoing email, calendars, contacts, shared mailboxes, delegated permissions, Outlook, mobile devices, OneDrive synchronisation, file access, SharePoint permissions, Teams teams and channels, external guests where applicable, connected applications, DNS and email authentication.
We can also assist during the first days to resolve incidents, user questions, outstanding permissions or adjustments in the new environment.
Security, permissions and compliance
Security is part of project design from the outset. We review administrator roles, privileged accounts, MFA, Conditional Access, SharePoint and Teams permissions, external access, shared mailboxes and delegations, sensitive data, retention policies, Microsoft Purview where applicable, and DLP, labels and compliance within scope. Legal, regulatory and internal requirements must be considered before moving data.
User communication
Communication is critical. Even a technically successful migration can generate incidents when users do not understand the change. We can help prepare messages about migration dates, affected services, user actions, Outlook changes, mobile access, Teams usage after transition, new tenant sign-in and where to request help.
Communication reduces uncertainty and helps teams adapt to the destination environment.
Why work with Kloudeal
At Kloudeal, we approach these projects by understanding the environment and business objectives before selecting the tool. A technical, realistic approach. We assess what can move, what requires review, what depends on tools and what may require manual reconfiguration. Clear scope. We define project inclusions, exclusions, limitations and the validation that will be performed.
Microsoft 365 experience. We work with email, OneDrive, SharePoint, Teams, domains, users, permissions, licences, Microsoft Entra ID and migration tools. Assistance through the change. We can help from initial analysis to subsequent validation, including incident support and guidance for the internal team. Documentation and organisation. A migration should leave a clearly understood destination environment. We document decisions, significant changes and critical points.
Documents to receive at completion
Migration closure should allow IT to continue administering the environment. Agree handover documents before starting: final inventory, user and destination mapping, change overview, outstanding incidents and updated procedures. Tool reports provide useful information but do not replace this operational context.
Acceptance can be organised by service and user group. Email owners check reception, sending and delegation; repository owners review documents and access; application owners confirm integrations. Each validation needs a specific criterion, evidence and an authorised approver. This makes the overall state clear even when a localised incident remains.
Also deliver an exception register. Where an item could not be transferred, identify what is missing, the impact and the agreed alternative. Combining every failure into an error total is insufficient. Some exceptions may be accepted, others need retries, and others require temporary retention of a source dependency.
Review temporary access and project licences after acceptance. Coordinate removal with the client to avoid deleting an account or application still needed. Where subsequent support is agreed, documentation should distinguish change-related incidents, recurring administration and scope extensions. This helps users know whom to contact and which information to provide.
The final financial review should reflect project decisions: services remaining active, subscriptions to cancel and accepted additional tasks. The business owner should receive an operational environment and a clear explanation of what remains contracted, outstanding or outside the service.
Frequently asked questions about Microsoft 365 tenant-to-tenant migration services
How does a tenant-to-tenant service differ from copying mailboxes?
The service may coordinate identities, domains, data, permissions, devices and applications alongside email transfer. Scope should describe included components and their destination state. Usage tests and assigned responsibilities demonstrate the work beyond what a copying tool performs.
Who decides which data moves during a business separation?
Business and information owners decide, supported by the necessary technical advice. The provider needs authorised scope identifying people, resources and exceptions. Tool defaults should not determine which information remains or is shared between organisations.
What can delay a tenant-to-tenant migration date?
Unresolved dependencies, identity preparation, method limitations and decisions about domains or applications can affect the schedule. A pilot reveals actual effort and errors. Planning should record these conditions and their owners, rather than treating copying duration as the total service timescale.
What should post-cutover support include?
Specify channels, coverage, owners and priority criteria for incidents affecting agreed operation. Also establish how additional requirements will be handled. Final handover includes tests, accepted differences, outstanding matters and documentation enabling the client’s team to operate the new environment.
Conclusion
A Microsoft 365 tenant-to-tenant migration is a sensitive project affecting users, data, email, files, collaboration, domains, permissions and applications. It requires preparation through inventory, scope, tool selection, pilot testing, phased migration, communication, cutover, validation and subsequent support. At Kloudeal, we can help organise a complex migration around identified risks and clear next steps.
Need to migrate your Microsoft 365 tenant?
In Kloudeal we can review your scenario and help plan a Microsoft 365 tenant-to-tenant migration with a technical, realistic approach suited to your business. We can help with Exchange Online, OneDrive, SharePoint, Microsoft Teams, domains, users, permissions, licences, migration tools, PowerShell, validation and subsequent support.
Talk to Kloudeal about my Microsoft 365 migrationRecommended official documentation:
- Plan a Microsoft 365 tenant-to-tenant migration
- Microsoft Migration Orchestrator overview
- Cross-tenant mailbox migration
- Cross-tenant OneDrive migration
- Cross-tenant SharePoint migration
- Microsoft FastTrack cross-tenant migration
- Power Platform tenant-to-tenant migration
A practical way to review the migration proposal
Review the proposal with two questions in mind: what will be different for the business at handover, and who is responsible for each part of that result? Start with a representative user rather than the tool licence. Describe the account they will use, the services they will open and the information they need to continue their work. This gives both parties a concrete reference for checking whether the proposed scope matches expectations.
For example, an employee may need their own mailbox, access to a shared departmental address, a personal document repository and membership of a project team. These are related requirements, but they are not one indivisible migration object. Ask how each will be prepared, transferred or reconstructed. Also ask which access and device tasks remain with the internal team. A clear answer prevents a later disagreement about whether a copied mailbox included the employee’s complete working environment.
Make dependencies visible in the schedule
A proposed date is useful only when its starting conditions are understood. Domain release may depend on another administrator. Application testing may depend on a supplier. Business acceptance may require a departmental owner who is unavailable during the planned window. Record these dependencies with the work they affect. This allows the project team to distinguish a transfer estimate from a date on which the organisation can safely change services.
Where a dependency remains unresolved, the proposal should describe the next action and its owner. The answer need not pretend every uncertainty has disappeared before assessment. It should explain how the uncertainty will be resolved and when it could change cost or timing. This is more useful than placing a broad disclaimer at the end of a document without connecting it to the actual work.
Agree what evidence will support handover
Ask for a short set of acceptance cases covering the services included. Mailbox transfer reports can support content checks, while users confirm sending, receiving and delegation. Repository owners confirm access and the ability to use their documents. Application owners validate the integrations for which they are responsible. The provider should explain how those results will be brought together and which outstanding issues can be accepted with a documented alternative.
Support arrangements should be equally concrete. Establish the channel for incidents, the agreed coverage, the information users should provide and the route for escalation. Distinguish a fault in delivered scope from a newly requested feature. That distinction allows the team to restore agreed operation promptly while evaluating additional requirements through a separate decision.
At the final review, reconcile the delivered environment with the original scope and approved changes. Identify services still retained at source, temporary access awaiting removal and subscriptions that continue for an agreed reason. The objective is a handover that the receiving team can understand and administer. A clear record of completed work, accepted exceptions and remaining responsibilities is therefore part of the service outcome, alongside the movement of information.
Review the final record with the receiving administrator, confirming that open actions have named owners and that the service boundary is understood by both teams.