4 Email Migration Best Practices to Follow

Best Practices to Follow for Email Migration

1. Figure Out Your “Why”

Before you get started, ensure all stakeholders know the “why” behind the email migration. Maybe you’re switching because:

• you want a new platform as the typical lifecycle of an SP platform is five to eight years
• you want to upgrade because migration needs appeared 
• you want to offer a premium service (better experience, more features, or more monetization options)
• you want a new vendor because the current vendor stopped supporting the legacy platform
• you want to avoid vendor lock-in (significant changes in pricing, product, or support)
• you want to align with the underlying changes in your infrastructure (Kubernetes or cloud-native, new centralized logging / SIEM)
• you want to support a growing user base for which the legacy platform no longer fits. 

Whatever the reason, consulting with and gaining support from your entire team early in the process will help ensure a more successful migration for you and your users. Internal teams typically involved with and affected by an email migration can include:

• customer support (ticket volumes and support) 
• marketing and product management (customer stickiness, customer retention, revenue growth, brand reputation)
• information technology (operation, DevOps, security, engineering)
• finance (budget, monetization)
• legal (contracts, compliance, customer privacy). 

These teams may differ from organization to organization, but ensure you listen to your teams and ask them to identify issues you may have missed. With this information, you can start creating your migration plan.

2. Carefully Create Your Migration Strategy

A successful email migration requires careful preparation and an “all hands on deck” approach from all internal teams. You must agree upon, write down, and flawlessly execute every pre-migration, migration, and post-migration timeframe and activity. To do so, you’ll need a well-put-together plan. If you don’t take the appropriate time to make one, you could cause delays or data loss for your users.

Decide on the following goals and expectations for your migration strategy:

• timeframe – do you have specific deadlines; will the migration take ten or 60 days? Remember, for larger email platforms, a migration can take anywhere from two to ten weeks, depending on which data you’re migrating and its volume, the migration methodology, and how many users you have.
• inactive users – what happens with inactive users (users who haven’t been active for more than six months)? Will they be manually migrated, deleted, or notified of the migration separately? For example, with Axigen, you can start migrating inactive users manually after migrating active users.  
• domains – how many domains do you need to migrate: a single big one or multiple small ones? Or a mix of the two? 
• scope – what are you moving (email data, calendar, contacts, tasks, user configurations, or all of these)? 
  data integrity – what data are you cleaning up prior to the migration? How long will this take, and who will ensure data integrity?
• methodology – which migration methodology will you use (automatic, staged, third-party, or hybrid deployment), and what are the pros and cons of each one?
• internal constraints – what privacy regulations, internal rules, or government regulations must you adhere to? For example, you may have to fulfill a lawful intercept request during a migration; will you be prepared?
• expert analysis – will you require the help of experts such as DNS or security teams? What staffing do you need for the migration? Who will create and take action on the customer communication plan?
• spam filters – ask end-users what spam and malware filters they’ll use following migration (Axigen is equipped with an extensive security feature set). 

Make these decisions early, with any involved teams, as they’ll affect the flow of future activity planning and timelines. Once you have all details squared away, you’ll want to let end-users know of any pertinent details.

3. Design the Customer Communication Plan

The migration must be communicated with end-users. We can’t restate this point enough. After every internal team is on board, the migration process must be as transparent as possible at every stage of the journey, so users experience a smooth transition.

For example, every service provider should let users know:

• what data you’re migrating and what data you’re not (if you’re not migrating the trash folders from users’ inboxes, let them know to avoid inconveniences)
• when the migration will happen
• what will happen to email messages during the transition
• how their email clients will behave and if they have to make any manual settings

• provide training, a landing page, a newsletter, or any other form of communication that details the new experience to help them learn about changes in functionalities, features, archiving, account, or password setups.

Additionally, ensure users have enough support to make changes or tweaks themselves. For example, some users may need to change their DNS settings after a migration (although you should try avoiding this). You may also consider archiving older emails to prevent network slowdowns after migration and let users know how they can access their archives.

Pro tip: include a risk assessment that will let users know what plan B is in case of unforeseen circumstances and who will mitigate each risk.

You’ll know you’ve successfully communicated the migration process with your end users from the number of support interactions. If you have a few customer support tickets, good job! Conversely, user confusion and irritability can lead to higher call volumes, delays in email migration, or loss of brand reputation and customers.

4. Be Diligent and Don’t Skip Any Steps

Once all stakeholders know your next steps, you’re ready to execute your migration plan! Good thing you were so thorough with it, right?

One of the first things you want to do is focus on the switchover. As such, it’s crucial to set a migration timeframe.

Next, you’ll want to monitor how many users and what percent of those users are self-migrating over a certain period (typically two to three weeks). You can then migrate the rest of the users manually with a password reset (inactive users can be migrated with a password reset or simply left behind).

Thankfully, Axigen offers 24/7 technical support to make your migration as smooth as possible. With Axigen’s automatic migration, you’ll want to consider the following points:

• You can enable automatic migration for the domain and the migration is configurable for each domain
• You can rename the folders containing ’/’ characters
• You’ll want to pay attention to POP3 duplicates
• You don't need a migration file; accounts are migrated 1:1
• You don't need to create new user accounts for each user; they get created automatically after the DNS switchover on the first end-user client login (IMAP / SMTP / POP3 / WebMail / ActiveSync).

To configure the migration, follow the three steps below:

1. Create the domain to be migrated
2. Configure the domain within the Automatic Migration section
3. Enable the automatic migration for the domain.

Note! The above steps work from WebAdmin; if you’re configuring from CLI, it’s a manual configuration that uses CLI commands. You can find more documentation on this here. 

Can You Migrate to Axigen?

Of course, you can migrate to Axigen! In fact, it’s pretty easy, and you can find the documentation for an Axigen migration here. Remember, for any type of migration, best practices include:

1. figuring out your “why” before you get started 
2. creating your migration plan
3. communicating all points with end-users 
4. be diligent and don’t skip any steps.