Creating a new mailbox is quick. The real migration question is whether shared mailboxes, calendars, mobile devices, scanners and business applications still work as expected afterwards. For a small or midsized business, that takes more than a date for changing DNS: the existing environment must be understood, a pilot must cover critical workflows, and the handover must record ownership.
This guide explains the decisions that should be made before moving to Microsoft 365 or carrying out a substantial change within an existing Microsoft environment. The appropriate migration method depends on the source system and the services in scope.
Start by defining the migration you actually need
A small greenfield setup is different from taking over an existing tenant, moving from another mail provider or migrating between two Microsoft 365 tenants. On-premises Active Directory or Exchange dependencies also change the plan. Microsoft explicitly notes that its general setup wizard is not the right path for directory synchronisation or hybrid Exchange environments.
Before selecting tools, define the services in scope: email only, or also OneDrive, SharePoint, Teams, device management and identities? A tenant-to-tenant migration introduces additional prerequisites, sequencing and potentially separate licensing. A universal migration recipe would create more risk than clarity.
Inventory: what must be known before the first change
The inventory does not have to become a lengthy report. It does need to capture the dependencies that could stop work or change access during the cutover.
- Identities and administration: users, administrative roles, emergency access, MFA methods and ownership of the existing tenant.
- Domains and DNS: the registrar, DNS administration, active domains and subdomains, and records used by email and other services.
- Email and calendars: mailboxes, aliases, distribution lists, shared mailboxes, forwarding, delegation, rooms and equipment.
- Files and collaboration: data sources, volume, permissions, external guests, retention requirements and business owners.
- Devices and applications: Windows devices, smartphones, Office sign-ins, scanners, multifunction devices and applications that use email or Microsoft sign-in.
- Operations and recovery: licences, support ownership, backup, known faults and outstanding changes.
Control of the company domain is particularly important. Microsoft recommends creating the required users and mailboxes before pointing the MX record to Microsoft 365. The DNS change itself is not a substitute for preparation or functional testing.
The target state describes more than products
Before the pilot, define how users will sign in, which primary addresses will apply, where files will live and who can approve administrative changes. Device management, MFA, shared resources, backup and leaver processes belong in that target state as well.
Not every legacy feature needs to be carried forward unchanged. Old distribution lists, duplicate accounts and historical permissions can be cleaned up deliberately. These decisions must be made before migration by an accountable business owner. The technical move should not quietly decide who may access which data afterwards.
A pilot must test representative workflows
A pilot is more than a successful sign-in with one test account. It should cover representative ways of working: a normal office user, mobile work, a shared mailbox or delegated access, and at least one relevant application or device that sends email.
A useful pilot might include:
- sign-in and MFA on the intended devices;
- internal and external mail flow, including replies;
- calendars, delegation and shared mailboxes;
- OneDrive sync or the agreed SharePoint permissions;
- Outlook, smartphones, and selected scanners or business applications;
- the support and recovery path when a user loses access.
Results should not be recorded only as “works” or “does not work”. Every open item needs an impact, an owner and a decision before the broader migration.
Cutover needs explicit decision points
Before the cutover window, users and destination mailboxes must be ready, current data and synchronisation states understood and the required DNS changes known. Staff need a communication channel outside the email service being changed. The plan should also define when to continue, pause or postpone.
A fallback is credible only when it states what can genuinely be reversed. A DNS record can be changed again, but moved data, new user activity and reconfigured devices do not automatically return to their previous state. Rollback boundaries therefore belong in the plan, not in an improvised response during an incident.
Acceptance and handover complete the migration
After cutover, repeat the agreed workflow tests. Confirm external reachability, shared or role-based mailboxes, permissions, mobile devices and the selected applications. Record exceptions with a priority and a responsible owner.
The handover should also cover administrative roles, controlled emergency access, domain and licence ownership, the backup and recovery decision, and a list of intentionally retained legacy components. Only then can ongoing operations be taken over with a clear basis.
A short checklist for the customer
- Who can make business decisions about accounts, data and permissions?
- Who controls the tenant, domain and DNS administration?
- Which mailboxes, aliases, lists and permissions are genuinely in use?
- Which devices and applications depend on email or Microsoft sign-in?
- Which users and workflows make the pilot representative?
- Which tests determine whether cutover is accepted?
- How will staff be reached while email is being changed?
- Who owns documentation, open work and subsequent operations?
Define the scope before setting a date
JITIS helps SMEs assess their existing Microsoft environment and its dependencies before migration. The Microsoft environment assessment provides a documented current state and an implementation roadmap; migration and ongoing operations are then agreed as clearly bounded services. If the project is part of a provider change, the IT provider handover checklist is a useful companion.
For the first conversation, the source system, user count, affected services and desired timeframe are enough. From there, it is possible to decide whether the next step is an inventory, a pilot or a defined migration project.
