How to Safely Migrate Your Business Email to Unlimited Email Hosting

Switching email providers is one of those tasks small business owners keep postponing, usually out of fear that something important will disappear along the way. An invoice thread, a signed quotation, or a year of customer correspondence going missing mid-move is a real risk if the switch is handled carelessly. The good news is that moving your business email to Z.com's Unlimited Email Hosting does not have to be risky. The file-based backup-and-restore method described below applies when your current provider uses cPanel; if you're on Google Workspace, Titan Email, or another non-cPanel service, you'll need a different migration path, covered in the FAQ. With a backup step done in the right order, a short overlap period, and a couple of DNS settings changed at the right time, you can minimize the risk of missing messages as you move each mailbox.

Why Businesses Move to Unlimited Email Hosting

Most migrations happen for a simple reason: the old plan charges per mailbox, and the bill keeps growing every time a business hires someone new. Whether you're currently on Google Workspace or Titan Email, moving to a plan that charges for storage instead of per user means adding staff, departments, or client-facing addresses no longer means a bigger invoice. Unlimited Email Hosting also includes Imunify 360 security, virus and spam protection, and standard cPanel management, so the switch is not just about cost — it is about not having to think about account limits again.

Before You Start: Pre-Migration Checklist

• List every mailbox you currently use, including forwarders and autoresponders, so nothing gets left behind during the move.
• Check how much data each mailbox holds, then choose an Unlimited Email Hosting storage tier that comfortably covers your total mail, with room to grow.
• Confirm you have cPanel or admin access to your current provider — the file-based backup step depends on it.
• Lower your domain's MX record TTL to 300–600 seconds at least 24 to 48 hours before cutover, so the switch takes minutes instead of hours once you're ready.
• Record your current MX records, SPF/DKIM/DMARC settings if you have them, your existing mail server settings, and approximate mailbox sizes or message counts — this gives you a reference point for verification or rollback if the cutover runs into trouble.
• Pick a low-traffic day and give your team a heads-up so nobody is mid-conversation with a customer when you start.

Step-by-Step: Moving Your Mailboxes to Z.com

The steps below follow Z.com's own cPanel-to-cPanel email migration process, which applies when your current provider also runs cPanel. If you're migrating from Google Workspace, Titan Email, or another non-cPanel service, skip ahead to the FAQ below for the recommended approach.

Step 1 — Back Up Your Current Mailboxes

In your current provider's cPanel, open File Manager and locate the Mail folder inside your account's home directory. Select it, right-click, and compress it — a standard .zip works well. Once the compression finishes, download the file. This is your complete mailbox backup, and it's the only step that touches your old server directly. Because this archive contains your business correspondence, store it somewhere access-restricted and delete it securely once the migration is verified.

Step 2 — Recreate Your Email Accounts on Z.com

Log in to your Z.com cPanel and, under the Mail area, create every address from your checklist — the same info@, sales@, and individual staff addresses you already use. Because Unlimited Email Hosting doesn't cap the number of accounts, you can recreate your entire directory without checking a headcount limit or paying per address you add.

Step 3 — Upload and Restore Your Backup

Back in Z.com's cPanel File Manager, upload your zip backup to the account's root directory, then decompress it and confirm you want to overwrite the existing Mail folder. This copies your old messages and folder structure onto the new server. Open a few of the recreated accounts afterward to confirm the message counts look right before moving on.

Step 4 — Confirm Your TTL Setting Before Cutover

This is your last checkpoint before changing MX records. If you lowered your TTL 24–48 hours ago as recommended, most resolvers are already caching the shorter value, so your new MX records should propagate quickly once you switch. If you haven't lowered TTL in advance, doing it now will not shorten records that other servers have already cached — those caches only expire on the old TTL's schedule. In that case, either wait for the previous TTL period to pass before cutting over, or plan for a longer propagation window and keep both mailboxes active until you've confirmed mail is flowing normally.

Preparing Email Clients and Devices

Before cutover, prepare new mailbox passwords for each account and check the current IMAP/POP3 and SMTP server settings shown in your Z.com account or official setup documentation. Update Outlook, Apple Mail, mobile devices, and any other mail clients your team uses with these settings. Test the change on one pilot mailbox first, confirm sending and receiving both work, then roll the update out to the rest of your team. Share the new settings with users through a secure channel rather than an open chat or unencrypted email.

Step 5 — Update Your MX Records and Verify Delivery

Update your domain's MX records to point to Z.com — this controls where incoming mail is routed. Separately, confirm or update your SPF and DKIM records for the new sending service, since these authenticate outgoing mail and don't follow automatically from an MX change. Keep both the old and new mailboxes reachable during the propagation window; some incoming mail may still arrive at the old server briefly while global DNS caches catch up, which is normal and expected. Test both directions: send a message from an external address to a recreated mailbox, and send one from that mailbox to an external address, checking that each is received, delivered, and not routed to spam. Cancel your previous plan only after confirming a full normal day of mail flowing, sending, and replying correctly through the new setup.

Common Migration Mistakes to Avoid

• Skipping the backup step because "it's just email" — an incomplete account list or a failed upload is the most common way messages go missing.
• Recreating only some mailboxes before restoring the backup, which leaves data with nowhere to land once it's uploaded.
• Leaving TTL at its default setting and cutting over without lowering it 24–48 hours in advance, which stretches out an already stressful transition.
• Canceling the old plan the same day you switch, before confirming every mailbox is receiving mail normally on the new host.
• Forgetting to check SPF and DKIM records for the new host, which can affect deliverability even after the migration itself succeeds.

Frequently Asked Questions