If you are responsible for coordinating the migration of a large customer email platform (e.g. for a telco or an ISP), there are definitely some common email migration FAQ that you need to know. Whether you’re vetting a new email solutions provider, answering to your customer service team about potential data loss and service disruption, or reporting to your CIO/CEO about budgets and timeframes, it’s important that you know the right questions to ask and/or have your well-informed answers ready to go.

To help with your preparation, we’ve put together a handy email migration FAQ list below.

If you’d like to read more about email migrations and take advantage of our free templates, we encourage you to read our previous email migration blog post and/or download our comprehensive 28-page guide, 7 Steps to a Successful Email Migration: A guide to help managers sleep at night.

 

 

Email Migration FAQ - Successful Email Migration - atmail email experts - email migration tips

 

 

Email Migration FAQ

 

Will data be secure during an email migration?

Yes, data should stay secure during an email migration, if the new email provider employs SSL and HTTPS protocols. Account passwords are also usually temporarily updated for transit and reinstated once the new account is created. After migration, end users should still be able to login with their pre-migration passwords.

 

Will any data be lost?

No data should be lost during an email migration, if an experienced provider is used who has checks and processes in place to prevent data loss. Due to DNS propagation, a limited amount of email may sometimes be delivered to the old server for up to 48 hours after your account becomes active. During this time, in a progressive migration, all email from the old server should be continuously synced to the new server, to ensure no emails are lost.

 

Will there be any downtime?

Ideally, email migrations should not result in any unexpected downtime. However, scheduled downtime may take place with a ‘big bang’ methodology (rather than a ‘progressive’ approach, where two platforms are fully available for the entirety of the migration). Once MX records are updated, email may still be delivered to the original service during DNS propagation. This can be mitigated by lowering the TTLs of domains (ahead of time, as appropriate) to the MX record update. Email sent to an original service should be identified and synced as the new provider performs incremental syncs during off-peak times. Access to the service should only be temporarily unavailable in the unlikely event of an end user attempting to access their account while it is being synced. If a server has minimal power, the new provider should be able to limit the amount of resources used by their migration tools, to ensure normal functionality during peak and off-peak periods.

 

Will end users need to change anything?

If all goes well, the only change most end users will experience as a result of an email migration is the new look web interface. End users who use email clients connecting on insecure ports may also need to update their settings, so that the new email system provides a highly reputable and secure service.

 

What information will end users require?

This will depend on how end users access their current environment and how an organisation would like to translate that access to the new environment. We recommend considering the following when planning customer migration communications: hostnames for webmail, IMAP/POP and SMTP; configuration of third-party clients; a user-friendly summary of the migration process (optional); and any other material that you expect end users might need (e.g. if there is an expected learning curve for the new webmail interface).

 

What about end users who use third party email clients?

In most cases, no change is noticeable to end users who use third party clients for their email. However, it is possible that some clients may experience the following scenarios: a prompt to accept a new certificate for their domain on SSL/ TSL connections; the need to update incoming/outgoing server settings, depending on their current configuration; the need to perform a refresh/resync (depending on the end users’ POP/IMAP syncing policies); and/or duplication of emails for POP users (although your new email provider can usually prevent this by migrating the UID of each email). Experienced and knowledgeable migration experts should ensure that POP messages are not duplicated for end users. (Note: Web browser and third-party mail client connection may also require a minimum TLS version.)

 

How long does an email migration take?

For large email platforms, an organisation should typically allow 30 to 90 days for the actual migration of their email, depending on: what data (and volume) is being migrated; the migration methodology; the available network bandwidth; as well as the number of users.

For smaller user numbers, a successful email migration can be completed in less than 3 hours.

For millions of mailboxes, it may be prudent to allow 3 to 6 months. The limitation is often (not technical but) organisational (e.g. internal red tape, changes within the internal action team, and limits to internal help desk resourcing).

 

What services and settings can be migrated?

Email migration typically involves the migration of an end user’s account, password and mailbox. Depending on what email system that an organisation is migrating from, the following services and settings might also be available for migration: Calendars; Contacts; User Forwards; User Aliases; and/ or User Whitelists/Blacklists.

 

Can company branding carry over to a new system?

If an organisation has selected a new solution that allows white label functionality, then they should be able to use their own company branding for the new email system (albeit it might require a new set up, rather than be auto-carried over). This includes white labelling for: hostnames (if you supply the SSL certificates) for HTTPS, POP/IMAP and SMTP; web/mobile addresses; SMTP addresses; web admin addresses; and POP/IMAP addresses.

 

Will antivirus, antispam and relay settings automatically be in place?

Yes, if agreed in the original requirements, the new email provider should already have antivirus, antispam and relay settings in place for the new solution, so that these settings are utilised as soon as the domain(s) point their MX records towards the new email system. As with all items though, it is a good idea to check.

 

 

Want to talk to email migration experts?

With 20 years of email migration expertise, we are trusted by telcos and service providers to power 170 million mailboxes worldwide.

We offer white label, user-friendly, cloud hosted email that is reliable, stable, secure and scalable.

Choose from our US or (GDPR compliant) EU data centres, or stay in-house with our on-premises webmail and/or mail server options.

We invite you to contact us here to discuss your email platform and/or to arrange an online demonstration of our branded email solution.

For more information, you might like to download our comprehensive 28-page guide, 7 Steps to a Successful Email Migration: A guide to help managers sleep at night.