Updated 2 weeks ago
To migrate your email to Duplika and reduce the risk of losing messages, prepare the destination mailboxes, copy the content while the previous service is still active, and change mail delivery only after verifying the copy. Once complete, perform an additional synchronization to retrieve messages that may have arrived on the previous server during the change.
We can help you coordinate the migration with the hosting plan you have already purchased. If you are also moving the website, databases, or the domain’s complete DNS configuration, it is best to plan all of these changes together.
Do not cancel the previous service when changing the MX records. Keep access to the source mailboxes until you complete the final synchronization, resolve copy errors, and verify sending and receiving for each account.
The 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 verify |
|---|---|
Mailboxes | The 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 | The provider that manages the zone, current MX records, and the new values confirmed for your service. |
Additional features | Aliases, forwarding rules, 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 only locally. |
Save a copy of the current data and configuration. If the provider uses OAuth or requires app passwords, confirm the supported method for the copy before scheduling the change.
Use server names that continue to identify each endpoint during the migration. If you configure both the source and destination with the same mail.tudominio.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 identify access or space issues before migrating all of them.
Create the addresses you are going to move by following the guide to manage mail accounts.
Assign enough space for historical and new messages within your plan’s capacity.
Recreate the forwarding rules, aliases, and other features required for those addresses.
Verify access to the new mailbox from the Webmail of the destination service.
Choose a mailbox for the initial copy and verify the result before continuing with the others.
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.
IMAP copying transfers messages stored on the server, including their folders. Imapsync lets you perform incremental, one-way copies from the previous server to the new one.
You can coordinate the copy with us or run it using a tool you manage and know. If you use an external migration service, that service gains access to the mailboxes, so assess who operates it before entering credentials.
Configure the source server and account with the previous provider’s details.
Configure the destination server and account with the new service’s details.
Verify that both connections use the appropriate encryption and authentication method.
Run a copy from the source to the destination, without options that delete messages on either server.
Review the task report and check the contents of the test mailbox in the new Webmail.
If the test is complete, repeat the process for the remaining accounts.
Keep the report for each mailbox: copied and skipped messages, and errors. A completed job alone does not prove that all messages were copied; there may be size limits, excluded folders, or connection errors.
IMAP copying cannot retrieve messages that no longer exist on the previous server. This can happen if a program downloaded them using POP and deleted the server copy, or if you saved messages in local folders.
Back up your email files or profiles before modifying the account. Then plan to import or copy those messages to the new mailbox using the program that stores them; do not delete the previous profile until you verify the result.
IMAP copies email, but it does not transfer contacts or calendars. Rules, signatures, forwarding rules, and automatic replies also require separate review.
Export this data from the service or program that manages it and import it into the compatible destination. If you are migrating from Google Workspace or Microsoft 365, first define which shared features you need to keep in addition to the messages.
Check whether the folder exists in the previous Webmail or only on a device. If it is on the server, verify that the task includes it and how its name was mapped at the destination.
Folders such as Sent, Sent Items, and Enviados may remain separate depending on the system and configuration. Do not combine or delete folders before checking their messages.
MX records indicate which servers receive messages for the domain. They are edited wherever the authoritative DNS records are managed, 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 performed separately, and mailboxes left there stop receiving new email.
Save the MX records and any other values you plan to modify.
Confirm that all destination mailboxes have been created and that the initial copy has no outstanding errors that would prevent you from continuing.
Publish the MX records and any associated records required by the new service, with the correct priorities.
Review Email Routing in cPanel so that it matches where the mailboxes are actually hosted.
Verify SPF, DKIM, and DMARC for the services that will continue sending email using your domain.
Update the settings in programs and mobile phones with the new server details.
If the mailboxes will be on this same cPanel server, local routing is appropriate. If they remain on an external service, remote routing is appropriate; cPanel’s automatic detection checks its local zone and does not verify public DNS.
To authenticate outgoing mail, use our guide to SPF, DKIM, and DMARC. Do not remove authorization for an application or server that is still being used during the transition.
If you are migrating only email, you do not need to change DNS providers. Keeping your DNS with the current provider and modifying only the necessary records avoids affecting the website and other services.
While DNS caches are updating, some messages may continue arriving at the previous server. The second copy retrieves email that was not present when the migration began.
Check the domain’s MX records in WhatsMyDNS and compare the responses with the expected destination.
Check whether the previous server is still receiving new messages.
Repeat the incremental copy from the source to the 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 resolution differences in our guide to DNS propagation. A set of checkers showing the correct MX does not, by itself, prove that email is no longer reaching 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 transfer, as this makes it harder to compare the results.
Verification | Required result |
|---|---|
Historical email | Old and recent messages, important folders, dates, and attachments available at the destination. |
Copy report | No unexplained errors or omissions. Totals help with comparison, but they do not replace reviewing differences in folders, duplicates, or labels. |
External receipt | A message sent from an account at another provider arrives in the new Webmail. |
External sending | The reply sent from the new mailbox arrives at that external account. |
Internal email | Two mailboxes in the domain can communicate with each other. |
Devices and applications | Outlook, mobile phones, forms, and other applications use the intended destination. |
Perform external tests with easy-to-recognize subjects and note the time. If a message does not arrive, see how to review mail logs.
You should cancel the service after completing the final copy, users have validated their data, and you have confirmed that the source is no longer receiving email that needs to be transferred. Do not use a fixed propagation period as the only criterion.
Keep the migration backups and reports before closing the service. If you detect a problem during the change, coordinate the correction without deleting any copies: reverting to the previous MX records does not 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, the DNS location, and your preferred day or time. If we perform the copy, we also need the list of mailboxes, each mailbox’s passwords on both servers, and the name of the source IMAP server. We will tell you how to share the necessary access details through the appropriate channel; do not include passwords in screenshots or public documents.
