Updated 5 days ago
To migrate your email to Duplika and reduce the risk of losing messages, prepare the destination mailboxes, copy their contents while the previous service is still active, and change where new mail is received only after checking the copy. When you're done, run an additional synchronization to retrieve messages that arrived on the previous server during the change.
We can help you coordinate the migration with your existing hosting plan. If you're also moving your website, databases, or the domain's complete DNS setup, it's best to plan all of these changes together.
Don't cancel the previous service when you change the MX records. Keep access to the source mailboxes until you've completed the final synchronization, resolved copy errors, and verified that each account can send and receive email.
Migration requires access to the contents of each mailbox, available space at the destination, and control over the DNS records that determine where email is received.
What to gather | What to check |
|---|---|
Mailboxes | Full address, used space, and folders for each account. |
Source server | IMAP server name, port, secure connection, and authentication method used by the previous provider. |
Destination server | Connection details for your new service and credentials for each mailbox you created. |
DNS | Provider that manages the DNS zone, current MX records, and confirmed new values for your service. |
Additional features | Aliases, forwarding, automatic replies, filters, mailing lists, and applications that send email using your domain. |
Users' devices | Outlook, mobile phones, or other programs, and whether they store messages locally only. |
Save a copy of your current data and settings. If your provider uses OAuth or requires app passwords, confirm which method is supported for the copy before scheduling the change.
Before changing the MX records, look up your domain in the HostingFAQ DNS comparator and save a copy for reference.
Use server names that continue to identify each endpoint throughout the migration. If you configure both the source and destination as mail.yourdomain.com, a DNS change may cause both to point to the new server.
The destination accounts must exist before they can receive email. Testing one mailbox lets you detect access or space issues before migrating all of them.
Create the addresses you're moving by following the guide to manage email accounts.
Allocate enough space for historical and new messages, within your plan's capacity.
Re-create the forwarding, aliases, and other features needed for those addresses.
Check access to the new mailbox through the destination service's Webmail.
Choose a mailbox for the initial copy and verify the result before continuing with the rest.
The new mailbox may have a different password from the previous one. Creating an account with the same name does not automatically transfer its messages or settings.
Copying over IMAP lets you transfer messages stored on the server, including their folders. Imapsync lets you make incremental copies in one direction, from the previous server to the new one.
You can coordinate the copy with us or run it using a tool you manage and are familiar with. If you use an external migration service, that service will have access to the mailboxes, so consider who operates it before entering credentials.
Configure the source server and account using the previous provider's details.
Configure the destination server and account using the new service's details.
Make sure both connections use the appropriate encryption and authentication method.
Copy from the source to the destination without options that delete messages from either server.
Review the task report and check the test mailbox's contents in the new Webmail.
If the test is complete, repeat the process for the other accounts.
Keep the report for each mailbox: messages copied, skipped, and errors. A completed job does not by itself prove that all messages were copied; there may be size limits, excluded folders, or connection errors.
An IMAP copy cannot retrieve messages that are no longer on the previous server. This can happen if a program downloaded them over POP and deleted the server copy, or if you saved messages in local folders.
Back up your email files or profiles before changing the account. Then plan to import or copy those messages to the new mailbox using the program that stores them; don't delete the previous profile until you've checked the result.
IMAP copies email, but it doesn't transfer contacts or calendars. Rules, signatures, forwarding, and automatic replies also need to be reviewed separately.
Export this data from the service or program that manages it, then import it to a compatible destination. If you're migrating from Google Workspace or Microsoft 365, first decide which shared features you need to keep, in addition to messages.
Check whether the folder exists in the previous Webmail or only on a device. If it's on the server, check that the task includes it and how its name was mapped at the destination.
Folders such as Sent, Sent Items, and Sent may remain separate depending on the system and configuration. Don't merge or delete folders before checking their messages.
MX records indicate which servers receive messages for the domain. You edit them where the authoritative DNS is hosted, which may be cPanel, Cloudflare, or another provider. Publishing the new MX records does not move messages stored on the previous server: the copy is done separately, and mailboxes left there will stop receiving new email.
Save the MX records and any other values you're going to change.
Confirm that all destination mailboxes have been created and that there are no outstanding errors from the initial copy that would prevent you from continuing.
Publish the MX records and any associated records required by the new service, with the correct priorities.
Check Email Routing in cPanel to make sure it matches where the mailboxes are actually hosted.
Verify SPF, DKIM, and DMARC for services that will continue sending email using your domain.
Update the settings in programs and on mobile phones with the new server details.
If the mailboxes will be on this same cPanel server, use local routing. If they remain on an external service, use remote routing; cPanel's automatic detection checks its local zone and does not check public DNS.
To authenticate outgoing email, follow our guide to SPF, DKIM, and DMARC. Don't remove authorization for an application or server that's still in use during the transition.
If you're only migrating email, you don't need to change DNS providers. Keeping your DNS as is and changing only the necessary records avoids affecting your website and other services.
While DNS caches are updating, some messages may continue to arrive on the previous server. The second copy retrieves email that wasn't there when the migration began.
Return to the HostingFAQ DNS comparator and check the MX records returned by Google Public DNS and Cloudflare 1.1.1.1. Compare them with the expected destination and with the copy you saved before the change.
Check whether the previous server is still receiving new messages.
Repeat the incremental copy from source to destination using the same folder mapping; in Imapsync, use the resynchronization option (Sync or resync!).
Review the reports for all accounts and resolve failed or skipped messages.
Ask each user to check their folders and configure the new server on all their devices.
You can learn how to interpret differences in resolution in our DNS propagation guide. A group of checkers returning the correct MX does not, by itself, prove that no email is still arriving on the previous server.
Incremental copying should not be used as permanent two-way synchronization. Avoid reorganizing folders or working interchangeably on both servers during the move, as this makes it harder to compare the results.
Check | Required result |
|---|---|
Historical email | Old and recent messages, important folders, dates, and attachments are available at the destination. |
Copy report | No unexplained errors or omissions. Totals help with comparison, but don't replace checking for differences in folders, duplicates, or labels. |
Incoming external email | A message sent from an account with another provider arrives in the new Webmail. |
Outgoing external email | A reply sent from the new mailbox arrives in that external account. |
Internal email | Two mailboxes on the domain can communicate with each other. |
Devices and applications | Outlook, mobile phones, forms, and other applications use the intended destination. |
Run external tests using easy-to-recognize subject lines and note the time. If a message doesn't arrive, see how to review email logs.
Cancel the previous service after you've completed the final copy, users have validated their data, and you've confirmed that the source is no longer receiving email that needs to be moved. Don't use a fixed propagation period as your only criterion.
Keep the migration backups and reports before closing the service. If you find an issue during the change, coordinate a fix without deleting either copy: switching back to the previous MX records won't automatically move messages received on the new server.
To coordinate the migration with us, provide the source provider, the number and size of the mailboxes, where the DNS is managed, and your preferred date or time. If we perform the copy, we also need the list of mailboxes, each mailbox's password on both servers, and the source IMAP server name. We'll tell you how to share the necessary access details through the appropriate channel; don't include passwords in screenshots or public documents.
