SMB email migration
An email migration often looks simple from the outside: move mailboxes, update a few DNS records, and ask employees to sign in again. In practice, a Microsoft 365 email migration checklist must account for identities, devices, shared mailboxes, security controls, historical data, and the everyday workflows that depend on email. Missing one dependency can turn a planned weekend change into a Monday morning operations problem.
For small and mid-sized businesses, the goal is not merely to get email working in Microsoft 365. It is to move into a platform that is easier to secure, support, and scale as the business grows. The following checklist is designed to help operational leaders and internal IT teams plan the work with fewer surprises.
Microsoft 365 Email Migration Checklist: Start With Assessment
Before selecting a migration date or tool, document what exists today. Your source environment may be another Microsoft tenant, an on-premises Exchange server, Google Workspace, a hosted email provider, or a mix of systems acquired through growth. The source affects both the migration method and what can be moved.
Create an inventory of every active user mailbox, shared mailbox, resource mailbox, distribution list, group, alias, and external forwarding rule. Include former employee accounts that may still hold business records. Confirm which mailboxes require their full history, and identify archives that may need separate handling.
This is also the point to identify applications that send email. Printers, accounting platforms, websites, alerting tools, and line-of-business systems may rely on SMTP settings that change after the move. These systems are easy to overlook because they do not appear in a user mailbox report.
Your assessment should answer four practical questions:
Who needs a license, and which Microsoft 365 plan fits their work requirements?
What data must move, including email, contacts, calendars, archives, and permissions?
Which business systems send or receive email through the current provider?
What security, retention, or industry requirements influence the migration design?
Avoid assuming that all existing settings should be copied. A migration is a useful opportunity to remove dormant accounts, outdated groups, broad forwarding rules, and legacy processes that no longer serve the business.
Design the Identity and Security Foundation
Email is connected to identity. Each employee's mailbox, access to shared resources, sign-in method, and security posture should be designed before data begins moving.
Start by confirming the domain names that will be used in Microsoft 365. Verify ownership early, and review DNS access with the person or provider who controls the domain. Delays commonly occur when DNS credentials are unavailable or when domain administration sits with a former employee, web agency, or registrar account no one actively manages.
Next, establish how users will authenticate. Microsoft Entra ID provides the identity layer for Microsoft 365, and multifactor authentication should be planned as part of the migration, not added as an afterthought. Decide whether security defaults are appropriate for the organization or whether Conditional Access policies are needed. The right approach depends on licensing, device management maturity, locations, user roles, and risk profile.
For organizations managing company devices, align the email migration with Microsoft Intune planning. A user who receives a new mailbox but cannot enroll a laptop or mobile device in the required security controls will still experience disruption. Device compliance, mobile application protection, and access rules should be tested together.
Microsoft Defender capabilities can also help improve email protection, but configuration should reflect the business's actual needs. Review anti-phishing, anti-spam, and quarantine processes, then make sure someone owns the day-to-day response. Security controls are only useful when employees know what to expect and administrators can investigate issues promptly.
Choose the Right Migration Method
There is no single best method for every organization. A small business with a handful of mailboxes and limited historical data may be able to use a carefully planned cutover. A larger organization, or one with significant mail history and shared resources, may benefit from a staged approach that synchronizes data before the final switch.
Native Microsoft migration options can be suitable in some scenarios. Third-party migration tools may offer additional reporting, filtering, scheduling, or support for complex source environments. The right choice depends on source platform compatibility, mailbox volumes, data size, coexistence requirements, and the level of control required during the transition.
Do not choose solely on speed. A faster cutover may create a shorter project timeline, but it can place more pressure on users and support staff during the change window. A staged approach takes more coordination, yet it can reduce the amount of data left to move on the final day. For many growing businesses, predictability is more valuable than finishing a few hours sooner.
Prepare Data, Users, and Business Workflows
Clean up source data before the migration where practical. Remove clearly obsolete mailboxes, confirm aliases, and address duplicate or inconsistent user records. If employees use personal contacts or local Outlook archives for business activity, decide whether those files should be imported, retained separately, or excluded. Not every old file belongs in the new environment.
Shared mailboxes need particular attention. Document membership, Send As and Send on Behalf permissions, delegated calendar access, and any workflows tied to those addresses. A shared inbox for sales, billing, or support is often a business process, not just a mailbox. Recreating the address without its permissions can stop a team from doing its work.
Communicate early and plainly with employees. Let them know the migration date, what will change, how they will sign in, whether they need to reset passwords or enroll in multifactor authentication, and where to get help. Keep the message focused on actions rather than technical detail.
A pilot group is valuable when the business has enough users to support one. Choose people who use different devices and workflows, such as a manager, a remote employee, a shared mailbox delegate, and someone who relies heavily on calendars. Their experience can expose configuration gaps before the broader rollout.
Execute the Cutover With a Clear Runbook
A written runbook turns a migration from a collection of tasks into a controlled change. It should name the people responsible for technical execution, DNS changes, user communications, escalation decisions, and post-migration support.
Before the cutover, create accounts and licenses, configure mail flow settings, set up security policies, and complete an initial data sync where the method allows it. Confirm that migration credentials have the required permissions and that source mailboxes are not subject to unexpected access restrictions.
During the cutover window, update DNS records according to the planned design. This commonly includes MX, Autodiscover, SPF, and verification records, with DKIM and DMARC considered as part of the broader email security configuration. DNS changes can take time to propagate, so schedule the transition with that uncertainty in mind. Avoid promising users an exact minute when all external email delivery will change.
Test critical functions immediately after the switch. Send and receive messages internally and externally, test Outlook and mobile access, check calendar sharing, confirm shared mailbox permissions, and validate mail sent by business applications. Also verify that new messages are being routed to Microsoft 365 rather than the old provider.
Keep the source environment available for an agreed period when possible. It provides a practical fallback for reference data and allows the team to address any remaining migration exceptions without rushing.
Validate, Support, and Optimize After Migration
The first few business days matter as much as the cutover itself. Monitor migration reports, failed items, mail flow alerts, user sign-in issues, and support requests. Resolve recurring problems at the configuration level rather than treating each ticket as an isolated event.
Review whether employees are using modern authentication and whether multifactor authentication enrollment is complete. Check for unexpected forwarding rules, review shared mailbox access, and confirm that former employee accounts are handled according to the organization's policies. If the business uses Intune, validate that required devices meet the intended compliance state before relying on conditional access restrictions.
This is also a good time to establish operational ownership. Document who manages new users, license changes, mailbox permissions, security alerts, and retention settings. Microsoft 365 is not a set-and-forget service. It performs best when changes to staff, devices, and business processes are reflected in ongoing administration.
For businesses without dedicated Microsoft expertise, a readiness review can clarify scope, migration method, security requirements, and support responsibilities before a date is announced. Lozes IT helps organizations plan Microsoft 365 migrations as part of a broader approach to secure identity, managed devices, and reliable day-to-day operations.
A well-prepared migration should leave your team with more than a new email address. It should give the business a clearer foundation for onboarding, collaboration, security, and the next stage of growth.
