Acmecorp as a group has several groups operating their emails on independent domain names such as acme.com, acmeiu.com, acmetm.com etc (totally 15 domains). Each of these email domains are hosted and maintained by various different email service providers (assumption). The total number of email users on all these domains is about 4000, which constitute the staff of the groups.

1. Acmecorp would like to consolidate all these independent email domains into a single common email domain, which will have email IDs of all users across the groups.
2. They would like to have a single point secure centralized email setup which can be managed and maintained at one point, while being accessed by the distributed users over the MPLS cloud.
3. They would like to keep alive the independent domains to continue receiving mail from the external world (where the old email ids are recorded in the address books of the senders), while ensuring that the mail received by an id on the independent domain is routed to the corresponding id on the common domain.

Zero disruption in the mail flow and mail access to end users, while performing the consolidation.

Over the several such deployments done, where Mithi has consolidated heterogeneous distributed setups, Mithi has worked out an approach which achieves the requirement with near zero disruption to the end user. Features in Connect Xf like multi tenancy, domain aliasing, password policies, and individual auto replies, further ease this task.

We propose not to migrate mail store from old server to the Mithi server since it is a very involved exercise and has to be done via a tool which connects over the IMAP protocol. This approach is chosen since the mail store formats of various mail server products may vary and the store cannot simply be copied or directly translated. The challenge with the IMAP sync approach is that we would need to get passwords of the users since the connection is authenticated. This is not a very user friendly exercise. Hence our approach is to let the users download their mail to a local store (PST if they are using Outlook or MBOX if they are using Thunderbird, or whichever is the relevant format) and then starts afresh from the new mail server.

Since the number of users are very large, you can use Connect Xf's address book features to distinguish users while searching for contacts or composing mail. The display name can be customized to contain defining fields like name/designation/department/office/location etc. The clients connect online to the address book store over LDAP and automatically display relevant ids (auto complete) as you type the address.

• Prepare the final list of email ids on the common domain by combining the user ids from the 15 domains into a single list.
• Resolve duplicates (example: john@acme.com and john@acmetm.com) by appropriately renaming the ids (depending on policy).
• Mithi recommends that you use the standard international format of firstname.lastname@commondomain.com
• Prepare a map which correlates the user on the independent domain to the user on the common domain, e.g.,
  john.d@acme.com = john.doe@acmecorp.com
  jane@acmetm.com = jane.doe@acmecorp.com
  ...
• Prepare the changes to be done on the desktop client
  Incoming server name: pop.acmecorp.com
  Outgoing server name: smtp.acmecorp.com
  Address book server name: ab.acmecorp.com
• Prepare a password for each user since we won’t be able migrate passwords from the existing systems

• The setup to have the common email domain with all the 4000 odd email boxes created.
• The setup to also have the independent 15 domains created with the corresponding email ids without a mailbox though.
• Setup connected to the Internet cloud to send and receive mail from the Internet.
• Setup connected to the MPLS cloud to allow distributed users to access their mailboxes using any client of choice.

• Based on the map, alias all mail being received by the independent domains to the corresponding user on the common domain.
• Configure the remaining parameters of the domains and servers like policies, etc.
• Configure an auto reply for all users of all the independent domains to inform senders that their email id has changed (while still accepting the mail though).
• Configure password expiry such that the user is forced to change his password on first login (since he has started with a fresh password).

• Change MX pointer of the common domain to this setup.
• Inform users on the common domain to download all their mail from the old server.
• Re-configure the desktop clients of the users on the common domain to connect to the new mail server using the host names provided.
• While reconfiguring the desktop clients, the users can access their mailboxes using the web mail client.
• Observe and resolve end user queries if any.

• Change MX pointer of the specific independent domain to this setup.
• Inform users on this domain to download all their mail from the old server (which would have stopped receiving mail by now).
• Re-configure the desktop clients of these users to connect to the new mail server using the host names provided (common domain).
• While reconfiguring the desktop clients, the users can access their mailboxes using the web mail client.
• Now the users of the old domain have new email ids on the common domain. When they send out mail, the mail will go with their new ids.
• Mail from their old contacts who have their old email id (of the independent domain) will continue to be received and will be routed to their corresponding new id.
• Observe and resolve end user queries if any.

• The pace would be entirely dependent on the comfort level of the internal IT team to handle end user queries.

Mithi has performed several such migrations but notably, Alliance Tire Company, where 7 independent domains running on different email servers like Exchange, pure hosted, etc were merged into one domain on Connect Xf. These domains and email servers were hosted in India and in the USA. The migration was done in phases, one domain at a time, with zero downtime of email access to the end users.