Hire me

Email migration service

A website move often exposes a hidden dependency: email is hosted on the same account. Changing nameservers or closing the old hosting package without mapping mailboxes first can cause lost messages, authentication failures or a sudden break in incoming mail.

Sharjeel Tahir

By Sharjeel Tahir

WordPress & Technical SEO Specialist · Lahore, Pakistan

Get a quoteSee what’s included

What does this service cover?

The riskiest moment in an email migration is not the copying — it is the cutover, when new mail must start arriving at the new provider while nothing in flight is lost. That is why the transfer and the routing change are planned as one job, not two. Messages synchronize over IMAP while the old service stays live; authentication records are prepared for the new provider in advance; and the MX switch happens only after the destination mailboxes exist and have been tested.

The second risk is scope creep by assumption: undocumented aliases, old forwarders, a catch-all quietly receiving order notifications, or website forms still pointed at the old SMTP server. The opening mailbox inventory exists to surface those dependencies before they become surprises.

Mailbox inventory

I identify every mailbox, alias, forwarder and catch-all behavior that needs to exist on the destination. Storage usage is checked so large mailboxes do not fail halfway through transfer.

Message transfer

When both providers expose IMAP, mail can be synchronized while the old service remains live. This allows a final incremental sync around the MX cutover rather than relying on a single one-time copy.

DNS authentication

MX records route incoming mail, while SPF, DKIM and DMARC help receiving systems authenticate it. These records are recreated or updated for the new provider and checked for conflicts such as multiple SPF records.

Cutover checks

I test sending and receiving, confirm DNS resolution, validate authentication records and keep the old mailbox service available during the transition when the provider permits it.

What is the typical scope?

Every engagement starts from the same place: a clear, agreed list of what is included before any work begins.

  • Source and destination mailbox access
  • Folder mapping, quotas and synchronization
  • MX cutover and outgoing mail authentication

The exact scope is confirmed from the real site and problem before changes are made.

How does the work proceed?

  1. Inventory mailboxes: list every mailbox, alias, forwarder and catch-all on the source, plus storage sizes, so nothing is missed.
  2. Prepare the destination: create the same structure on the new provider and set MX, SPF, DKIM and DMARC for it.
  3. Synchronize messages: copy mail via IMAP while the old service stays live; large mailboxes transfer in stages.
  4. Cut over and verify: switch MX records, run a final incremental sync, and test sending and receiving on both ends.

What you need to provide

Most of the technical work is on my side. To start, I usually need:

  • Admin access (or credentials) for the source and destination mail systems
  • DNS management access for MX and authentication records
  • A list of mailboxes, aliases and forwarders, if you have one
  • A preferred low-traffic window for the MX cutover

Typical timelines

Small migrations with a handful of mailboxes complete in 2–4 days. Larger ones with multi-gigabyte mailboxes take 5–10 days because IMAP transfer speed depends on the providers; the cutover itself is scheduled, not rushed.

Frequently asked questions

Will I lose emails during the migration?

No. Mail is synchronized while the old service stays live, and a final incremental sync runs around the MX cutover. Old mailboxes remain accessible during the transition where the provider allows it.

How long until new mail arrives at the new provider?

MX changes propagate like other DNS changes — usually minutes to a few hours with lowered TTLs. Both old and new inboxes are monitored during the window.

Do contacts, calendars and folders migrate too?

Folders and messages migrate over IMAP. Contacts and calendars depend on the providers involved and are scoped separately, so nothing is assumed.

What happens to my old hosting email account?

It stays live until the cutover is verified, then it can be closed. I confirm mail flow on the new provider before anything is decommissioned.

Can you migrate from cPanel mail to Google Workspace or Microsoft 365?

Yes — that is a common job. The mailbox structure is recreated on the destination, messages sync over IMAP, and authentication records are set for the new provider.

What about email sent from my website's forms?

The website's SMTP or mail configuration is updated to the new provider as part of the cutover checks, and test submissions verify it.

What we confirm together

Copying messages does not update where new mail arrives. The plan must cover the transfer, final synchronization and DNS change together. Contacts, calendars and provider-specific features need their own scope.

Before starting, we agree on access, affected systems, testing, timing and the handover. Hosting subscriptions, premium software and work outside that scope are identified separately.

Start with a clear scope

Describe your website and what needs to happen. You will receive a fixed scope, price and timeline before any work starts — no passwords needed at the enquiry stage.

Get a quote How projects work