Microsoft 365 migration services
A migration can affect your users, email, files, Teams, devices, applications, security policies, domains and access to business systems. The difficult part is not copying the data — it is moving everything in the right order while the business keeps operating. So every migration starts by establishing what exists today, what depends on what, and what has to happen before anything moves.
Users, email, domains, SharePoint, OneDrive, Teams, devices, applications and permissions all have to arrive in the right place — in a planned sequence, against a stated cutover window. They do not all move at the same time.
The migration plan determines what moves, when it moves, what depends on it, and what happens if something goes wrong.
Before anything moves, every source account needs a destination. When two companies become one, the same employee may hold accounts in both tenants. Two different employees may have the same name. Former employees may still have mailboxes. Service accounts may belong to applications that are not moving at all. Each account is mapped before the migration begins, and the rest of the plan follows that mapping.
Identifying a person does not settle what they should be able to open. An employee may hold access today because of a role they held three years ago, and after an acquisition or a restructure that role is often narrower, wider, or gone. Permissions travel with the content and membership travels with the group — neither knows the organization changed — so copying them across unreviewed rebuilds years of unnecessary access inside the new tenant. Financial information, HR records, executive documents, deal information, salary data and redundancy planning are the material where that matters most, and they are exactly what a tenant merge brings into one place.
A user’s license determines which services they can reach and, in some cases, whether a workload can move at all. The license inventory belongs in the migration sequence rather than at the end of preparation.
Moving a mailbox is one part of moving email. The plan also covers shared mailboxes, distribution groups, mail-enabled security groups, transport rules, connectors, journaling, SMTP relay, the applications that send mail, and the scanner in the warehouse that relays through the tenant. Miss one and mail still fails after a mailbox migration that succeeded.
A verified domain normally cannot be attached to two tenants at once. Moving it is therefore a scheduled event of its own, separate from moving mailboxes and files — and mailboxes can already exist in the destination before the domain follows them. Sign-in names, mail delivery and anything authenticating on that domain all depend on when it lands.
Device work covers Intune enrollment, compliance policies, configuration profiles, BitLocker recovery keys, Autopilot registrations and Conditional Access requirements. A mailbox can be fully migrated while the same person’s laptop is still joined to the old environment, so devices need a plan of their own.
The tenant may carry line-of-business applications authenticating against Entra ID, Power Automate flows owned by someone who left, SharePoint links embedded inside documents, scripts still holding old tenant credentials, Azure applications, third-party integrations, anything calling Microsoft Graph, and SMTP relays. These surface during discovery, or they surface during cutover.
first.last@source-aflast@source-bMerge to a single identity. Both old addresses stay as aliases so inbound mail keeps arriving.
first.last@targetj.smith@source-aj.smith@source-bBoth keep an identity. One address has to change, and somebody has to decide which.
j.smith@targetjohn.smith@targetleaver@source-bNo account is created in the target. What happens to the mailbox is a decision, not a default.
svc-scanner@source-aTied to a system that is not moving. Carried, replaced or retired — settled before the wave, never by default.
Identity decisions come first, because almost everything else depends on them. How the mapping gets built
The approach changes with your starting point. Pick the one that describes your estate.
From another Microsoft 365 tenant
This usually follows an acquisition, a merger, a divestiture or an internal restructure. Identity drives the sequence, and both environments often have to run at the same time during the move. SharePoint, OneDrive and Teams travel with it — sites, permissions, sharing links, chat and channel history.
Tenant consolidationFrom Google Workspace
Google Workspace and Microsoft 365 organize users, files, permissions, calendars and collaboration differently. This is not Gmail copied into Exchange Online. Drive permissions and shared drives rarely map one to one, and the calendar and contact estate is usually messier than the mail. Some of it maps cleanly; the rest is a design decision taken before anyone moves.
Google Workspace → Microsoft 365From email that is not Microsoft 365 yet
The source may be Exchange Server or hybrid Exchange, hosted Exchange, an IMAP platform, another legacy mail system, or a GoDaddy-provisioned Microsoft tenant. File servers may be moving into SharePoint and OneDrive at the same time. Each source has its own limitations and its own migration options.
Email and complex sources → Microsoft 365Many organizations get in touch after the environment has already become complicated.
Sometimes there was never a formal merger or migration project — the company simply accumulated tenants. A department created one, an acquired business kept another, a project team bought its own licenses, and nobody consolidated them.
Disconnected Microsoft 365 environmentsA carve-out or a divestiture runs in the opposite direction: users, applications, data and identities come out of a shared tenant rather than into one. The deadline is usually somebody else’s, tied to a transaction or a transition services agreement.
Divestitures and tenant separationSome users moved and some did not. Duplicate accounts, broken permissions, domains split between environments, partial SharePoint migrations, two security models, and applications still pointing at the old tenant. The first job is not to carry on migrating — it is to establish what has already happened.
Start with a Readiness AssessmentDocument the environment as it actually exists, not as documented: users, licensing, domains, mail flow, devices, applications, permissions, security controls, and the systems connected to the tenant.
Define the destination and the route to it: target tenant design, identity model, what has to run in coexistence and for how long, the migration sequence and the cutover strategy.
Fix the problems that would cause the migration to fail, while nothing is at stake: identity cleanup, licensing, mail flow, domain preparation, permission review and application dependencies.
Start with a controlled pilot group, which validates the design while the impact is still small. Then move users and workloads in planned waves, each against a stated cutover window and with a rollback position.
Test after every wave: sign-in, mail delivery and mail flow, shared mailboxes, permissions, SharePoint and OneDrive, Teams, applications, device compliance, and access to business-critical systems.
Provide hypercare while people find the things testing did not. The less obvious problems appear once everyone is working normally again.
Remediate what surfaced, and transfer knowledge to the people who will run the environment. This closes the engagement — it is not a service desk and not an ongoing contract.
Document what changed, how the new environment works and what has to be maintained, and confirm that the old environment is no longer required.
A migration should leave you understanding the environment you now own. You keep these deliverables whether or not Sunrise runs the migration. Four of them — the estate inventory, the dependency map, the remediation register and the migration plan — exist before anything moves, and they are also part of what a Readiness Assessment produces. That can be bought on its own, and it gives you a defensible migration plan before you commit to the migration itself.
Every migration surfaces security posture, because migrating forces someone to examine identity, permissions, administrative access and the way people share information. That review turns up old administrator accounts, excessive privilege, missing MFA, Conditional Access that no longer matches the estate, external sharing nobody has reviewed since it was granted, former employees who still have access, and groups whose membership stopped being true years ago. Permissions carried across unchanged are part of that posture rather than separate from it.
Some of it gets corrected as part of the migration. When the security of the tenant becomes the question rather than a side effect, it is a separate piece of work with its own scope, baseline and remediation plan.
Microsoft 365 Security AssessmentCopilot can only see what the user already has permission to open. That sounds safe, and it is exactly what exposes a problem most organizations have carried for years: people usually have access to more than anyone realizes. Spread across SharePoint, Teams and OneDrive, that access went unnoticed while people had to find information by hand. Asked a question, Copilot surfaces it.
So readiness starts with permissions, sharing, data ownership, information structure, governance, and identity and access. Licensing comes after those are understood. It is the same question a consolidation raises, arriving later and louder.
Copilot Readiness & GovernanceBefore anyone commits to a migration date, you need to know what is actually inside the environment. That is a piece of work with its own output, and you keep the output.
A Readiness Assessment gives you the estate inventory, the identity and access findings, the dependencies, the migration blockers, the remediation required and a proposed sequence you can defend internally. The documents stay useful whether Sunrise runs the migration or another provider does. Know what you are moving before you start moving it.
Ask about a Readiness AssessmentTell us where you are moving from, what needs to move, what has already been attempted, and whether the work has a deadline.