Email Migration Services: DIY or Hire a Specialist

An email migration service moves mailboxes, calendars, contacts and often archived mail from one platform to another (Exchange to Google Workspace, on-prem to Microsoft 365, one hosting provider to another) without dropping messages, breaking authentication, or taking the business offline. Whether you pay for one or do it yourself comes down to mailbox count, data volume, and how much downtime you can stomach. It has nothing to do with how technical the person doing it feels.

What does an email migration service actually do?

A proper migration service handles four things: the sync tool that copies mail from source to destination, the DNS cutover that points mail flow at the new system, the authentication rebuild (SPF, DKIM, DMARC) so the new sender is trusted, and the cleanup afterwards so nothing gets left half-migrated. Most DIY attempts I see fail at step three. People copy the mailboxes fine and then wonder why half their outbound mail lands in spam a week later, because nobody touched the MX record properly or rebuilt SPF for the new sending IPs.

The mailbox copy is the easy 60% of the job. The DNS and authentication work is the harder 40%, and that's where most self-service migrations quietly go wrong.

Can you migrate email yourself, or do you need to pay someone?

Under roughly ten mailboxes on a mainstream provider, with one domain and nothing unusual in the setup, a competent admin can do this in an afternoon using a tool like imapsync and a proper checklist. I've had clients do exactly that with no complaints. Run your domain through our email migration checker first, it flags the obvious traps (aliases, forwarding rules, catch-alls) before you start copying anything.

The honest line is this: mailbox count alone rarely decides it. It's what sits around the mailboxes that pushes a job from a weekend project to something you hire out.

What pushes a migration from DIY to professional territory?

Watch for these, because any one of them changes the calculation:

• Shared mailboxes and calendars. Permissions and delegate access rarely survive a naive copy, and rebuilding them by hand across dozens of shares is where whole weekends vanish.
• Public folders. These are the single biggest source of failed migrations I've seen. They were never designed to be portable and most sync tools handle them badly.
• Legal or regulatory retention. If a compliance officer needs to sign off on chain of custody for archived mail, this is not a job for a weekend and imapsync.
• Multiple domains under one tenant. Every additional domain adds its own DNS records, its own SPF entry, its own routing quirks.
• Mailboxes over roughly 50GB. Large mailboxes take longer to sync, are more likely to hit throttling limits on the source or destination, and are far more painful to redo if the first attempt fails partway.
• No tolerance for downtime during business hours. If mail can't pause even briefly, you need someone running a staged cutover with a rollback plan, not a single all-at-once switch.

If two or more of these apply, stop calling it a DIY job. Call it a project.

How do email migration companies price their work?

There are three honest pricing models, and each one tells you something about the provider.

Per mailbox pricing scales with headcount and is common for straightforward Google-to-Microsoft or Microsoft-to-Google jobs where every mailbox is roughly the same shape. It gets expensive fast if your mailboxes are wildly uneven in size, because you're paying the same rate for a 2GB mailbox and a 60GB one.

Flat project fees turn up where the provider has scoped the whole job upfront, including public folders, shared resources, and DNS work, and is willing to carry the risk of it running over. This is usually the better model for anything with the complexity flags above, because it forces the provider to scope the job properly before quoting rather than guessing.

Hourly billing shows up most often with generalist IT support rather than specialists. Fine for small, well-defined jobs, but a genuine risk on anything with public folders or legacy retention rules, where the hours can balloon in ways nobody predicted.

None of these models is inherently the honest one. The dishonesty shows up in what's included, not in which model is used.

What should a quote actually include?

A quote that's just a single number tells you nothing. Before you sign anything, get clarity on:

• Whether the sync tool licence is included in the price, or whether you're expected to buy that separately.
• Whether the quote covers only the mailbox copy, or also the authentication rebuild (SPF, DKIM, DMARC) and the actual DNS cutover.
• Who is on call during the cutover window, and what happens if something breaks at 6pm on the day.
• What the rollback plan is if the migration needs to be reversed partway through.
• Whether retesting failed mailboxes after the first pass is included or billed separately.

A provider who quotes a single flat figure with no breakdown of these points hasn't scoped your job properly. They've priced a generic migration and hoped your setup matches it.

What questions should you ask a provider before signing?

Ask these directly, and pay attention to the answers you get back, not just whether they answer at all:

• "What is my current SPF lookup count?" Anyone who has actually scoped your domain will know this or check it live. SPF has a hard lookup limit, and migrations that add a new sending platform without checking this can silently break authentication for everyone. If they can't answer, they haven't looked at your DNS.
• "What is my current MX TTL?" A high TTL means mail can keep routing to the old system for hours after cutover. A provider who hasn't checked this hasn't planned the cutover window properly. Check it yourself with our MX record lookup before the call, so you know if their answer is right.
• "What happens to mail that arrives mid-migration?" A good answer involves dual delivery or a queuing mechanism. A bad answer is a shrug.
• "Can you show me a migration plan document before I sign?" If they can't produce one, they haven't built one, and you are the plan.

A provider who hasn't asked you about your SPF lookup count or your MX TTL before quoting hasn't properly scoped the job. That's not a minor gap. It's the difference between a migration that works and one that quietly breaks deliverability for weeks afterwards.

What does a proper cutover look like on the day?

A well-run cutover is boring, which is the point. Mail is synced in advance so the cutover window only has to catch the last few hours of delta changes. DNS changes go out with the TTL already lowered days ahead, so propagation is fast rather than dragging on. Someone is actively monitoring mail flow on both old and new systems for a defined window, not just "on standby." And there's a documented, tested rollback path: if the new system throws unexpected errors, mail keeps flowing through the old one while the issue gets fixed, rather than everyone finding out the hard way that inboxes are down.

If a provider describes cutover as "we flip the DNS and it should be fine within a few hours," that's not a plan. That's optimism.

How do you choose between a specialist and a generalist provider?

A dedicated email migration specialist is usually the right call for anything with public folders, multiple domains, or regulatory retention requirements, because that's their whole job and they've almost certainly hit your exact edge case before. A broader managed service provider makes more sense if the migration is one part of a wider infrastructure move and you want a single point of contact for everything, not just the mailboxes. If you run an agency managing this for clients rather than for yourself, our agencies section covers how to structure that relationship so you're not personally on the hook for someone else's DNS mistake.

Either way, get more than one quote. HostList's Agency Arena lets you post the brief once and have matched providers pitch you directly, a faster way to compare like-for-like quotes than ringing round individually. You can also browse providers directly in our directory if you already know roughly what you're looking for. For a fuller walkthrough of the migration process itself, our email migration guide covers the mechanics step by step. And if pricing structures across IT services generally confuse you, Managed IT Services Pricing: The Four Models Explained breaks down the same per-unit, flat-fee, and hourly patterns you'll see quoted here.

Do you need a specialist for regulated industries?

Yes, generally. If retention rules govern how long mail must be kept and in what form, a generalist provider without direct experience in your sector is a genuine risk, not a cost saving. This comes up constantly in law firms, where chain of custody for archived correspondence is not optional. If that's your situation, read Managed IT Services for Law Firms: The Real Checklist alongside this piece, because the vetting questions overlap heavily with what's above. Google's own migration documentation and Microsoft's mailbox migration advice are worth reading even if you're hiring someone else, because it means you can tell whether the provider actually knows the platform or is winging it.

Frequently asked questions

How long does a professional email migration take?

It depends entirely on mailbox size and count rather than a fixed timeline. Small, straightforward migrations can complete in a day. Anything with large archives, public folders, or multiple domains typically runs across several days, with the mailbox sync happening in the background well before the actual cutover window.

Will I lose email during the migration?

You shouldn't, if the provider syncs mail in advance and handles the cutover with a proper delta sync for anything that arrives right up to the switch. Mail loss during migration is almost always a sign of a rushed, single-pass sync rather than an unavoidable part of the process.

Can I migrate email without any downtime at all?

Mostly, yes, with the right approach. Downtime usually comes from DNS propagation delays rather than the mailbox copy itself, and those delays can be minimised by lowering the MX record TTL well ahead of the cutover date. Any provider promising zero downtime should be able to explain exactly how they're managing that propagation window.

What is the difference between an email migration service and a general IT support provider handling it?

A dedicated migration specialist has done your exact scenario repeatedly and has tooling built around it. A general IT provider can handle simple migrations perfectly well, but on anything with public folders, shared calendars, or retention requirements, ask directly how many similar migrations they've completed rather than assuming competence carries across.

Should you switch to a professional service

If your setup is small, clean, and on a mainstream platform, do it yourself with a checklist and a proper sync tool, and save the money. The moment shared resources, public folders, retention rules, or business-hours uptime enter the picture, hire someone who has scoped the job properly, meaning they've already asked about your SPF lookup count and your MX TTL before quoting a price. That single question is the fastest way to separate a real specialist from someone guessing.