Is the fear of migration holding you back from moving to a better performing-lower cost email platform ?

Fear of Migration holds many IT managers from migrating to a new platform, making them put up with high cost and/or poor performance.

This fear appears to be as much about running into surprises related to the performance, quality and functionality of the new platform as it is about ensuring a smooth, hassle free migration from the currently running email system.

But it’s not that difficult, a three step process can help you do this with much ease:

Mapping > Evaluation > Planning & Rolling Out

This post brings together years of experience of migrating and setting up small to very large email setups.


Map your requirements

Before you go hunting for a new mail and collaboration system, it’s important to work out your pain points and requirements by writing them down in a spread sheet and classify these items by priority – Critical, Important & Nice to Have

Here is a simple framework to map the scope and functional requirements in the table below. It is an indicative list and would need to be completed depending on your requirements. Many of these requirements will be a carry forward from your current use cases, which are served by your existing mail system.


—- SCOPE —-
Cost Performance Security Data Availability Users
Upfront Cost Uptime guarantees Spam/Virus control Mail archival for Compliance Mobility
Recurring cost Latency guarantees Mail flow policies Email Discovery Web Access to all apps
Payment Terms Burst handling capability Access control policies Backups, RPO, RTO Role based administration


Many of these requirements will be a carry forward from your current use cases, which are served by your existing mail system.

A simple sheet to map your requirements with priority and availability with the selected target solution (pertaining to an email system) is given in the table below (please note that the table is an indicative framework and is not an exhaustive list of features and requirements, which is beyond the scope of this article):


Requirement Scope Priority Description Vendor
99.9% uptime guarantee Performance Critical Vendor must provide an SLA guarantee for this
Integrated Web access Users Important End users can login to access all their apps and data via a unified web application
Scheduled vacation reply Users Nice to Have User can schedule their vacation reply
MFA access for Administrator console Security Critical Administrator can only login with 2 factor authentication


This mapping will help bring all the stakeholders onto the same page and will also make it easy for you engage with multiple vendors in a standard uniform way with the same baseline requirement.

Map your current environment

Document your current use cases, devices, locations, networks, users, security policies, usage patterns, integration etc.

Many a times, systems evolve over time and IT teams fall back on the work of documenting and maintaining the inventory of the elements in the system and the various use cases being served by this system.

To help you in this exercise use the work flows of

  • The End User (The actual consumers in your organisation) and
  • The Administrator (The person or team who will manage the system)

to decide on the criticality

Ensure that you have a detailed map of:

  • All the use cases in play currently e.g. Email accessed from iPhones, Shared Calendar events and meetings, Chat from mobiles, etc
  • A list of all the users, aliases and groups (distribution lists) in the system
  • A map of the various end point devices and clients being used. Typically in an email environment, this can be quite varied.
  • A comprehensive list of all security and access policies in place e.g. who can access email, from which service, who can send mail to whom, password policies, etc
  • All integration done with existing business applications within the company or externally (e.g. automatic provisioning by an HR system, ERP systems using this system to send alerts, etc.
  • A diagram of access by all end user groups (essentially all connection points to the servers) and their capacities
  • It would help to have reports on mail flows & access (number of mail in and out, average mail size, total size of mail transacted in a day, top senders, number of logins a day, etc)
  • Your current methods for achieving Compliance and data recovery using Mail Archival.

Knowing this upfront will help you in evaluating a new system and planning the migration.

Tip : You can use the sample requirement mapping sheet shown in the first step above for documenting the current setup as well.


Verify if all your use cases and requirements (mapped in the steps above) are supported adequately in the new solution.
  • What are the variations?
    You may find certain requirements are not met at all, or are met but need a different way to work with them (unlike what your users are used to) and some will work exactly or better than what you expected.
  • How does the new system rate on the comfort and ease of using all the selected devices and clients for EACH service/application.
    The End Users form the majority and most frequent users of the system.
  • How does the new system rate on Performance and Security?
    From an System Administrator point of view, besides ease of provisioning and managing the system, the critical factors to consider might be Performance (uptime and performance, difficult to ascertain during a POC, but the warranties can be reviewed in the SLA), Security (certifications, specific penetration tests, and verification of the archival and discovery capabilities) and Scale (will this solution grow with your needs and usage patterns…an easy way is to check with existing customer references)
  • What are the (shared) policies or limits applicable to your users when they use the system (especially true if you are opting for a cloud based shared hosted service)?

    E.g. the maximum mail size permitted, maximum data download in a day, maximum recipients in a mail, maximum number of mail in day by each user (rate), etc. Match all this to your current usage to see if any of these are show stoppers.

Planning & Roll Out

1. Planning

Decide Phases for the migration and update the operation documents

Answering some questions here, will help you decide on a strategy for roll out to end users.

  • What is involved to deploy the solution to the end points and migrate clients and devices to the new system?
  • What are the steps involved, and can the end user do it themselves, can it be done centrally and pushed to the clients, or will you need a local help-desk person to hand hold the end users through this?
  • What kind of documentation & training is required to prepare the users for the upcoming shift?
  • Will you need a L1 helpdesk to answer queries during the transition phase?

To help your Backend team manage the system, the maps and documents created by you in the first step (Map of the current system), need to be updated for the new platform.

Updating these detailed process and architecture documents, before you start any changes, will give you visibility, before you go ahead. Break down the roll out in phases with the first phase having the bare minimum steps to ensure a smooth transition and a start. It is, for example, best to avoid rolling out new features in Phase 1.

2. Training

Train of the IT team & educate the End Users

Hurrying to shift to the new system without adequate familiarity can result in more work for the IT teams.

Bring your IT team and end users upto speed on the new system well in advance.

Allow enough planning time to consider the possibility of unknowns and account for the training requirements for the various stake holders.

It’s important that the back end teams and the end users are aware and trained of all aspects of the change BEFORE the change.

3. Configure

Configure the new platform & verify functionality (UAT)

While keeping the current system running, configure and test the new platform for the expected functionality. This verification will be with your actual data, from the currently running system, and may or may not uncover some issues which you may have missed earlier.

4. Live

Go live process

At the designated time, perform the shift to the new system and monitor closely, the mail flow and access by end users. We suggest a full downtime during the shift period and if you have the option to arrest inbound mail at the security gateway, do so until the shift is complete and tested.

5. Monitor

Post go live hand holding and cleanup

In all likelihood, you would have shifted the MX pointer, which takes a while to reflect worldwide (depends on the TTL). So until this happens, the older mailing system will continue to receive some inbound mail and these would need to be migrated once the switch is done.

In Conclusion

Migrating an email system may be involved, but going about it systematically will ensure that there is less likelihood of surprises during the migration and more importantly none after you go live.

Watch out for a follow up post with a detailed checklist to help plan the migration to a new email platform.

An entrepreneur making a big impact on business team collaboration and enterprise data management using SaaS solutions architected with Artificial Intelligence, Big Data warehousing, Deep ediscovery, Mobility and Cloud platforms.

Leave a Reply

Your email address will not be published. Required fields are marked *


Privacy Policy | Terms of service