Tenant migration
Map identities, mail, files and permission dependencies.
Pilot and cutover plan with representative user validation.
IT Projects · Migrations
Enterprise IT migration planning for tenant moves and hardware refreshes
Migrations rarely fail on the night. They fail in the planning, when nobody lists the shared mailbox finance depends on, the app registered to the old domain, or the laptops still sitting in a warehouse. We plan the move in enough detail that cutover weekend is boring.
/ Fit check
Best for
Mergers, divestments, rebrands, tenant consolidations and device refreshes
Not for
Moves with no downtime window at all and no room for a pilot
Deliverables
Inventory, migration runbook, cutover plan, rollback points and handover notes
/ Direct answer
What does enterprise IT migration planning include?
Enterprise IT migration planning covers inventory, dependency mapping, sequencing, pilot testing, cutover scheduling, rollback points, user communication and post-migration support. For Microsoft 365 tenant-to-tenant moves it also covers identities, mailboxes, OneDrive, SharePoint, Teams, domains and licences. For hardware, it covers supplier lead times, device provisioning, data transfer and secure disposal of old equipment.
- Every dependency listed before cutover
- Pilot group before everyone
- Rollback triggers agreed in advance
/ Scope your engagement
Agree the cutover and the point at which you roll back.
Choose the change you need to deliver. The estimate should identify dependencies and completion criteria as well as implementation tasks.
Server or cloud move
Review workloads, network routes, identity and recovery prerequisites.
Migration sequence, rollback trigger and application-owner checks.
Hardware refresh
Plan provisioning, data transfer and retirement.
Deployment records, acceptance and handover to the support owner.
Example migration acceptance recordView an illustrative deliverable
This example illustrates the record format. It is not a client result or a service-level commitment. Your proposal lists the deliverables and responsible people.
| Checkpoint | Evidence | Approval |
|---|---|---|
| Before cutover | Pilot checks, backup/recovery readiness and dependency list | Sponsor accepts the window and rollback trigger |
| After cutover | Sign-in, mail flow, file access and application tests | Business owners validate representative workflows |
| Closeout | Exceptions, documentation, access removal and support contacts | Named owner accepts handover and remaining actions |
What to bring to the first conversation
Source and target environments, users and data, dependencies, business validation owners and acceptable disruption.
/ 01
What happens in a Microsoft 365 tenant-to-tenant migration?
Users, mailboxes, OneDrive, SharePoint sites, Teams and usually the email domain move from one Microsoft 365 tenant to another, most often after a merger, acquisition or divestment. The tricky part is that a domain can only be verified in one tenant at a time, so the cutover has to be sequenced carefully or mail starts bouncing.
Content moves in passes: a bulk copy weeks ahead, delta syncs as the date approaches, then a final pass at cutover. That keeps the cutover window short, because only the last few days of changes move on the night.
| What moves | What often gets missed |
|---|---|
| Mailboxes | Shared mailboxes, delegated access, inbox rules, room and equipment calendars |
| OneDrive | External sharing links, which break and need re-sharing |
| SharePoint and Teams | Private channels, chat history, apps and connectors, site permissions |
| Identities | App registrations, service accounts, MFA re-registration |
| Devices | Entra-joined laptops, which need re-joining or re-provisioning into the new tenant |
/ 02
Can you migrate between Google Workspace and Microsoft 365 in either direction?
Yes. Both directions follow the same plan: pre-stage mail, calendars, contacts and files, switch the domain's mail records at cutover, then run a final pass for anything that changed. The differences are in the detail, such as shared drives versus SharePoint sites, Google Groups versus Microsoft 365 groups, and how each platform handles room calendars and sharing permissions.
/ 03
How do you migrate on-premises servers to AWS, Azure or Google Cloud?
Server by server, based on what each one actually does. Some move as virtual machines, some move onto a managed service such as a cloud database or file service, and some are retired because a SaaS product already does the job. We map dependencies, licensing and data size first, pilot one workload, then move the rest in waves with a rollback point for each.
| Approach | Good for | Watch out for |
|---|---|---|
| Rehost as a virtual machine | Applications you can't change | Carries old problems and costs into the cloud |
| Move to a managed service | Databases and file servers | Application compatibility and connection strings |
| Replace with SaaS | Email, file sharing, accounting | Data migration and staff retraining |
| Retire | Servers nobody really uses | Confirm nothing still depends on it first |
/ 04
How do you provision hardware for remote staff without an office?
Devices ship straight from the supplier to the employee and set themselves up on first sign-in using Windows Autopilot and Intune (or Apple Business Manager for Macs). The user unboxes the laptop, connects to Wi-Fi, signs in with their work account, and gets company apps, policies and security settings without anyone touching it.
The prerequisite is that the supplier registers the devices to your tenant at purchase. When that step is missed, someone has to collect hardware hashes by hand, which is exactly the kind of detail planning exists to catch.
Old devices get the same attention. Data is checked and retained where needed, the device is wiped and removed from management, and disposal is recorded so the asset register matches reality.
/ 05
How do you reduce downtime during a migration?
By moving most of the data before cutover, piloting with a real team first, scheduling the switch for the quietest window, and agreeing in advance what would make us roll back. Downtime usually comes from surprises, so most of the effort goes into finding them before the weekend rather than during it.
- Pre-stage content weeks ahead
- Pilot with one real team
- Written go/no-go checkpoint
- Rollback triggers agreed before cutover
- User instructions sent a week ahead
- Hypercare support for the first week
/ 06
What should an IT migration plan document?
At minimum: what's in scope and what isn't, the full inventory, dependencies, the order things move in, who approves each stage, an hour-by-hour cutover timeline, rollback triggers and steps, user communications, and who supports people on the first morning. If a plan can't answer "what do we do if this step fails", it isn't finished.
| Document | Why it matters |
|---|---|
| Inventory and dependency map | You can't move what you haven't found |
| Sequencing plan | Some things must move before others, like domains and identities |
| Cutover runbook | Every step, owner and time on the night |
| Rollback plan | Decided calmly in advance, not at 2am |
| Communications plan | Users know what will change and what to do |
| Handover notes | The new environment is documented for whoever runs it next |
/ 07
How long does an enterprise IT migration take?
Planning usually takes longer than the move itself. A focused tenant-to-tenant migration for a mid-sized business typically runs several weeks from discovery to cutover, with the heavy data copying done in the background. Large or regulated environments take longer, mostly because of approvals and dependency discovery rather than the copying.
Frequently Asked Questions
Not completely. Users usually need to sign in again, re-register MFA, and reconnect Outlook and Teams on their devices. We keep that to one short disruption with clear instructions sent beforehand, rather than several small ones.
Channel conversations can be migrated with the right tooling, but one-to-one and group chats are harder and not every tool handles them well. We confirm what will and won't move during planning, so nobody is surprised afterwards.
Admin access to both platforms, a plan for the domain, licences assigned in the destination, an inventory of users, mailboxes, shared drives and groups, and a decision on how long mail is kept in both places. Our Google Workspace to Microsoft 365 migration checklist covers the full list.
Each server is assessed on whether it should move to Azure, be replaced by a cloud service, or stay where it is. Not everything belongs in the cloud, and the plan should say why for each system.
With Autopilot, very little physical work is needed because devices go direct to users. For anything that must happen on site, like racking a server or replacing network gear, we write the task list for your team or a local contractor and support them remotely.
Yes. Migrations are scoped as projects after discovery, and the inventory and risk items that drive the effort are written into the proposal so you can see where the time goes.
/ Next step
Review your migration requirements
Source and target environments, users and data, dependencies, business validation owners and acceptable disruption.