How Email Migration Works for Resellers

Free migration is one of the easiest reasons to move a client over, but it helps to know how the process actually runs before you promise a timeline to a customer. Here’s what to expect, step by step, plus what you’ll find in the full migration guide in our wiki.

It’s a two-step migration

We migrate email data in two passes: one before your MX records change, and one after.

• Before the MX change: we pull everything currently in the mailbox while your client is still receiving mail on the old provider.
• After the MX change: we run a second pass to catch anything that arrived at the old provider during the transition window, so nothing gets lost between the two systems.

For most sources, we migrate via IMAP, so make sure you have IMAP access to the account before requesting the migration. Two exceptions:

• Microsoft 365 / Exchange: we migrate from a PST file.
• Google Workspace: IMAP access needs to be enabled on the account first.

Set temporary passwords before you start

To migrate a mailbox, we need working credentials for it, either an app password (for providers like Google Workspace that require one) or a temporary password you set for the migration window. In practice, that means resetting each account’s password with the current provider ahead of time.

Since you’ll be the one setting these, advise your customers what temporary password to use during the migration window, so they’re not locked out of their own mailbox while it’s in progress.

Requesting a migration

Open a support ticket from the Support Portal. You can choose a specific date and time for the migration to start, and you’ll receive a confirmation email with your ticket number to track progress.

Batch your migration requests

We process migrations per ticket, so only include the domains and accounts you can actually manage at one time in your migration CSV. As a guideline, keep each ticket to 1 to 10 domains, since you’ll need to coordinate DNS record updates and email client reconfiguration with each affected customer.

For example, a single ticket could cover one domain with 200 mailboxes, or three smaller domains totaling 50 mailboxes. Mailbox volume matters more than domain count.

Smaller batches also make failed accounts easier to fix. Migrations most commonly fail when a mailbox’s password changed after you set the temporary one, and we only retry an account once you tell us it’s ready. A lean migration that finishes in a few hours lets us retry those accounts, or move on to your next ticket, right away. A single 1,000-mailbox migration has to run to completion before we can retry anything inside it, which holds up every account in that batch, not just the ones that failed.

Beyond email: contacts, calendars, and more

We can also import address books and calendars alongside the mailbox data. Attach a CSV or vCard (.vcf) file for contacts, and an iCalendar (.ics) file for calendars, per account.

Scheduling around business hours

Migrations don’t have to happen during the business day. We run migrations after hours and on weekends too, but request that window at least 48 hours in advance so we can guarantee availability.

How long it takes, and staying in the loop

Most migrations complete in under 24 hours. Once it’s running, you don’t have to keep checking in manually. We send automatic updates:

• when the migration begins
• when it ends
• every few hours if it runs past the 6-hour mark

What you’ll find in the migration wiki guide

This post covers the process end to end, but the wiki guide is where you’ll actually execute each step. It includes:

• Example CSV templates you can download and fill in directly — for the migration request itself (email address, temporary password, source IMAP server), plus separate templates for aliases, forwards, and distribution lists.
• Step-by-step instructions for preparing mailboxes, submitting the support ticket, managing local delivery, and completing the DNS and email client cutover once the first pass is done.
• Provider-specific notes, including what changes for Microsoft 365/PST-based migrations versus Google Workspace’s IMAP requirement.
• What happens after migration, including how folder structure and larger mailboxes are handled on the new service.

Full Migration Guide (Wiki) →

Migrating from your client’s current provider

We regularly migrate clients from Microsoft 365, Google Workspace, Rackspace, and effectively any provider that offers IMAP access or an exportable mailbox format. If a client’s current provider isn’t listed here, open a ticket and we’ll confirm the best migration path for it.

Migrating a client off Microsoft 365? This one works differently from the two-step process described above: it’s a single PST export handled after your DNS already points to us, not before. See our step-by-step Microsoft 365 migration guide for the full process and which tier fits your client’s usage.

Migrating a client off Google Workspace specifically? Workspace requires a bit of prep on the client’s end before the migration can start — enabling IMAP access and generating an App Password for each mailbox. Walk through it with our step-by-step Google Workspace migration guide before you open the ticket.

Migrating a client off Rackspace? Which steps apply depends on whether they’re on standard Rackspace Email or Hosted Exchange — see our step-by-step Rackspace migration guide for the tier mapping and what each path needs before you open the ticket.