Data Migration: How It Works, From A to Z

Switching mail platforms or hosting providers is intimidating for one reason: the fear of losing emails, contacts or years of calendar during the cutover. The good news is that a well-prepared data migration happens with no loss and no downtime your users can see. The secret isn't speed, it's method — a serious audit, a target provisioned in advance, a copy running in the background, then a controlled DNS cutover.

What actually gets migrated (and why people switch)

We talk about "data migration" as one thing, but it's really several very different data sets, each of which needs the right tool:

• Emails and the folder tree — the bulkiest part, often tens of gigabytes per mailbox, with subfolders, labels and read/unread state to preserve.
• Contacts — personal address books and shared lists, exportable as CSV or vCard.
• Calendars — past and future events, invitations, recurring series, shared team calendars.
• Files — Google Drive, OneDrive, SharePoint or a plain network share, with their hierarchy and sharing permissions.

People usually switch to cut licensing costs, unify a team on a single suite, leave an ageing server behind, or gain better collaboration tools. Whatever the reason, the goal is always the same: the user finds everything again, exactly as before, in their new environment.

Step 1 — The audit: take inventory before touching anything

No serious migration begins without an inventory. List every mailbox and its real data volume (a 2 GB mailbox and a 45 GB one don't migrate at the same pace). Note the number of shared folders, aliases, distribution lists and service accounts. Then pinpoint the most sensitive item: the domain. Who manages the DNS zone? Where do the MX records point today? What is the TTL on those records? Lowering the TTL to 300 seconds a few days before cutover makes switch-over nearly instant on the day.

Step 2 — Provision the target

Before you copy anything, the destination has to be ready. That means: creating the tenant or organization, buying the right number of licenses, creating each user account with its final address, preparing groups and aliases, and checking mailbox quotas. Add and verify the domain on the target side now (via the TXT verification record) — this doesn't redirect email yet, but it authorizes the platform to accept your domain when the time comes. Provisioning ahead gives you room to make mistakes without ever touching production.

Step 3 — Migrate the emails (IMAP or a native tool)

This is the heart of the project. There are two broad approaches, depending on source and target:

• To Google Workspace: the built-in Data Migration Service (DMS) in the admin console copies email from an IMAP, Gmail or Microsoft 365 source straight into the target mailboxes.
• To Microsoft 365: depending on volume, you use an IMAP migration (ideal for third-party servers), a cutover or staged migration from Exchange, or a hybrid migration for large on-premises Exchange estates.
• By export/import: when no server-to-server connection is possible, you export to PST (Outlook/Exchange), MBOX (Thunderbird, many Linux servers) or via Google Takeout, then re-import into the target.

In every case, the first sync is a full copy, then you re-run incremental passes that only recopy new messages — that's what lets you migrate without freezing the mailboxes.

A successful migration goes unnoticed: the user logs in the next morning, everything is there, and nothing stopped overnight.

Step 4 — Move the files

Files follow their own path. For a Drive ↔ OneDrive/SharePoint move, you must preserve the folder tree, the owners and above all the sharing permissions, often the trickiest point. Tools such as the SharePoint Migration service or Drive connectors handle the bulk copy. Do the large volumes first in the background, then the active files just before cutover to capture the latest versions.

Step 5 — Cut over the DNS/MX with no downtime

Once the mailboxes are synced, you change the MX records to point at the new platform, then update SPF, DKIM and DMARC to keep good deliverability. Thanks to the TTL lowered earlier, propagation is quick. For a few hours you're in coexistence: old servers may still receive messages, which a final incremental pass pulls across. No email is lost — it's simply delivered with a slight delay while propagation completes.

Step 6 — Verify and configure the clients

The migration isn't done until it's verified. Check a sample of mailboxes: message counts, folders, contacts and calendar events present. Then reconfigure clients: recreate the Outlook profile, re-add accounts on mobile, rebuild signatures and rules on the target. Warn users that a local re-index may take a while.

Common pitfalls to anticipate

• Rate limits — APIs enforce quotas; a large migration spreads over several days, that's not a bug.
• Duplicates — re-running a tool without proper resume can recopy messages; always use incremental passes.
• Sharing permissions — they don't always carry over automatically between Drive and SharePoint: re-check them.
• Recurring calendars — recurrence rules and time zones can shift; verify a few series afterwards.

How much it costs: Yuna7 vs an IT contractor

Having an IT contractor migrate Ancien to Nouveau often costs several hundred dollars, with quotes and lead times. Yuna7 automates the cutover and you only pay for what you actually use — you can even try it for free.

Let Yuna7 migrate Ancien to Nouveau for you

Describe your migration in one sentence — "move my mailboxes and files to my new suite" — and Yuna7's AI handles the rest: it audits what exists, provisions the target, transfers email and files, cuts over the DNS and verifies the result, asking you to approve each sensitive step. You stay in control from start to finish, for far less than the cost of a technician.