Not every migration is a full-site migration. Sometimes the site is fine right where it is, but email is the problem: it arrives late, lands in spam often, or you simply want to move it to a different mail service without touching anything on the web hosting side. It is a more common situation than it sounds, and the procedure is considerably simpler than a full migration, as long as the correct order is respected.
When it makes sense to separate mail from hosting
There are concrete scenarios where this is the right call. The site is well hosted and fast, but mail from that same provider has delivery or spam problems that will not go away. Or the reverse: you want to centralise mail for several domains under one professional mail service, while each site keeps living where it already is. Or you simply prefer a specialised mail service for its collaboration tools, while web hosting remains the best place for the site itself.
The key thing to understand is that a domain does not have "one single place": it can have the website pointing at one server and mail pointing at a completely different one, at the same time. They are two independent DNS configurations on the same address.
The record that does the magic: MX
Every domain has a DNS record called MX (Mail Exchanger) that tells the world which server to deliver mail addressed to that domain to. It is entirely independent of the record that points the website. Changing the MX does not touch the site at all; changing where the site points does not touch mail at all.
Migrating only email essentially means changing that MX record from the old server to the new one, without touching the domain's other records.
The correct order, step by step
1. Create the new accounts at the destination before changing anything. Same addresses, new passwords. At this point real mail is still landing on the old server.
2. Migrate the existing messages. If there are years of accumulated mail you want to keep, this is the step that takes longest. Most mail services offer some import tool that copies messages from the previous server; if the volume is large, it can take hours.
3. Test the new accounts before changing the MX. Send and receive a test message using the new configuration, without having touched the public record yet. This confirms everything works before real mail depends on it.
4. Only now, change the MX record to point at the new server. This is the point of no return, and it follows exactly the same principle as a site migration: nothing public changes until it has been tested in private.
5. Wait for propagation, which can take from an hour to a full day. During that window, some messages may reach the old server and some the new one, depending on which internet provider is asked first.
6. Keep the old server reachable for a few more days, to rescue any message that landed there during propagation.
The other records worth checking
The MX does not travel alone. If the domain had mail authentication records configured (the ones that keep your messages out of spam), they need to be recreated pointing at the new service, because they are specific to each mail provider. Copying the old values unchanged does not work: every mail service has its own.
If you will keep sending outgoing mail from some part of the site (a form, for instance) using an address on the domain, confirm that piece is configured against the new mail server, not the old one, or sends will fail silently.
Common mistakes when doing this
Changing the MX before migrating the old messages. Once the MX points at the new server, mail that was landing on the old one stops flowing there, and if you have not migrated the history yet, it becomes far more awkward to recover.
Forgetting to update devices. Every phone and every mail program has the old server's settings saved. Each one needs updating, or those devices will keep trying to connect to a place that no longer has the new mail.
Not telling the rest of the team. If more than one person uses mailboxes on the domain, everyone needs the new configuration at the same time, not staggered, to avoid confusion about where each message is during the transition.
What happens to outgoing mail during the transition
One point that often gets missed: while the MX is still propagating, mail you send can keep going out through the old configuration if you have not also updated the outgoing settings in your mail program, not just the incoming ones. Check both separately: they are different settings, and it is common to update one and forget the other.
And if you notice duplicate copies of the same message arriving during those days, that is not a bug: it is exactly the expected behaviour of an MX change in progress, where both servers can be receiving copies of the same send until propagation finishes settling everywhere.
Give it a few extra days before you consider the migration finished. Propagation timing is not identical for every reader of your mail, and closing the old server too early, right after the change, is how a handful of stray messages end up genuinely lost instead of merely delayed.