Short link: opensrs.help/migration
Migrating your users to the OpenSRS Email Service can be done with little or no disruption of service by following the recommended steps below.
The migration process is composed of 4 different phases:
- Preparation (three weeks prior)
- Pre-migration (one week prior, recommended)
- Switching to the OpenSRS DNS
Note: The exact timing of the following tasks is up to you, though we recommend that you inform your users about the upcoming change at least three weeks before the migration.
In your current system
At least two weeks before the switchover, lower the TTL (time to live) value to less than an hour on the DNS Zone records for the domains.
DNS resolvers around the Internet cache DNS records for the length of time that is specified by the TTL value on each DNS entry. For example, if on a DNS record, the TTL is 86,400, a DNS resolver could cache the record for up to 1 day (86,400 seconds) before checking to see if it has changed. Ideally, you should reduce the TTL to the minimum value so that the transition can be as quick as possible.
The minimum value for most DNS resolvers is 300 seconds, and we recommend that you set the TTL on the MX record to 300 seconds. If your end-users connect to something like mail.theirdomain.com and you want them to continue using that hostname, change the TTL on the hostname as well.
Make a note of the old TTL value. If it was 3,600 seconds, you need to wait at least 1 hour (3,600 seconds) to be sure that DNS servers across the Internet have picked up the new, lower TTL value. If the TTL was 86,000, you need to wait a day, etc. If you don’t change the TTL on a DNS Zone record, it will take longer to deliver mail to the OpenSRS Email Service after the MX record has been changed to point to OpenSRS. It will also take longer for end-users to be directed to the new service.
To summarize the required steps are:
- Lower the TTL (time to live) value to less than an hour. We recommend setting the TTL on the MX record to 300 seconds
- Keep note of the old TTL value
Inform your users that you will be migrating their email accounts to a new email system. Let them know that once their accounts are migrated, they will have to reconfigure their Web-based email signature, auto-reply, forwarding, and filter settings. We have some communication templates that you can use to inform your end-users of the planned migration.
We suggest that you also recommend to your users that they backup their address books to a vCard format and their web-based calendars to iCal (.ics) format. Once the migration is complete, they can upload their address book and calendar data into the new email system.
Introduce your users to the new email platform and what they should expect.
In the Reseller Control Panel
- Set up the branding that you want to apply to the domains that you will be moving to the OpenSRS Email Service. Make sure that you make this the default brand so that it is automatically applied to new domains.
- Set the default settings for domains on your company profile page, including default branding, account limits, language, and time zone settings.
We recommend performing these tasks well in advance, approximately one week, to avoid any hiccups. It is possible, however, to perform them on the day of migration.
In your current system
- Stop provisioning new email accounts.
- Stop allowing password changes for email accounts on the existing email service. This is typically done by making the current password preference page inaccessible.
- Be sure to inform your users well in advance that any changes to their address books or calendars made after the designated extract date will not be reflected in the extracted files.
- The address book fields and field headers in the exported file must be in a format that is recognized by the OpenSRS Email Service. We recommend that you import a text file to the new address book service to make sure that the address book files are in an acceptable format.
- Extract the existing Web-based address books and calendars on behalf of each user and save it to a vCard and .ics format files, respectively.
- Send each user their calendar and address book files as email attachments, with instructions to save the files to their desktop and then import the files into the new OpenSRS Email Service after post-migration.
In the Control Panel
- Before you make any hostname changes to DNS, ensure that the same users exist in both the old system and the new system. If you have encrypted passwords for your users, you can use these passwords when creating the accounts, as long as they are Unix-Crypt, MD5-Crypt, SHA, or BCRYPT encrypted.
- If you only have a few accounts to create, you can create them manually using the bulk tool. If you have a large number of accounts, use the Bulk Add function in the Control Panel or use API.
- You can create up to 1000 accounts at a time, and provisioning occurs in real-time.
In your DNS system
- Change the DNS on the domains to point to the new email service by applying MX changes for email access and email delivery. You must specify the DNS entries to configure mail access.
- Ensure you have the correct MX record and CNAME based on your cluster.
Note: MX record is required but the CNAME record is recommended.
- A short while after making the DNS changes (thanks to the TTL change made earlier), all DNS servers around the Internet will have the new hostnames. Mail will begin to flow to the OpenSRS systems, and mail will stop being delivered to the old system. If end-users were connecting to mail.theirdomain.com, their mail clients will pick up the DNS change and begin connecting to the OpenSRS mail server instead of the old system. DNS Propagation may take more than five minutes for some DNS servers, so allow an hour to pass before considering all users moved over to the new service, and before starting the email migration process.
- Re-enable or allow provisioning of accounts, directing requests to the new service.
You can also add the RFC 6186 DNS entries. If added, these entries will allow compatible email clients to automatically configure their hostname and port settings, which makes it easy for new users. Users who connect to their mail client using IMAPS and POP3S records results automatically using SSL encryption for all their email communications.
Once the DNS TTL five minutes have expired, disconnect all IMAP sessions on your mail server. IMAP connections can be long-lasting, and they can stay alive for days at a time. Disconnecting the IMAP sessions will force clients to look up the new DNS entry and connect to the OpenSRS system.
In the Reseller Control Panel
- Use the Migrate Users bulk tool to migrate user mail over IMAP or POP.
- You can migrate up to 500 accounts per batch; batches must be run one at a time.
- You can choose Bulk Actions from the User menu at the top right to view ongoing migrations.
- You can log out or perform other actions in the Control Panel and then return to the running bulk migration job without impact.
- If any of the migrations fail, they can be re-run. The tool will try to prevent duplicate messages from showing up in the user’s mailbox.
- Re-enable provisioning of accounts.
Switching to the OpenSRS DNS
- Duplicate the existing DNS entries in the DNS section of the Reseller Control Panel, and then change the authoritative nameservers to the OpenSRS nameservers.
Note: This step can be done before the migration, with OpenSRS becoming authoritative before the mail is switched over.
- When the root nameservers pick up the change of nameservers, the OpenSRS nameservers will become authoritative. Because they have the same entries as the old nameservers, nothing will change regarding mail flow or DNS lookups.
In the Reseller Control Panel
- Start provisioning email accounts within OpenSRS.
- Remind your users about the instructions on how to import the extracted calendar and address book files into the new platform.
- Reintroduce your users to the new email platform and what they should expect.
The migration process is explained in a video for better visual understanding and to help resellers walk through the entire process.