Microsoft 365 Migration Checklist for Toronto Small Businesses: 15 Steps for 2026

A small Toronto company can decide to move to Microsoft 365 for sensible reasons: professional email, easier collaboration, modern identity, better device management, or one place for Outlook, Teams, OneDrive, and SharePoint. The subscription can be purchased in minutes. Moving the business safely takes more thought.

The difficult part is rarely copying one mailbox. It is discovering the forwarding rule that sends invoices to accounting, the shared calendar used by dispatch, the desktop archive only one employee knows about, the file-share folder with inherited permissions, the scanner that sends email through an old account, and the phone number used for an administrator’s multifactor authentication.

This Microsoft 365 migration checklist is written for small and medium-sized organizations in Toronto, Ontario, and across Canada moving from Google Workspace, hosted email, file servers, another Microsoft 365 tenant, or a mixture of older systems. It covers the decisions that reduce disruption before, during, and after cutover.

What a Microsoft 365 migration actually includes

A migration may involve much more than email. The exact scope depends on the source environment and what the business wants to operate in Microsoft 365 after the move.

Not every business needs every workload on day one. A phased project may move identity and email first, then redesign file collaboration, device management, and Teams after the essential communication path is stable.

1. Define the business outcome and migration scope

Write down why the organization is moving and what must be true for the project to be considered complete. “Move to Microsoft 365” is too broad. A more useful objective is: “Move 32 employee and shared mailboxes from our current provider to Exchange Online, preserve required mail and calendars, protect every account with multifactor authentication, and complete cutover with no lost inbound email.”

• Which users, locations, domains, and business units are included?
• Are email, calendars, contacts, files, Teams, devices, and applications all in scope?
• What must remain available during the transition?
• Which information needs to be preserved for legal, contractual, operational, or tax reasons?
• What is explicitly out of scope for this phase?
• Who can approve the cutover, accept known limitations, or stop the migration?

2. Build a complete source inventory

Export what can be exported and interview the people who know how work actually happens. The inventory should include active and inactive users, aliases, distribution lists, shared mailboxes, delegates, forwarding, calendars, contacts, mailbox sizes, file volumes, permissions, external sharing, applications, devices, and DNS records.

Look specifically for dependencies that fail quietly after a move: printers and websites that send mail, accounting software with SMTP settings, forms that deliver to an old address, mobile devices using basic credentials, archive files on local computers, service accounts, and employees who sign in to third-party applications with the old identity.

3. Design the target tenant before creating users

Choose the tenant carefully because its default domain, region, administrative model, and identity design become long-lived foundations. Decide how usernames and email addresses will be formatted, how groups and shared resources will be named, which domains will be connected, who will hold administrative roles, and how emergency access will be protected.

Use role-based administration instead of making everyday accounts Global Administrators. Keep separate administrator identities where practical, protect them with strong authentication, document ownership, and avoid tying critical recovery to one employee’s personal phone or email address.

4. Match licensing to actual users and controls

Microsoft 365 Business plans are intended for organizations with up to 300 users, but the plans do not provide identical desktop applications, security, device management, or service capabilities. Assign licenses by persona and requirement rather than buying one plan because its name sounds complete.

A user who needs browser and mobile services may have different needs from an employee who requires desktop Office applications. A company that wants managed devices, Conditional Access capabilities, Defender for Business, and enhanced email protection may evaluate Microsoft 365 Business Premium. Microsoft describes Business Premium as including Business Standard capabilities plus security products such as Defender for Business and Defender for Office 365 Plan 1. Confirm the current service description and regional pricing before purchase because product packaging changes.

• Map each user type to required email, storage, desktop, meeting, security, and device features.
• Include shared mailboxes, meeting rooms, frontline workers, contractors, and service identities.
• Check mailbox and archive requirements rather than assuming every plan has the same limits.
• Separate base licensing from optional backup, voice, compliance, or Copilot services.
• Record who approves license changes and how unused licenses will be reclaimed.

5. Review Canadian privacy, contracts, and data handling

A cloud migration changes where information is processed, who can access it, and which providers or subprocessors are involved. The Office of the Privacy Commissioner of Canada advises businesses to understand what a cloud provider will do with personal information, whether it uses subcontractors, how information is protected, and how the organization will meet its own privacy obligations.

Inventory personal and confidential information before migration. Review customer contracts, retention duties, breach-notification procedures, data-location needs, access controls, and deletion requirements. Privacy responsibility does not disappear when a Toronto or Ontario business uses a cloud service.

6. Select the right migration path and tools

The source determines the method. Exchange Online supports different mailbox migration approaches for Exchange Server, Google Workspace, IMAP systems, and cross-tenant moves. An IMAP migration generally moves email, not every calendar, contact, task, rule, or delegate configuration. Google Workspace and tenant-to-tenant projects have their own prerequisites and routing considerations.

For files, Microsoft provides tools and guidance for file shares, SharePoint Server, Google Workspace, Dropbox, and Box. The SharePoint Migration Tool can copy content from file shares and supported SharePoint Server versions to SharePoint Online, OneDrive, or Teams locations. Migration Manager supports additional sources and centrally managed tasks. Scan and assess content before copying it; permissions, invalid names, unsupported features, path length, and information architecture need deliberate remediation.

7. Redesign file ownership before copying data

Do not reproduce an old file server folder-by-folder without asking who owns each area and how people collaborate. OneDrive is generally suited to an individual’s working files. SharePoint and Teams-connected sites are better for information owned by a department, project, or business process.

Define site owners, members, visitors, external-sharing rules, naming, sensitivity, and lifecycle. Reduce deeply nested paths, remove obvious duplicates, address unsupported files, and map source permissions to understandable target groups. Copying complicated legacy permissions can preserve the problem while making it harder to explain.

8. Configure identity and security before cutover

Create the security baseline before users begin depending on the tenant. At minimum, protect users and administrators with multifactor authentication, block legacy authentication where appropriate, restrict administrative roles, configure audit and alerting, and decide how devices and external sharing will be managed.

Microsoft Entra security defaults provide a baseline for many tenants. Microsoft’s June 18, 2026 documentation notes that new tenants created from July 1, 2026 block device code flow as part of security defaults. That can affect applications or devices that rely on this sign-in method, so include them in the inventory and pilot rather than weakening controls during an urgent cutover.

• Register at least two appropriate authentication methods for critical administrators.
• Test scanners, meeting-room devices, scripts, and applications that sign in without a normal browser.
• Use least privilege and time-limited elevation where licensing and operations support it.
• Configure anti-phishing, anti-malware, safe-link, and mail-flow settings appropriate to the plan.
• Define external sharing and guest access before employees create workarounds.
• Document secure onboarding and offboarding for employees and contractors.

9. Verify the domain and prepare DNS safely

Adding and verifying a custom domain is not the same as directing email to Microsoft 365. Verification commonly uses a DNS record that proves ownership. The MX record controls where new inbound email is delivered. Plan these as separate events.

Microsoft’s April 23, 2026 DNS guidance says to add users and set up mailboxes before updating the MX record. When the MX record changes, new email for the domain begins going to Microsoft 365; existing messages remain at the former provider unless they are migrated. Record current DNS values, understand registrar access, reduce time-to-live in advance where appropriate, and prepare the required Exchange Online Protection, Autodiscover, SPF, DKIM, and DMARC decisions.

10. Run a representative pilot

Choose pilot users who represent different roles, devices, mailbox sizes, file patterns, locations, and business applications. Include a technically confident user and at least one person who performs a critical everyday workflow. Avoid selecting only the IT team because their behaviour and tolerance for troubleshooting are not representative.

• Sign in on managed and approved personal devices.
• Send and receive internal and external email, including attachments.
• Test aliases, groups, shared mailboxes, delegates, calendars, and meeting rooms.
• Open migrated files, verify ownership and permissions, and test external collaboration.
• Validate Outlook profiles, mobile clients, Teams meetings, printers, scanners, and line-of-business applications.
• Compare item counts or reports and sample important historical data.
• Record user questions, failed items, timing, and support effort before expanding the batch.

11. Write the cutover and rollback plan

A cutover plan should name the owner of every action, the expected start and finish, dependencies, acceptance checks, communication points, escalation contacts, and the condition for pausing or rolling back. Avoid scheduling a major change immediately before payroll, month-end, a public event, or a period when key decision-makers are unavailable.

The rollback approach depends on the migration method. It may involve restoring the previous MX record, keeping source accounts active, resuming an earlier client configuration, or postponing a user batch. Rollback does not erase messages that arrived during the change, so define how mail and data created on both sides will be reconciled.

12. Communicate what employees must do

Tell employees what is changing, why, when, what they must complete, what may look different, and where to get help. Provide short role-specific instructions instead of one long generic manual. Employees may need to register authentication methods, sign in again, recreate a mobile profile, find team files in a new location, or learn when to use OneDrive versus SharePoint.

Warn users about migration-themed phishing. Attackers may exploit an expected password reset or sign-in request. State which messages are legitimate, what sender and URL to expect, and how employees should verify a request before entering credentials.

13. Cut over in a controlled window and validate

Freeze changes that would make the source and target diverge, complete the final synchronization supported by the migration method, update approved DNS records, and work through the acceptance checklist. Watch both environments while DNS and client behaviour settle.

• Confirm the public MX, Autodiscover, SPF, DKIM, and DMARC state matches the approved design.
• Send inbound and outbound tests through more than one external provider.
• Check mail queues, bounces, forwarding, aliases, groups, and shared resources.
• Validate priority executives, customer-service addresses, accounting, and automated applications.
• Confirm migrated file access and permissions with representative users.
• Track issues, owner, severity, workaround, and expected update time in one place.
• Do not decommission the source because the first test email succeeded.

14. Configure retention, backup, and recovery

Migration is not a recovery strategy. Decide how the business will recover from accidental deletion, malicious deletion, ransomware, misconfiguration, and the loss of an account or site. Microsoft 365 includes service-specific retention and recovery features, and Microsoft also offers Microsoft 365 Backup for supported workloads. The right design depends on required recovery points, recovery time, retention, coverage, administrative separation, and budget.

Microsoft’s June 23, 2026 Microsoft 365 Backup FAQ documents specific retention and restore behaviour, including scenarios involving deleted users. Treat those details as product conditions to verify—not a substitute for a business recovery requirement. Define what must be recoverable, for how long, by whom, and how restoration will be tested.

15. Stabilize, document, and retire the source

Keep a support period after cutover. Review migration reports and failed items, resolve duplicate or missing content, update application settings, remove temporary permissions, and help users adopt the target workflow. Measure unresolved tickets, mail-flow errors, sign-in failures, file-access problems, and user feedback.

Decommission the former service only after the business has accepted the migration, required data is verified, retention and backup are operating, ownership is documented, billing dependencies are understood, and a final export or preservation step is complete. Remove stale DNS, connectors, credentials, forwarding, and administrator access so the old environment does not become an unmonitored security risk.

A realistic small-business migration timeline

A very small, simple email migration may be completed quickly, while a multi-site organization with large file shares, legacy applications, regulated data, or complex permissions may need several phases. User count alone does not determine effort; dependencies and data quality usually matter more.

Common Microsoft 365 migration mistakes

• Changing the MX record before every required mailbox and address exists.
• Assuming an IMAP migration includes calendars, contacts, rules, and delegate access.
• Copying file-server permissions and folder structure without redesigning ownership.
• Enabling strong security after cutover instead of testing it with the pilot.
• Forgetting printers, websites, scanners, service accounts, and business applications.
• Using one person’s mobile number or personal email as the only administrator recovery path.
• Cancelling the source service before reports, backups, and important historical data are verified.
• Treating employee communication and training as optional.

When to hire a Microsoft 365 migration consultant

Professional support is useful when the business has multiple domains, Google Workspace, Exchange Server, another Microsoft 365 tenant, complex file permissions, large mailboxes, legacy applications, security or compliance requirements, limited internal IT capacity, or a cutover that cannot interrupt customer service.

A useful Microsoft 365 consulting engagement should produce a source inventory, target design, licensing map, data and privacy decisions, migration method, pilot, cutover and rollback plan, security baseline, acceptance report, and operational documentation. The deliverable is a stable environment the business can manage—not simply copied data.

The bottom line

A Microsoft 365 migration succeeds when employees can communicate, find information, collaborate safely, and recover from mistakes after the project team leaves. That requires attention to identity, data, permissions, security, privacy, DNS, devices, and people—not only transfer speed.

For a Toronto small business, the best next step is a scoped discovery session. Count the users and data, identify critical workflows, confirm the source systems, and decide what the target should improve. With that foundation, the checklist becomes a controlled plan instead of a stressful weekend.