Microsoft 365 tenant-to-tenant migration

Migration between Microsoft 365 tenants.

We deliver projects to consolidate or separate Microsoft 365 environments. We plan users, mailboxes, files and domains, taking account of dependencies between services and the preparation needed for the destination tenant before the transfer and final change are carried out.

Request tenant-to-tenant migration Explore the migration process
Reviewing project information on a screen

We plan the transition between Microsoft 365 organisations with attention to identities, domains and service dependencies. We define which data can migrate, which exceptions need separate treatment and which acceptance tests will be used to assess the result of the move.

Tenant-to-tenant migration scope depends on the state of the tenants, the services used and the technical limitations of each workload. At Kloudeal, we define scope from the outset, distinguishing what can migrate, what should be recreated and what requires manual validation. This helps establish realistic expectations and a clear basis for planning and checking the work.

For migration of Exchange Online, we review user and shared mailboxes, aliases, calendars, contacts, rules, domains, DNS records and mail flow. For migration of OneDrive, we analyse account sizes, ownership, permissions, item counts and synchronisation after the move. In SharePoint, we review sites, libraries, documents, lists, permissions, shared links and the document structures used by the organisation.

We can also assess environments using Microsoft Teams, recognising that teams, channels, associated files, applications, meetings and chats can behave differently according to the tool and project scope. Some content can migrate; other elements may be better recreated so that the destination tenant has a clearer structure and can be administered more easily. These decisions are made before committing to the transfer scope.

  • Exchange Online: mailboxes, email, calendars, contacts, aliases and the shared mailboxes used by the organisation.
  • OneDrive for Business: personal files, folders, ownership and permissions, with the relevant accounts mapped to their destination users.
  • SharePoint Online: sites, libraries, documents, lists and the collaboration structures included in the agreed migration scope.
  • Microsoft Teams: teams, channels, associated files, members and permissions, according to the tools and scope agreed for the project.
  • Microsoft Entra ID: users, groups, roles, identities and access policies that need to be reviewed for the destination environment.
  • Domains and DNS: MX, SPF, DKIM, DMARC, Autodiscover records and mail flow arrangements required for the transition.

Cross-tenant migrations often take place at important moments for a business. A common case is a merger or acquisition, where two organisations need to consolidate users, email, files and collaboration tools in a single environment. They also arise in business separations, when a division or subsidiary needs to leave its original tenant and start operating independently with its own identities, services and administration.

Another common scenario is a domain or brand change. Email, users and Microsoft 365 services then need to align with a new corporate identity. A business may also have created several tenants over time and want to centralise administration, licensing, security and collaboration within a single environment that can be managed with a consistent structure and operating model.

Planning matters in all these cases. Errors involving domains, permissions, mail flow or access can cause interruptions, lost productivity or confusion for users. We therefore work with an inventory, mapping, testing, internal communication and validation before the final change, establishing how each service and user group will be handled during the transition.

One of the most sensitive points is the business domain. The same domain cannot normally be active in two tenants at the same time, so the transition needs careful planning. This particularly affects email, user identities, DNS records, Outlook settings and devices. The domain move must therefore be coordinated with the other activities needed for users to access the destination.

Another important point is identity mapping. Each source user needs to be matched correctly to the destination user, with primary addresses, aliases, groups, shared mailboxes, permissions and file access reviewed together. Incorrect mapping can cause access problems after migration, even where the content itself has been transferred successfully to the new tenant.

We also review inherited permissions, external access, connected applications, integrations, workflows and dependencies. Some applications depend on the original tenant, consents, connectors or APIs that need review before the change. Tenant-to-tenant migration therefore requires assessment of the services around the data, including the configuration and access arrangements that may need to be recreated or updated in the destination.

Implementation is organised into the following phases. The activities, dependencies and checks for each stage are defined within the scope agreed for the project and the environment involved.

  1. Initial assessment: review of tenants, domains, users, services and the dependencies affecting the proposed migration.
  2. Inventory and mapping: relationships between users, mailboxes, files, groups and permissions in the source and destination environments.
  3. Migration plan: phases, tools, work windows, responsibilities and validation activities defined for the project and its services.
  4. Destination preparation: users, licences, security, domains and the collaboration structure needed in the destination before the transfer.
  5. Pilot migration: validation using selected users or services to assess the proposed approach before the wider migration.
  6. Main migration: execution in phases or within a controlled change window, according to the plan agreed for the project.
  7. Domain change: DNS, mail flow, access arrangements and devices where these need changes as part of the transition.
  8. Final validation: checks on data, permissions, email and the services included in the migration scope after the transfer.
  9. Ongoing support: incident resolution, documentation and recommendations for administering the destination environment after the change.

Before a cross-tenant migration starts, several points should be clear: which services will move, how many users are involved, which domain will be used, which data is critical, which permissions should be retained, which applications depend on the current tenant and which users will validate the result. These details establish both the scope and the dependencies that need planning.

Internal communication also needs preparation. Users should know when the change will happen, which services may be affected, whether they need to sign in again, whether Outlook, Teams or OneDrive needs reconfiguration and whom to contact if a problem occurs. These instructions need to reflect the migration sequence agreed for their services and user group.

After migration, the destination tenant should be operational, validated and ready for administration. We review sending and receiving, shared mailbox access, calendars, OneDrive, SharePoint, Teams, permissions, groups, devices, Office applications and dependent services. We also recommend documenting the new structure, reviewing security, organising groups and removing unnecessary permissions so that the resulting environment can be maintained coherently.

We agree the scope, responsibilities and priorities with your team. We document the work and the checks carried out. Any additional requirement is assessed before it is incorporated into the project or the support service, so that the implications for the agreed work are understood.

We answer common questions about moving users, mailboxes, files and services between Microsoft 365 tenants. We also include links to official documentation for further technical detail, helping clarify the supported methods, workload limitations and preparation needed before a cross-tenant migration is planned.

It is the process of moving users, data and services from a source Microsoft 365 tenant to a destination tenant. It is commonly used for mergers, acquisitions, business separations, domain changes or consolidation of environments, with the scope defined around the services and identities that need to move.

Microsoft provides official documentation for planning these projects in its guide to Microsoft 365 tenant-to-tenant migration.

Scope depends on the project, available tools and the limitations of each service. Exchange Online, OneDrive, SharePoint, Microsoft Teams, users, groups, permissions, domains and security settings are commonly reviewed. The assessment distinguishes which content can be transferred from configuration or access arrangements that need to be recreated and validated separately.

Microsoft also provides documentation on Migration Orchestrator for tenant-to-tenant migration.

Yes. We can plan cross-tenant mailbox migrations, reviewing source-to-destination users, domains, permissions, licences, shared mailboxes, aliases, calendars and coexistence requirements. These points define the preparation needed in both tenants and the way mail flow and user access will be coordinated during the change.

Microsoft documents the process of cross-tenant mailbox migration, used in scenarios such as mergers, acquisitions and business separations where mailboxes need to move between organisations.

Yes. We can assess and plan OneDrive cross-tenant migrations, reviewing users, ownership, permissions, account sizes, item counts, synchronisation and subsequent validation. The review establishes how each account maps to the destination and what users need to do to access and synchronise their files after the move.

Microsoft provides official documentation on cross-tenant OneDrive migration.

Yes. Migration of SharePoint sites, libraries, documents, lists and permissions can be planned, although the method depends on volume, structure, permissions, content types and the tools used. These characteristics need review before the transfer approach and validation criteria are agreed for the sites included in the project.

Before committing to scope, we review critical sites, libraries, owners, shared links and possible technical limitations that could affect the transfer or the way users access information afterwards.

It depends on the scope and tools available. Teams requires a review of teams, channels, associated files, permissions, applications, meetings, conversations and chats. Some items may need rebuilding or specific handling rather than direct transfer. The project needs to make these differences clear before the migration method is selected.

We therefore create an inventory first and distinguish what can migrate, what must be recreated and what should be reorganised in the destination tenant to support its future use and administration.

One-to-one Teams chats are among the most sensitive items in cross-tenant migration. Their treatment depends on available tools, permitted APIs, service limitations and the contracted scope. Requirements for retaining or transferring conversations need to be assessed specifically, rather than assumed to follow the same method as channels or files.

Before the project starts, we review whether conversations need to be retained, whether export is required, whether teams should be recreated or whether the focus should be on files, channels and future collaboration in the destination.

It depends on the migration type, domain use, data volume and selected strategy. Many projects can be phased, but the transition of domains, email and access usually requires a controlled change window. The plan needs to coordinate these activities with the transfer of data and the steps required for users to work in the destination.

Where a domain must move between tenants, its removal from the source, activation in the destination, DNS changes, mail flow and user validation all need to be planned carefully as part of the same transition.

It depends on the service and migration method. Permissions can be retained in some cases; in others, rebuilding them is advisable to improve security and avoid carrying over outdated configuration. The review establishes which settings should be retained, recreated or changed before access is validated in the destination tenant.

Before migration, we review users, groups, roles, permissions, external access, shared mailboxes, libraries, teams and policies to define a consistent strategy for the destination tenant and the services being moved.

After a cross-tenant migration, users may need to sign out, sign in again, reconfigure Outlook, Teams, OneDrive or Office applications, and validate file and email synchronisation. These activities depend on the applications and access arrangements in use and need to be included in the communication and support plan.

We can assist users during this stage to reduce incidents and help them adopt the new environment and the access arrangements that apply after the migration.

Timing depends on user count, mailbox volumes, OneDrive sizes, SharePoint structure, Teams usage, synchronisation speed, technical restrictions, the shared domain and available change windows. These factors need to be assessed together before estimating preparation, transfer, cutover and the validation of the services included in the migration.

After the initial assessment, we can estimate the work by phase. In complex environments, we recommend a pilot, migration in batches and validation before the wider change to the destination tenant.

Yes. After migration, we can help validate users, configure Outlook, Teams, OneDrive and Office applications, review permissions, handle incidents and provide documentation and administration recommendations. The work is defined around the services moved and the support arrangements agreed for the period after the transition.

We can also provide basic training, review security, organise groups and help improve the new tenant, according to the requirements and scope agreed with the organisation for subsequent work.

Tell us about the current platform, the number of users or resources involved and your priorities. We will review the context to define the next steps and the scope of the proposal for your organisation.

Contact Kloudeal