Office 365 Email Migration: The Complete Destination Guide

Office 365 email migration isn't one job. It's four different jobs wearing the same name. Microsoft calls them cutover, staged, hybrid and IMAP migration, and picking the wrong one is the single most expensive mistake I see clients make. Usually because someone read one blog post and assumed their five person agency needed the same approach as a 2,000 seat enterprise. Get the type right first. Everything else, the DNS, the licensing, the timing, follows from that choice.

Which Office 365 migration type actually matches your situation?

Cutover migration is for small organisations moving everything from an existing Exchange server in one go. You move every mailbox at once, over a weekend usually, and you're done. Microsoft caps how many mailboxes this method comfortably handles, so it suits smaller estates, not because of some hard technical wall but because the coordination gets messy past a certain headcount.

Staged migration is for larger Exchange environments that need to move in batches over weeks rather than one weekend. You migrate a group, let them settle, migrate the next group. This is the right call when you can't take the whole company offline at once and IT needs to support two systems in parallel for a period.

Hybrid migration is different again. This is a genuine long running coexistence between an on premises Exchange server and Microsoft 365, not a temporary state on the way to somewhere else. Some organisations run hybrid permanently because regulatory or infrastructure reasons keep certain mailboxes on premises indefinitely. It's the most complex option and the most over prescribed one, because plenty of consultants default to hybrid when a staged migration would have done the job in a fraction of the time.

IMAP migration is the plain one. If your mail isn't sitting in Exchange at all, if it's coming from a generic IMAP provider, a reseller inbox, or a hosting company's basic mail product, this is your route. It copies mail only, not calendars or contacts, which is worth knowing before you promise users a seamless move. Run your source setup through the email migration checker before you commit to a method, because half the pain in these projects comes from assumptions about what the source system actually supports.

For the general sequence that applies across all four types, our email migration guide and the accompanying email migration checklist cover the groundwork. Microsoft's own comparison of these methods is worth reading directly rather than trusting a summary, and their mailbox migration advice page is the current authority on which method suits which tenant size, since Microsoft changes eligibility thresholds and UI more often than most third party guides keep up with.

Why is a GoDaddy to Microsoft 365 migration harder than it looks?

This deserves its own section because it's genuinely awkward in a way that catches people out. If you bought Microsoft 365 through GoDaddy, your mailboxes don't live in a tenant you control. They live in a tenant GoDaddy administers as the reseller. So the job you actually need isn't a simple mailbox copy inside one Microsoft 365 environment, it's a tenant to tenant migration, moving mail from a Microsoft tenant you can't fully administer into one you own outright.

That distinction changes both the tooling and who has to sign off. A cutover or staged migration inside Exchange Online assumes admin access to a single tenant. Tenant to tenant migration needs domain transfer, a period where the domain has to be removed from the old tenant before it can be added to the new one, and coordination with GoDaddy support to release the domain and any associated mailboxes on their side. Clients who treat this as a normal migration lose time waiting on support tickets they didn't know they needed to raise.

I've seen this go wrong the same way twice. A client assumes they can just export and reimport, starts the process without checking who owns the tenant, and ends up locked out of their own domain for a stretch while GoDaddy support processes the release. Plan the domain handoff before you plan the mailbox copy, not after.

If part of the decision is whether Microsoft 365 is even the right destination for a personal or small business domain currently sitting with GoDaddy, read our separate piece on GoDaddy Microsoft 365 alternatives for personal domains first. That covers the choose a destination question properly, so I won't repeat it here.

How do you verify your domain in the Microsoft 365 tenant?

Before anything else moves, the tenant needs to prove it owns the domain. Microsoft gives you a TXT record to add at your DNS host, and until that record is published and detected, the tenant treats the domain as unverified and won't let you use it for mailboxes. This step trips people up mainly because they're editing DNS at one provider while the domain's actual nameservers point somewhere else entirely, a common leftover from registrar and hosting being split across different accounts. Check where your DNS is actually authoritative before you add anything, and confirm the record has propagated using the MX record lookup tool once you get further along, since that same tool doubles as a general sanity check on what your domain is currently telling the world about its mail setup.

When should you provision licences, and does the order matter?

Yes, the order matters more than people expect. Licences need to exist and be assigned before mailboxes get created in the tenant, not the other way round. I've watched migration timelines slip by days because someone queued up the mailbox migration batch before procurement had finished assigning the right licence tier, and the batch simply sat there failing silently rather than throwing an obvious error. If you're running a staged migration across departments, assign licences per batch ahead of that batch's migration window, not all at once at the start, so you're not paying for seats sitting idle for weeks while later batches wait their turn.

How does the mailbox copy itself actually run?

Once verification and licensing are sorted, the actual data movement is the least dramatic part of the whole project, which surprises people who expected the technical copy to be the hard bit. For cutover and staged migrations from Exchange, Microsoft's tools connect directly to the source server and pull mailbox content across in the background while users keep working. For IMAP sources, the process is slower and more literal, since it's copying folder structures over a protocol that was never designed with speed in mind, so budget more time for larger mailboxes with years of retained mail. Microsoft's own mailbox migration documentation is the right place to check current batch limits and supported source versions, because those details shift with product updates in a way no third party guide can promise to track in real time.

How do you switch MX to Microsoft without breaking mail flow?

The MX record is the switch that tells the internet where to actually deliver your mail, and this is the step people rush because it feels like the finish line. It isn't. Do the mailbox copy first, confirm mail is landing correctly in the new tenant, and only then change MX at your DNS host to point at Microsoft's mail exchange endpoint. Change it too early and new mail starts arriving in a tenant that hasn't finished receiving the historical archive, which creates the exact kind of confusion, missing threads and support tickets, that make a migration look botched even when the underlying copy worked fine. Run the domain through the MX record lookup before and after the change to confirm propagation, and keep TTL low on the record in the days beforehand so the switch actually takes effect quickly rather than dragging on for the length of whatever TTL was previously set.

How do you set up DKIM and SPF, and where does it go silently wrong?

This is where most Office 365 migrations quietly break authentication without anyone noticing until deliverability drops. Two separate things need attention here, and they behave differently to what most people expect if their only prior DKIM experience was manual setup.

DKIM first. Microsoft doesn't hand you a single TXT record with a key in it the way most self managed DKIM setups work. It publishes two CNAME records that your domain needs to point at Microsoft's own DKIM key infrastructure. If you're used to pasting a long TXT value into your DNS panel, this catches you out, because there's no key to paste. You're adding CNAMEs, not a TXT record, and missing that distinction is one of the more common support requests I see from teams doing their first Microsoft 365 migration. The DKIM generator is useful for checking your final record format once published, even though the values themselves come from Microsoft's admin centre rather than being something you generate yourself for this particular destination.

SPF is the genuinely dangerous one. Adding Microsoft's SPF include alongside whatever your previous mail provider required is exactly the moment domains cross the ten DNS lookup limit that RFC 7208 sets for SPF evaluation. The failure mode here isn't obvious. It doesn't produce a clear error that a normal person would notice. It produces permerror, which receiving mail servers frequently treat as equivalent to having no SPF record at all, quietly undermining deliverability while your SPF record still technically exists and looks fine to the naked eye. This is exactly the scenario where teams keep the old provider's include mechanism in the record long after they've stopped using that provider, because nobody remembered to remove it during the Microsoft 365 cutover. Audit the full include chain rather than just adding Microsoft's entry on top, and use the SPF generator to rebuild the record clean rather than layering another include onto an already crowded one. Once SPF and DKIM are both correct, add or update a DMARC record to actually enforce the alignment between them, since a correct SPF and DKIM setup without DMARC still leaves the door open for spoofing on your domain.

What else changes when the mail server itself moves?

If this migration is happening as part of a broader move away from your current web host, not just a mail provider swap, the mail changes are only one piece of a bigger DNS reshuffle. Website records, other subdomains and any other services hanging off the same zone all need the same care that mail gets here. Our separate guide on site migration without losing SEO covers the host only side of that move in detail, and it's worth reading in parallel if your Microsoft 365 migration is happening alongside a hosting switch rather than in isolation.

Frequently asked questions

How long does an Office 365 email migration take?

It depends entirely on migration type and mailbox size rather than anything fixed. A small cutover migration for a handful of mailboxes can be done over a weekend, while a staged migration across a larger Exchange estate is deliberately spread over weeks. IMAP migrations from older mail systems tend to take longer per mailbox than Exchange based methods, simply because the protocol is slower at moving large volumes of stored mail.

Do I need to keep the old email provider active during migration?

Yes, until you've confirmed the mailbox copy is complete and MX has been switched and verified. Cancelling the old provider before mail flow has fully cut over is one of the more common ways migrations turn into support emergencies, particularly with IMAP sources where the copy process runs slower than people expect.

Can I migrate email without downtime?

Largely yes, if the sequence is followed properly. Mailbox content is copied in the background before MX changes, so users keep sending and receiving mail on the old system right up until the switch. The main risk to a clean cutover is changing MX before the mailbox copy has actually finished, not the migration method itself.

What's the difference between GoDaddy Microsoft 365 and buying Microsoft 365 directly?

Mailboxes bought through GoDaddy sit in a tenant GoDaddy administers as reseller, not one you control outright. Moving away from that setup is effectively a tenant to tenant migration involving domain transfer and reseller sign off, which is a different and more involved process than migrating mailboxes within a tenant you already own.

Final thoughts

Most Office 365 migration failures I get called about aren't technical failures at all. They're sequencing failures: MX changed too early, SPF layered on top of an old provider's record instead of rebuilt, licences assigned after mailboxes rather than before. Get the migration type right for your situation, do the domain and DNS work in the correct order, and treat the GoDaddy scenario as the tenant transfer it actually is rather than a normal copy. That discipline matters far more than which tool you use to do the copying.