This article outlines the considerations when Mimecast accounts need to be consolidated, or if a Mimecast customer has acquired another business and wants to integrate the email management services into their primary account.
If you're an Advanced Account Administration client, contact your Account Manager, as there are additional factors to consider outside of this documentation.
When two Mimecast customer organizations merge, it is usually required that all archived data be transferred into one storage account. Customers choose this option in order to have a single archive, and to manage all internal users in one account. Later in this article, we will cover the considerations for extracting and importing data, and managing the user migration.
When a Mimecast customer acquires a different organization, ingestion of their email data into the Mimecast archive, as well as the migration of users should be considered. It is common to require address rewriting for the secondary domain to the primary domain, among other options detailed below.
Before making any changes, it is important to consider the end user experience and the migration of user data:
- Will new administrator roles be required?
- Are new internal domains going to be added?
- Will address rewriting be required? For example, user addresses should be name@companyA.com, but are currently name.surname@companyB.com.
- Will users be migrated gradually, or will they all be switched over in one batch?
- Is mailbox delegation required? For example, jsmith@companyA.com must still be able to access emails for john.smith@companyB.com.
- Should the policies currently in place for Company A users, be implemented for Company B users, or will there be a variation for the different user groups?
- Will the new users be migrated to the existing network directory and email server? Mimecast recommends reviewing the Connect process for the routing of emails.
- Should the user's legacy data be available in their personal Mimecast archive?
Answering these questions will assist you with the preparation and implementation steps outlined below.
Preparing Your Mimecast Account
It may be necessary to add additional administrators to your main Mimecast account. For example, during a merger, the existing email administrator may need to continue in their role for the parent organization. For more information on configuring administrators and permissions, view the related article on roles. If required, training options are also available. Additionally, it is recommended to add new administrators to early warning alerts issued by Service Monitor.
If additional infrastructure is being added or consolidated, you may need to adjust the items detailed in these articles:
|Advanced Account Administration: Managing Internal Domains||The domain names that will be controlled in your Mimecast account.|
|Outbound||The IP addresses or hostnames that transmit emails to Mimecast. You may need to adjust your email server settings to route emails to Mimecast.|
|Directory Synchronization||Synchronizing the users from the local directory.|
|Journaling||Archiving of internal emails.|
|Configuring Delivery Routing Definitions and Policies||Delivering emails from Mimecast to your email servers.|
|Connect Process: Setting Up Your Inbound Email (at this preliminary stage, specifically MX Records)||To route inbound emails to your Mimecast account, and lock down the firewall to only accept emails from Mimecast.|
Policies and Groups
Your existing Mimecast account has a number of rules that apply to internal users. Once the new users are routing emails through your account, you may want to consider if the same rules apply to the new users, or if a different set of rules is required.
Many Policies are based on Mimecast groups or Active Directory groups. Adjustments to the policies or creation of new groups may be required.
Policies that should be considered are listed below. You can view the active policies for your account in the Consolidated Policy Viewer.
- Secure Receipt Policies / Configuring Secure Delivery Definitions and Policies to encrypt connections with TLS or CCM.
- Configuring Anti-Spoofing Policies to prevent spoofing.
- Block Senders Policies
- Configuring Email Size Limits Policies
- Configuring Attachment Management Definitions and Policies
- Configuring Spam Scanning Definitions and Policies and Configuring Digest Sets Definitions and Policies
- Configuring Content Examination Definitions and Policies and Configuring Document Services Definitions and Policies
- Configuring Auto Response Definitions and Policies
- Creating a Stationery Policy to brand emails and add disclaimers.
- Mimecast Synchronization Engine (MSE) - possible changes to Exchange, file archive, and instant message archive tasks.
User personal Policies could also be imported into Managed Senders.
Once the preparations for your Mimecast account have been planned or implemented, it is important to consider how the user experience will be affected during and after the migration.
Depending on the scenarios listed below, you may need consider different strategies. As an example, Company A (companyA.com) is merging with or has acquired Company B (companyB.com).
|Migrating users keep their own domain name and email addresses||This is the simplest form of domain consolidation, as the new details are added to your Mimecast without requiring changes to user email addresses. The preparation steps listed earlier in this article must be considered in order to add the new users to your Mimecast account|
Migrating users will be gradually migrated to new email addresses
Migrating users have to immediately change their email addresses
The recommended practice for larger organizations is to migrate users in groups, as it allows administrators to control the migration without impacting all users at once. Mimecast recommends notifying the users of the impending changes before they take place.
The following elements should be considered:
|All users will move to a unified domain name and new email addresses|
The following elements should be considered:
Important note: Email addresses must always be unique. For example, when these email addresses exist:
A new address will need to be considered for one of the two users. For example:
- john.smith@companyA.com (the user retains their address).
- jsmith@companyA.com (the migrated user will change their address).
This may also make it more challenging to give this migrated user access to their historical emails as described in mailbox delegation.
Users may expect to have access to their historical emails within their personal archive. As Ingestion takes place as a separate process and time frame, it is important to consider if:
- it is acceptable that historical emails will become available gradually over a period of time.
- it is required to make all available historical data available as soon as the users have been migrated.
Your Mimecast representative will consult with you to ensure that appropriate expectations are met. Ingestion services do not provide instant data transfer, and it may be some time before archived data is available for users. For more information, view the The specified item was not found. space.
The prerequisites before ingestion can commence include:
- Inbound, outbound and internal email flow needs to be fully archiving in the new account. For internal emails, the journal date must be identified.
- Full details of the source and destination accounts must be included with the ingestion request.
- The data to be migrated must be clearly defined (e.g. all internal domain user data or alternatively subsets of data).
Access to the data should also be considered, as outlined in the address alterations and mailbox delegation sections above.
If the amount of data to be transferred is significant, the old account may remain open for specified period of time. Once the cut-off date is reached, the account is closed and the data is no longer available in Mimecast. You would be able to choose one of the following strategies for providing users with access to their personal archive during the time that the old account is available:
|Allow users to access their personal Archive in the old Mimecast account||Users have access to their full historical Archive for their old email address||Users will not see new emails being added to their old account Archive, as these are routed through their new email address|
|Allow users to access their personal Archive in the new Mimecast account||Users have access to all emails for their new email address, including current emails||Users will not have access to the Archived emails for their old address|
Deploying User Applications
Now that users have been migrated, you can consider the deployment of Mimecast apps.
Application Settings must be configured to outline the permissions that users will have, and the features that will be made available to them. See the Configuring Application Settings article for more info.