Cloud & Data Migration Services

The four migrations small businesses actually run

Almost every migration project we handle for a 5–40 person firm falls into one of four shapes, each with its own failure modes:

• File server to SharePoint or Google Drive. The aging Dell in the closet, or a Synology NAS, moving to cloud libraries. The hard part is never the copy — it’s untangling fifteen years of folder permissions and deciding what deserves to survive.
• Email to Microsoft 365 or Google Workspace. From POP/IMAP hosting, GoDaddy email, an old on-prem Exchange, or between the two suites. DNS timing and mobile device re-enrollment are where these go sideways.
• On-prem application to SaaS. Desktop QuickBooks to QuickBooks Online, an Access database to a proper line-of-business app, a local practice-management install to its vendor’s hosted version. Data mapping and report parity are the risks.
• Tenant-to-tenant. Mergers, rebrands, or escaping a tenant an old IT guy set up under his own account. The least visible type and the most intricate — mail, files, Teams chats, and OneNote all move on different tools with different fidelity.

The sequence that avoids disasters

Every clean migration we’ve run follows the same five-stage order. Every rescue job we’ve inherited skipped at least one stage.

1. Inventory. Count mailboxes and their sizes, measure file data (real data, not disk size), list shared mailboxes, distribution lists, aliases, service accounts that send mail (scanners, the alarm system, invoicing software), and every device that will need reconfiguration. The scanner-to-email copier is forgotten in roughly half of DIY migrations.
2. Pilot group. Move 2–4 people first — ideally one skeptic and one power user. They surface the surprises: the Outlook plugin that breaks, the shared calendar nobody documented, the mapped drive a spreadsheet’s links depend on.
3. Staged cutover. Pre-sync the bulk of the data days ahead, then flip over a weekend with only a small delta left to copy. For email this means a final incremental pass after the MX change; for files it means the old location goes read-only before the last sync so nothing changes underneath you.
4. Verification. Compare item counts and spot-check, don’t assume. Ten mailboxes checked for folder counts, a dozen files opened from deep paths, the scanner sending a test page, calendar invites round-tripping externally.
5. Decommission — later. The old server or tenant stays read-only for 30–60 days as a safety net, then gets a final archive image before it’s wiped or the subscription is cancelled. Decommissioning on day one removes your only rollback.

Email migration specifics

Three approaches, chosen by size. A cutover migration moves everyone at once — right for under ~50 mailboxes, which covers nearly every business we serve. A staged migration moves batches over weeks and only matters for larger orgs. A hybrid keeps on-prem Exchange and the cloud coexisting; for a small business it’s almost always unnecessary complexity left over from enterprise playbooks.

The moment of truth is the MX record change. Before the cutover we drop the DNS TTL to 300 seconds (from the typical 3600 or 86400) a day or two ahead, so the change propagates in minutes instead of hours. Mail sent during propagation isn’t lost — sending servers retry for up to 48 hours — but a low TTL shrinks the window where mail lands in the old system. SPF, DKIM, and DMARC records get staged in advance so the new platform’s mail doesn’t start life in recipients’ spam folders.

What users notice, honestly: Outlook builds a new profile and spends a few hours re-caching (recent mail appears first), phones need the account re-added, autocomplete address lists sometimes reset, and any rules stored client-side need recreating. What they should never notice: lost mail, broken calendar invites, or missing folders. We schedule cutovers Friday evening so caching happens over the weekend.

File migration gotchas

File moves look trivial — it’s a copy, right? — and hide the most landmines:

• Path length limits. SharePoint caps the full URL around 400 characters, and legacy Windows tooling chokes at 260. Old file servers with folders like Clients2019Smith & Sons ConstructionCorrespondenceInsurance Renewal DocumentsScanned Copies blow past both. We flatten and rename before the move, not after it fails.
• Permissions don’t map 1:1. NTFS permissions with nested AD groups, deny entries, and per-file exceptions have no clean SharePoint equivalent. Attempting a faithful translation produces an unauditable mess; the right move is designing a simpler group-based model and mapping data into it.
• Metadata and timestamps. A drag-and-drop copy stamps every file with today’s date and the admin as author. Purpose-built tools (SharePoint Migration Tool, Movebot, Google’s migration service) preserve created/modified dates — which matter for retention, sorting, and “which version is newer” disputes.
• Orphaned owners. Files owned by accounts of people who left in 2017 can fail to transfer or land inaccessible. The inventory phase flags them so ownership is reassigned first.

Realistic downtime, coexistence, and rollback

Plan for a coexistence period rather than pretending it away. For two to four weeks people will occasionally need something from the old system — a mail rule they forgot, a template buried in an odd folder. Keeping the source read-only and reachable turns those moments into a two-minute fetch instead of a crisis. Rollback planning is the same idea formalized: before cutover we write down the exact conditions that would trigger reverting (mail flow broken past a defined hour, data integrity failures in verification) and the exact steps — usually just repointing MX back, since the source was never destroyed.

Finally, the reason “just copy everything” migrations fail: garbage in means garbage in the cloud, now with per-gigabyte consequences. Moving 900 GB when 300 GB is live data slows the transfer, blows through storage quotas, and recreates the same unfindable mess in a new location. Our archive-first approach moves anything untouched for 24 months into a cold archive library — still searchable, still restorable, but out of everyone’s way. Post-migration validation then checks a fixed list: item counts within 1% of source, spot-opened files from every top-level library, permissions tested with a non-admin account from each department, mail flow verified inbound and outbound, and every device that prints, scans, or sends confirmed working.

Frequently asked questions

Will we lose email during the switch?

No. Sending mail servers retry delivery for up to 48 hours, so mail sent while DNS propagates is delayed at worst, not dropped. With TTLs lowered ahead of time, the delay window is typically minutes. Historical mail is pre-synced before cutover, so it’s waiting in the new mailbox on Monday morning.

Can we keep working during a file migration?

Yes, until the final sync. The bulk copy runs in the background against live data; only the last delta pass requires the old location to go read-only, which we schedule for a weekend. By Monday, shortcuts and mapped paths point at the new libraries.

Should we clean up files before migrating or after?

Before — but shallowly. Deep manual sorting stalls projects for months. The practical rule: archive everything untouched for 24 months automatically, fix folder names that break path limits, and delete only obvious junk (old installers, duplicate “Copy of Copy of” files). Fine-grained cleanup is easier in the new system, where search actually works.

What happens to the old server or tenant afterward?

It stays read-only for 30–60 days as the rollback safety net and reference copy. After that we take a final archive image, then wipe drives (or delete the tenant) and cancel the associated licensing, support contracts, and any static IP or domain services tied to it. Skipping the archive step is the most regretted shortcut in migrations.