Planning a Microsoft 365 Migration in Annapolis: A Practical Guide

Annapolis businesses run on a mix of old and new IT that would surprise outsiders. Firms that work alongside state government carry email retention obligations most small companies never think about. Maritime businesses along the waterfront have crews and brokers working from boats, yards, and phones, not desks. Associations and lobbying shops headquartered near the State House live and die by their calendars. And plenty of established firms are still running an aging on-premises Exchange server in a closet, or a legacy email host they outgrew years ago.

Microsoft 365 is where most of them are headed, and for good reason: email, files, Teams, and security tooling in one subscription, reachable from anywhere. But the migration itself is where things go wrong. Done well, users leave Friday on the old system and start Monday on the new one with everything where they left it. Done badly, mail bounces for two days and the managing partner's calendar vanishes.

Here is the plan we expect any competent provider to follow, phase by phase, with the gotchas called out.

Phase 1: Assessment (before anyone buys a license)

Every failed migration we have been asked to rescue skipped or rushed this phase. The assessment inventories what actually exists:

• Mailboxes: every user mailbox, plus the ones people forget: shared mailboxes (info@, billing@), distribution lists, resource calendars for conference rooms, and mailboxes of former employees that someone still checks.
• Mailbox sizes and PST files: a 49 GB mailbox and a decade of PST archives scattered across laptops both change your timeline. PSTs on local drives are invisible to server-side migration tools; they have to be found and ingested deliberately.
• Where files live: file server shares, Dropbox, Google Drive, old SharePoint. Decide what moves to SharePoint and OneDrive, what gets archived, and what dies.
• What else touches email: scanners and copiers that email PDFs, line-of-business software that sends invoices, website contact forms, alarm systems. Each of these authenticates somewhere and will silently break at cutover if nobody reconfigures it.
• Who controls the domain: confirm you have working logins for your DNS registrar before migration week, not during it. This is the single most common day-of emergency.

Phase 2: Licensing decisions

Microsoft's small-business tiers differ more than the price list suggests. Business Basic gives you web apps only; Business Standard adds the installed Office desktop apps most staff expect; Business Premium adds the security layer (device management, advanced phishing protection, conditional access) that firms handling state contracts or client financial data should treat as the floor, not an upgrade. Mixing tiers by role is normal and saves real money: the warehouse or dock crew rarely needs what the front office needs.

Two localized notes. First, organizations working with government clients sometimes assume they need the government cloud (GCC); most private firms do not, and it costs flexibility, so make that decision on actual contract requirements, not vibes. Second, if your firm has retention obligations tied to public-sector work or litigation holds, decide your retention policy configuration during this phase so mail is governed from day one. Getting comparable quotes on licensing and migration labor is exactly what a structured RFQ process is for.

Phase 3: Prepare the tenant and pilot

Before any data moves, the destination gets built: the Microsoft 365 tenant, verified domains, user accounts, security baseline (multi-factor authentication enforced from the start, admin accounts separated from daily-driver accounts), and the SharePoint structure files will land in.

Then pilot with a small, tolerant group: five to ten users, ideally including one power user with a huge mailbox and one person from each department. The pilot surfaces the surprises (that one calendar with 15 years of recurring meetings, the folder permissions nobody documented) while they are cheap to fix.

Phase 4: Migration waves and the cutover weekend

For most businesses under about 150 seats, the pattern is: pre-stage the data over one to two weeks (initial sync of mail and files happens in the background while everyone keeps working), then pick a cutover window, almost always a Friday evening, when MX records switch and mail starts flowing to Microsoft 365.

The gotchas that bite at cutover, in rough order of frequency:

• DNS TTLs left long. Lower the time-to-live on your MX and related records days in advance, or the old server keeps receiving mail for hours after the switch.
• Autodiscover remnants. Old DNS records or an old server still answering Autodiscover will point Outlook at the dead system. This is the classic "my Outlook keeps asking for a password" Monday.
• SPF, DKIM, and DMARC not updated. Skip these and your invoices start landing in customers' spam folders, which you will discover slowly and painfully.
• Devices and apps that send mail. The copier, the practice-management system, the website form: each needs new settings, and modern authentication requirements mean the old username-and-password trick often no longer works at all.
• Mobile phones. Every user's phone needs the new account. Plan for the Monday-morning line at the office manager's desk, or better, get ahead of it with written instructions and a drop-in help hour.

Phase 5: The two weeks after

Cutover is not the finish line. The provider should stay in hypercare mode: verifying mail flow both directions, chasing down stragglers whose Outlook profiles need rebuilding, completing PST ingestion, confirming backups of the new environment are running (Microsoft's built-in retention is not a backup), and decommissioning the old server only after everything is verified, never the same weekend.

This is also when training lands best, because people have real questions. An hour on Teams, OneDrive sharing, and phishing-report buttons does more good in week two than any amount of pre-migration documentation.

Who should run this?

A migration is a project, with a timeline, dependencies, and a hard cutover date, and it deserves real project management rather than a best-effort side task. If you already have an MSP, ask them to walk you through their plan against the phases above; gaps in their answer are gaps in your weekend. If you are choosing a provider partly on the strength of this project, that is a matching problem, and it is the one our MSP broker service exists to solve. Nonprofits planning the same move should also read our note on nonprofit licensing discounts first, because Microsoft's nonprofit grants change the licensing math entirely.