Email moves fail for boring reasons: a DNS TTL you forgot to lower, an IMAP sync that quietly skipped folders, or a shared mailbox nobody ever documented. If you’re planning a provider change, a server upgrade, or consolidating client mail for an agency, this email hosting migration checklist is written for real hosting operations in 2026.
Hostperl support sees the same pattern over and over. The actual copy step usually works. The trouble shows up around it: sender identity (SPF/DKIM/DMARC), device reconfiguration, and having a rollback that doesn’t lose mail. This guide stays focused on planning and risk control, not a command-line marathon.
What you’re migrating (and what people forget)
“Email hosting” usually includes more than inboxes. Before you lock in a cutover date, write down exactly what’s in scope. It prevents surprise dependencies and makes it easier to brief a team or client.
- Mailboxes: inbox, sent, drafts, archived folders, and server-side rules.
- Aliases and forwards: catch-alls, role accounts (accounts@, sales@), and distribution lists.
- Shared mailboxes: often created as a normal mailbox used by multiple devices; these are easy to miss.
- Calendars and contacts: may live in groupware platforms, not IMAP.
- Outbound identity: SPF, DKIM, DMARC, and reverse DNS expectations.
- Apps that send email: website forms, WooCommerce/Shopify connectors, CRMs, POS tools, and scanners/printers that relay SMTP.
If your setup is messy, split the problem in two: “people mailboxes” and “application sending.” Move inboxes to the new host, but keep app sending on a dedicated SMTP service or a server with a properly configured identity. That’s a simple way to cut deliverability tickets.
Email hosting migration checklist: pre-migration planning (7–14 days out)
This is the work that prevents downtime. It’s also the work people skip because nothing looks broken yet.
- Inventory every address (mailboxes, aliases, forwards, groups). Export a list from your current control panel and confirm it matches what staff actually use. Include “hidden” mailboxes on old phones.
- Confirm mailbox sizes and growth. If you have 25 GB mailboxes, plan your sync window and storage on the destination.
- Decide the migration method: IMAP sync, control-panel migration tooling, or export/import. IMAP sync is common but doesn’t always bring rules or calendars.
- Plan your cutover window based on business hours. For NZ/APAC teams, a late-evening NZT cutover can reduce disruption and give you a local support window next morning.
- Lower DNS TTL for the domain’s MX record set (and any related records) to 300 seconds. Do this at least 24 hours before cutover so caches drain.
- Prepare a rollback plan: how you’ll revert MX, and how long you’ll keep the old mail server accepting mail (typically 3–7 days).
- Pick who owns the “source of truth” during the move. One admin should control DNS changes and final sign-off to avoid conflicting edits.
If you’re moving your broader hosting stack at the same time, coordinate it. Email cutovers during a website migration tend to double the tickets because you’re changing too many variables at once. Hostperl customers often stage email and web separately for a calmer change window. If you’re upgrading infrastructure, this pairs well with our planning post: VPS Upgrade Checklist: What to Fix Before You Migrate in 2026.
Choose the right landing spot: shared hosting vs VPS vs dedicated
Where you host mail affects reputation, performance under load, and how quickly you can troubleshoot. Here’s the practical version we use when these cases hit support.
- Shared hosting email fits small teams that want simple mailboxes alongside their site and don’t need custom mail routing. If you’re already using cPanel-style workflows, Hostperl shared hosting is usually the lowest operational overhead.
- VPS email fits agencies and growing businesses that need clearer separation, consistent performance, and control over sending identity (especially across multiple domains). If you want control without turning this into a full mail-platform project, start with a Hostperl VPS and treat email as a monitored service, not a side feature.
- Dedicated server email makes sense if you have high mailbox counts, heavy IMAP concurrency, strict compliance requirements, or you want predictable performance at peak. Dedicated also helps when you need hard isolation for reputation management. For high-traffic businesses, a Hostperl dedicated server can be the right call.
If you’re stuck between options, decide based on supportability. Email hosting isn’t only CPU and disk. It’s your ability to diagnose bounces, keep DNS accurate, and respond fast when someone says “mail is bouncing” five minutes before a proposal deadline.
Identity and deliverability: lock down SPF, DKIM, DMARC before cutover
Most “email migration problems” are deliverability problems in disguise. You move mailboxes, update MX, and suddenly outbound mail lands in spam because the new system sends differently.
Before cutover, document what you have today:
- SPF: who is allowed to send for the domain (mail server, CRM, newsletter tool).
- DKIM: signing keys and selector(s).
- DMARC: policy (none/quarantine/reject) and reporting addresses.
Two rules we apply at Hostperl because they prevent common breakages:
- Don’t break third-party senders. If you use Microsoft 365, Google Workspace, Mailchimp, Xero, or a ticketing system, keep them in SPF and plan DKIM per service where available.
- Don’t publish multiple SPF records. Combine mechanisms into a single record. Multiple SPF TXT records cause intermittent failures.
If you want a focused deliverability run-through written for VPS hosting customers (not email marketers), use: Email Deliverability Checklist for VPS Hosting in 2026.
Mailboxes and data transfer: plan for “what doesn’t sync”
IMAP sync handles most migrations well, but it has a few sharp edges:
- Server-side rules may not migrate (depends on platform).
- Calendar/contacts usually don’t live in IMAP.
- Read/unread state can drift if users keep working during the copy.
- Sent Items can split across devices if users have “save sent locally” behavior.
To keep the helpdesk quiet, agree on a “quiet period” during the final sync (often 30–90 minutes). For busy teams, this message works: keep reading mail, don’t move folders, and avoid sending large attachments during the window.
If you’re migrating between control panels, use panel-native tooling when it’s available and supported. If you’re on Plesk and email continuity matters, your backup approach matters too. These two Hostperl tutorials are useful references while you plan:
DNS cutover that doesn’t cause a week of random behavior
DNS is where “it should have worked” turns into “some people can send, some can’t.” The goal is predictable propagation and clean mail flow while old caches expire.
Use this cutover sequence for most small-to-mid migrations:
- Day before: reduce TTL for MX, autodiscover/autoconfig records (if used), and any mail-related hostnames (mail.example.com). Target TTL: 300 seconds.
- Cutover time: switch MX to the new provider and verify the new hostnames resolve correctly.
- Immediately after: confirm SPF/DKIM/DMARC still reflect reality for all senders.
- Keep the old server alive to accept late-delivered mail while caches expire. Forward or sync any stragglers.
A common pitfall is leaving old autoconfig or autodiscover records pointing at the previous provider. Mail might still deliver, but you’ll get endless setup failures and password prompts on devices.
If you manage DNS on your own server or need more advanced DNS operations (like zone transfers for redundancy), this guide can help your team understand the moving parts: Set Up DNS Zone Transfers with BIND9 on Ubuntu VPS.
Client devices and staff comms: the fastest way to cut support tickets
The biggest “migration cost” usually isn’t server time. It’s staff time answering the same question all day: “Why is my phone asking for a password?”
Before cutover, prepare a one-page internal note that includes:
- New IMAP/SMTP server names (or the new mail host).
- Ports and encryption (IMAP 993 SSL/TLS, SMTP submission 587 STARTTLS is typical).
- Whether passwords change.
- Who to contact if mail stops.
If you’re an agency, add a simple table: client domain → who approves DNS changes → who validates mail at completion. That alone avoids last-minute “we can’t find the login” delays.
Security and compliance checks that matter for email moves
Email moves are a good moment to clean up security drift. Skip the theatre. Fix the things that prevent real incidents and reduce future lockouts.
- Enforce strong mailbox passwords (or passphrases) and rotate credentials for shared mailboxes.
- Enable TLS for IMAP/POP/SMTP and verify certificates are valid and auto-renewing.
- Audit forwarders for unexpected external destinations. We routinely find old “temporary” forwards still active.
- Lock down SMTP relay so only authenticated users and trusted apps can send.
If your email runs on a VPS, basic protection against brute-force attempts is non-negotiable. A maintainable baseline is UFW + Fail2ban. Hostperl has hands-on references you can keep in your runbook:
Day-of migration run sheet (what to verify, in what order)
You need a sequence someone can follow while the clock is running. Keep it short enough to use during the change window.
- Confirm backups exist and are accessible for mailboxes you can’t afford to lose.
- Start/complete final mailbox sync (or schedule the panel migration job).
- Switch MX and any required mail host records.
- Send test mail to and from an external address (Gmail/Outlook), not just internal tests.
- Check headers on a test message: confirm DKIM=pass and SPF alignment where expected.
- Validate webmail and one desktop client (Outlook/Apple Mail/Thunderbird) plus one mobile device.
- Monitor bounces for the next 2–4 hours. Most misconfigurations surface quickly.
If you run your own mail server stack, don’t mix “nice improvements” into migration day. Avoid changing spam filtering policy, mailbox quotas, and outbound throttling in the same window. Keep the change surface area small.
After cutover: keep the old system for a short overlap
Even with a clean DNS cutover, delayed delivery happens. Some remote servers retry for hours. Some devices keep sending via cached SMTP settings. A short overlap keeps those edge cases from turning into mail loss.
A practical overlap policy:
- Keep old mail receiving for 3–7 days (or longer for high-risk businesses), but discourage users from logging into the old system.
- Monitor both sides: check for mail still landing on the old server and sync it across if needed.
- Only then decommission the old mail service once new delivery is stable and staff devices are updated.
Common failure modes we see in support (and how to avoid them)
These issues generate repeat tickets. Prevent them and the migration feels boring—in the best way.
- Password prompts everywhere: usually wrong server names, wrong ports, or old autodiscover records. Fix the documentation and autoconfig DNS.
- Some users are “missing mail”: often they used POP on a legacy device. POP downloads mail locally, so server-side history can be incomplete. Identify POP users early.
- Sent mail is split: device-specific sent folders and SMTP settings. Standardise “Sent Items” handling where possible.
- Outbound mail goes to spam: SPF/DKIM/DMARC misalignment, or sending IP reputation changes. Stabilise identity first, then tune spam policy.
- Website forms stop sending: SMTP credentials changed or the site was relying on localhost mail(). Treat application sending as a separate checklist item.
Summary: a migration that stays under control
A good email migration in 2026 is mostly planning: clear scope, stable identity, sensible DNS timing, and user comms. The copy step is just the middle of the project. Treat email as an operational service—with backups, monitoring, and rollback—and you avoid the “random issues for a week” spiral.
If you’re moving to a more predictable platform, pick the hosting tier that matches how much control and isolation you actually need. For many teams, a Hostperl VPS hosting hits the sweet spot between performance and manageability. If you want the simplest path for a small business site and mailbox set, Hostperl shared hosting keeps things straightforward.
If you’re planning an email move and want fewer surprises, Hostperl can help you choose the right landing zone and run a clean cutover plan. Start with a reliable platform—either shared hosting for straightforward mailbox needs or a VPS when you need more control over identity and performance.
FAQ
How long should we keep the old email server after cutover?
For most businesses, 3–7 days is enough to catch delayed delivery and straggler devices. If you’re in a high-risk period (billing runs, tenders, payroll), keep it longer and monitor both sides.
Do we have to change passwords during an email migration?
Not always. If you’re recreating mailboxes on a new platform, you can often set the same passwords to reduce user friction. For shared mailboxes or compromised accounts, it’s a good time to rotate.
Will IMAP migration copy everything exactly?
It usually copies folders and messages, but not always rules, signatures, calendars, or contacts. Plan those items explicitly, and validate a few “complex” accounts (large archives, many folders) before cutover.
What’s the single most important DNS step?
Lowering TTL at least 24 hours before the MX change. It makes propagation predictable and reduces the “some users still hit the old server” problem.
Should we host email on shared hosting or a VPS?
Shared hosting is fine for smaller teams that want simplicity and don’t need custom mail routing. A VPS is a better fit when email is business-critical, you need more control over sending identity, or you manage multiple domains for clients.
