Cloudiway’s mail migration solution helps businesses perform elaborate technical migrations through a simple SaaS interface. As a result, mail migrations require no additional software installation or overhead, and migrations can be performed securely and quickly.
The Cloudiway platform is flexible enough to support all types of migration paths. Your migration strategy will depend on your business setup, type and size. Whichever migration path you choose, Cloudiway provides all the essential features including automatic account provisioning, license assignment, archive migration, mail routing and calendar coexistence (free/busy scheduling).
Two of the most common migration strategies are cutover and staged migrations. Cutover strategies involve migrating all mailboxes over a weekend, ready for your users on Monday morning. Staged strategies provide more flexible migration options, as discussed below.
1.1. Cutover migration
You migrate everybody over a weekend and perform a single migration pass. This strategy is the simplest to implement. After you have switched your MX records to point to the new system, you start mailbox migration.
Cutover migration is therefore a strategy where the entire company is switched at the same time.
1.1.1. Cutover migration benefits
1.1.2. Cutover migration considerations
You can combine your cutover migration with pre-staging, if required. In this case, during the days or weeks leading up to your cutover, you would migrate all mails up to a week or so ago along with calendars and contacts, then on the day of your cutover, you would run a quick delta pass to migrate the remaining items.
1.2. Staged migration
A staged migration allows you to migrate batches of mailboxes over the course of a few weeks or months. This strategy is useful for migrations with large volumes of data (very full mailboxes or many mailboxes) and you estimate that you won’t be able to do your migration over a single weekend.
Cloudiway offers you additional flexibility in your approach to a staged migration. For example, you could migrate the last six months of emails over a weekend and leave older emails and email archives to be migrated after cutover, explaining to users that their older emails will appear soon.
Prestaging is also an option on the Cloudiway platform. For example, you could perform a multi-pass migration where you migrate most mailbox items before performing the final cutover. During the days or weeks leading up to your cut-over, you would migrate all the mails up to a week or so ago along with calendars and contacts, then on the day of your cutover, you would run a quick delta pass to migrate the remaining items.
Cloudiway provides a number of options to help you find the best strategy for a staged mail migration. We provide coexistence services, plus mail routing, and batch migration of users, which you can define in any way you like. Basically, you can choose who, when and what gets migrated during each pass.
1.2.1. Staged migration benefits
1.2.2. Staged migration considerations
Staged migrations tend to be more complicated than single cutover migrations. Therefore, it’s important that you have planned your approach thoroughly prior to starting any migration.
We take your privacy and security seriously at Cloudiway, and we have invested significant effort into making our platform and your data secure. Cloudiway provides a cloud-based application hosted in Windows Azure. It means that the software and data are centrally hosted and accessed by clients using a web browser and internet connection. In addition, Cloudiway’s SaaS benefits from Windows Azure’s certifications, ensuring security of the infrastructure, network and physical security layers of the Cloudiway cloud.
For total assurance, Cloudiway provides auditing tools, secure, authenticated data connections and a logging system. More specifically:
*For the delta pass mechanism, the messageID of each email is used. This ensures that no data is duplicated, and for efficiency, only the changes are propagated. We automatically delete inactive records after 90 days, or upon request.
In addition, because the Cloudiway platform needs credentials to connect to the source and the target, you define connectors to connect to them and enter credentials that will be used for the connection. These credentials are stored encrypted using AES 256.
For complete peace of mind, we recommend that you create a temporary migration account during your migration which you can delete at the completion of your project.
The Cloudiway platform uses all available resources to provide the fastest migration possible and can support both small and large migrations. The on-demand migration engine allocates the capacity that you need to migrate the volume of data of your choice in the time slot you have allocated.
However, there are limitations. Many mail systems can heavily throttle users. When you perform too many API calls, the remote server will begin throttling and decrease the number of calls that can be performed each minute, thus reducing the migration throughput. Cloudiway continuously attempts to migrate email at the maximum capacity allowed to achieve the highest throughput.
Office 365 limitations
Office 365 uses throttling policies to limit the resources consumed by a single account. To maximize throughput and limit throttling, Cloudiway follows Microsoft best practice and uses impersonation.
An account that has impersonation privileges can impersonate 100 users concurrently to migrate 100 mailboxes in parallel. The platform uses EWS (Exchange Web services) protocol; Microsoft theoretically allows throughput of around 300 MB per user per hour. The Cloudiway platform typically sees throughput between 200 Mb and 300 MB per mailbox per hour. This gives an average throughput of around 500 GB per day with a constant migration of 100 concurrent mailboxes.
To further improve throughput, you can create additional connectors. For example, if you create two target Office 365 connectors (each with its own distinct migration account), you can migrate 200 mailboxes concurrently and reach a throughput of around 1 TB per day.
Mailbox item count is also a factor. Office 365 throttling policies limit migration to 1500 to 1800 mails per user per hour. Therefore, a mailbox with 1,000,000 small emails will be slower to migrate than a mailbox with 1,000 large mails containing attachments.
Exchange On-Premises limitations
A major benefit of Exchange On-Premises is that you’re in control of all settings. If you’re migrating from Exchange, make sure your server(s) and network are optimized for maximum throughput.
Amazon WorkMail limitations
At the time of writing, Amazon WorkMail has the following limits, which cannot be increased:
In addition, Amazon WorkMail requires one directory (you’re limited to two AWS Directory Service directories per region) and one VPC (you’re limited to 5 VPCs per AWS region). See http://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html for more information.
4.1. What can be migrated
When moving from Office 365 to Amazon WorkMail, these mail-related items can be migrated:
4.2. Migration limitations
Amazon WorkMail currently doesn’t support archiving. Archive mail can still be migrated to Amazon WorkMail, but it is treated the same as non-archived mail. Litigation hold folders are also not currently supported by Amazon WorkMail. Shared Mailboxes are also not currently supported, and Amazon WorkMail doesn’t include tasks, journals or notes so these cannot be migrated.
Migration takes place between existing mailboxes. This means that mailboxes must exist in the target at the time of migration. Please ensure that all mailboxes to be migrated to Amazon WorkMail have had their target mailbox created in the target domain. This also applies to resources.
During migration, Outlook profiles are not recreated by default. Although this is the responsibility of the system administrators performing the migration, Cloudiway provides a tool to perform this task. Please contact Cloudiway for more information.
To migrate a user, you must use the primary source and target SMTP address rather than an alias.
PST files are not migrated as these are normally stored locally, where the Cloudiway platform has no access. To migrate mail in a PST file, import it back into the user’s mailbox prior to migration.
If you’re migrating from Exchange On-Premises, you have an extra option available called ‘selfmigration’. In some circumstances, you might not get have access to an account with impersonation privileges. In this case, selecting the self-migration option on the Cloudiway platform will still allow migration to take place, even without those privileges. An email notification will be sent to the end user with a migration link. After clicking on the link, the user will be asked to enter their credentials. Once entered, the migration will start automatically using the username/password entered.
This guide is aimed at experienced system administrators who are capable of connecting to remote systems and using a variety of administration tools.
Although we provide support for our own products, we do not provide support for third party products such as PowerShell or server administration of Exchange of Amazon WorkMail.
If you are concerned you might have any difficulty completing these steps, please consider a solution with our consulting team, contactable via email@example.com. This will ensure a fast, costeffective and stress-free implementation.
5.1. Before you start
Before you start, you will need to ensure you have the details outlined in the following table. You will only need the items associated with your chosen target. The sections below the table only need to be followed if they related to your target. We recommend you create accounts especially for migration. After migration, simply delete the accounts.
|Cloudiway login||Stores details and provides communication between the systems you already use.||https://apps.cloudiway.com|
|Knowledge base access||Our extensive knowledge base is always accessible, with videos, troubleshooting tools, samples and more.||https://kb.cloudiway.com|
|Source: Office 365
Office 365 account with impersonation privileges
|Used for impersonation to access mailboxes. This doesn’t have to be the tenant’s admin account. However, it must be an admin account if you wish to migrate permissions. The account must be able to bypass SSO and authenticate using username/password credentials with the format: firstname.lastname@example.org (with a password set to never expire).||Exchange Admin Center.
We provide steps below to set up an account with impersonation privileges.
|Source: Exchange On-Premises
Exchange account and secure port
|Used for impersonation to access mailboxes. This doesn’t have to be the main admin account. However, it must be an administrator account if you wish to migrate the permissions. The account must be able to bypass SSO and authenticate using username/password credentials (with a password set to never expire). This is not required if self-migration is used. The Cloudiway platform needs to connect to Exchange securely. Use SSL port 443.||Your Exchange server
If you can’t access an account with impersonation privileges, you can use the self-migration option.
|Amazon WorkMail migration account||Used for impersonation to access mailboxes. It can be any user.||Amazon WorkMail Console
We provide the steps below to set up access.
5.2. Set up an Office 365/Exchange account with impersonation privileges
An Office 365 account with impersonation privileges can access up to 100 mailboxes concurrently. Therefore, by default, Cloudiway allows you to migrate 100 concurrent users. If you wish to speed up your migration, you should set up additional source connectors on the Cloudiway platform and associate different accounts with admin access to each one.
Below are the steps to show you how to set up impersonation using the Office 365 Exchange Admin Center. If you don’t already have impersonation set up, please follow the steps below.
If you’re using Exchange On-Premises, you can follow the steps below too. Remember, if you plan to use the ‘self-migration’ option, you don’t need to create this account at all.
5.3. Set up an Exchange On-Premises account via PowerShell
If you’re migrating from Exchange On-Premises, you can create a migration account with admin and impersonation permissions using your existing Exchange server interface or using the command line instructions shown in the steps below.
5.4. Set up an Amazon WorkMail account with impersonation privileges
Below are the steps to show you how to set up impersonation using the Amazon WorkMail Console. We recommend that you create a user especially for mail migration at both your source and target.
Remember to make sure that all users, groups and resources are created on Amazon WorkMail prior to getting started with the Cloudiway migration platform. Mail migration can only begin if mail has a target inbox to be copied to.
6.1. Allocate mail migration licenses
Please get in touch with Cloudiway (at email@example.com) so that your licenses can be organized and allocated to your Cloudiway account right away. By getting in touch now, the licenses will be available for use well before you need them.
6.2. Create your source connector
To facilitate mail migration, the Cloudiway platform needs to be able to communicate with both your source and target domains. To do this, Cloudiway uses connectors, which are configured on apps.cloudiway.com. You will need to set up a connector for each source tenant you wish to migrate and each target tenant that mail should be migrated to. Follow the steps below to configure Office 365 or Exchange On-Premises source connector.
If you’re migrating from Office 365, remember that each account with impersonation privileges can access up to 100 mailboxes concurrently. Therefore, by default, each Cloudiway connector can migrate 100 concurrent users. If you wish to speed up your migration, you should set up additional Office 365 source connectors on the Cloudiway platform and associate different accounts with admin access to each one.
If you’re migrating from Exchange On-Premises, the speed of migration is limited only by your hardware, network and software setup, so concurrent connectors on the Cloudiway platform are unlikely to increase throughput.
If you’re migrating from Exchange On-Premises and opting for self-migration, you can choose whether to send the activation notification to the user at their source mailbox or their target mailbox. The target mailbox notification can be used if users are already accessing the target system, allowing them to migrate their old mailbox at their leisure. The source mailbox notification can be used if users are still accessing the source system, allowing them to trigger their mailboxes to the target system when they’re ready to move.
6.3. Create your target connector
For Cloudiway to migrate your email, it needs to be able to communicate with both your source and target domains. To do this, Cloudiway uses connectors, which are configured on apps.cloudiway.com. You will need to set up a connector for each source you wish to migrate from and each target that you wish to migrate to. With your source connecter already set up, a target connector to Amazon WorkMail is now required.
6.4. Configure the global settings for migration
Now that you have set up at least one source and target connector, you’re ready to configure your global settings. Using the Cloudiway platform, this is simply a matter of selecting what you want to migrate.
By default, the global migration settings are configured to migrate everything but the Trash folder. You can toggle these and change the date and time settings from the Global Settings option on the Cloudiway platform.
Most of the options are self-explanatory. The Convert Email Address option needs further explanation. When activated, this option rewrites email addresses found in the header and replaces source email addresses with their corresponding target email addresses.
For example, if Bob sends an email to his colleague, Chloe, from his source address firstname.lastname@example.org to email@example.com and a week later, after migration, firstname.lastname@example.org replies to Bob, the Cloudiway platform has already updated SMTP header in Bob’s original email in her inbox, so her reply will be sent to bob@target.
For migrations where the only email address change is the domain name (such as Bob’s email address above), the Cloudiway platform uses the domain name defined in the target connector to convert source email addresses.
For migrations where both the domain name and the username change (for example, email@example.com becomes firstname.lastname@example.org), the Cloudiway platform already uses a mapping table to link each user. This mapping table is also used by the Convert Email Addresses option in this situation. Therefore, it’s important that all users exist in the mapping table before migration begins (this guide contains instructions).
Note that users in the mapping table do not require a license until you’re ready to migrate them. Therefore, you can assign the ‘No license’ option to all your users prior to migration. Having a complete mapping table is also required if you plan to use Cloudiway’s free/busy calendar tool in conjunction with mail migration.
The Convert Email Address option is switched on by default (and is best left on). Make sure your user list is up to date to benefit from this functionality.
X.500 address migration: The Cloudiway platform automatically converts any X.500 addresses to SMTP during migration.
6.5. Import or create your users
There are a number of ways to add users that you wish to migrate. These include:
Regardless, each user will need to be assigned a license type.
6.5.1. Import or create your users
If you have a CSV file of all your users, you can upload the file to Cloudiway. The file must have the following fields in the header row:
Note that many browsers limit CSV file uploads to 5000 lines, so files larger than that should be split up and uploaded separately. Data already uploaded will not be overwritten, so you can upload as many files as required.
The BatchName field can be left blank. If required, you can use this field to name different batches so they can be run in a certain order. A sample CSV file is available for download during the steps outlined below.
6.5.2. Option 2: Import Users tool
Cloudiway’s Import Users tool helps you to retrieve users from your source tenant. The functionality works via Identity Access Management. The tool requires you to specify any transformation rules you wish to apply. It will then add new users in the Mail Migration User List view within the Cloudiway platform.
This is an advanced tool that is best used in partnership with Cloudiway consultants. If you are interested in using this option, please get in touch with your Cloudiway contact.
6.5.3. Option 3: Single user creation details
Many of our first-time customers create a single user for testing purposes. This provides a means of watching the migration process without affecting all users. Single users can also be created for migrations affecting just a few users.
6.6. Activate and monitor your migration
Now that you have performed all the pre-migration steps within your tenants and within Cloudiway, you’re ready to migrate. We recommend you run a test migration on a single user first to check that your configuration produces the outcome you expect.
To start your migration, select the users or batch you wish to migrate and click on Migration on the Action bar, then Start. Your batch will be scheduled and will begin as soon as resources are available. By default, a hundred migrations can be run concurrently per connector.
Don’t forget that Cloudiway migration platform supports delta passes and that migrations are therefore incremental; every time you restart the migration of a mailbox, only items that haven’t already been copied to the target will be migrated. The platform therefore does not duplicate items in the target.
6.7. Migrate permissions globally
You can globally migrate permissions for mailboxes through the Cloudiway platform. Note: once you start the process of setting permissions, it cannot be stopped! Make sure you’re ready.
Please note that some of the tools shown on the Global Actions screen above are designed to work with Office 365 targets only, but Cloudiway developers are working to make these more broadly available. Their inclusion during Amazon WorkMail migrations is a high priority, so please contact Cloudiway if you’d like to test these features.
7.1. Link calendar meeting entries
This task runs on all mailboxes defined in the user list, and tries to link meeting entries for owners and attendees. When completed, attendees and owners can send and receive updates on appointments.
NOTE: Remember, you can always check progress on the Mail Migration Dashboard
7.2. Migrate existing mail archives
Archive mailboxes and In-Place archives at the source are treated differently to standard mail and are not migrated by default: all existing mail archives are ignored during standard mail migration. Mail archive quota packages can be bought if you wish to migrate any type of mail archive.
There are several important considerations when migrating mail to Amazon WorkMail:
If you still wish to migrate mail archives to Amazon WorkMail, the most straightforward way to is to create a new target connector to use especially for archive migrations. This allows you to begin an archive migration even if a user’s inbox migration is ongoing.
For example, the following steps are required to migrate a user who has an inbox and an archive:
If you have followed this user guide, you will have already performed steps 1, 2 and 3. You can now perform steps 4 to 6 for the archive migration.
For example, if Bob has a normal mailbox and an In-Place archive, he will appear on the Cloudiway platform twice: once in the standard User List section and once in the Archive user list section. Bob’s entry in the User List section will be associated with the standard mail migration license, so archive mail will be ignored. Bob’s entry in the Archive user list section will be associated with the same connectors, but associated with the mail archive quota package, so only archive mail will be migrated.
As these two migrations are treated separately, you have the flexibility to migrate archives before, during or after the standard mailbox migration has taken place. If you choose to migrate both at the same time, make sure you have set up new connectors especially for archive migration with different admin credentials to ensure you achieve maximum throughput. This recommendation is followed in the steps below.
Cloudiway provides an extensive knowledge base with many resources, including common error messages, video guides and downloads.
Please visit the entire knowledge base here (where you can search for keywords or read through topics): https://kb.cloudiway.com/
The knowledge base also contains information on how you can ask for further support, should you require it.