Account Settings - Mergers and Acquisitions

This article contains information on merging two Mimecast customer organizations, covering data migration, user migration, address alterations, policy adjustments, and infrastructure considerations to ensure a seamless transition and unified management.

If you're an Advanced Account Administration client, contact your Account Manager, as there are additional factors to consider outside of this documentation.

Mergers

When two Mimecast customer organizations merge, all archived data is usually required to 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 user migration.

Acquisitions

When a Mimecast customer acquires a different organization, ingestion of their email data into the Mimecast archive and 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.

Considerations

Before making any changes, it is important to consider the end-user experience and user data migration. Answering these questions will assist you with the preparation and implementation steps outlined below:

1. Will new administrator roles be required?
2. Are new internal domains going to be added?
3. Will address rewriting be required? For example, user addresses should be [e-mail] but are currently [e-mail].
4. Will users be migrated gradually, or will they all be switched over in one batch?
5. Is mailbox delegation required? For example, [e-mail] must still be able to access emails for [e-mail].
6. 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?
7. 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.
8. Should the user's legacy data be available in their Mimecast archive?

Answering these questions will assist you with the preparation and implementation steps outlined below.

Preparing Your Mimecast Account

Administrators

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.

Local Infrastructure

If additional infrastructure is being added or consolidated, you may need to adjust the items detailed in these articles:

Feature	Description
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 several 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 the 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.

1. Secure Receipt Policies / Configuring Secure Delivery Definitions and Policies to encrypt connections with TLS or CCM.
2. Configuring Anti-Spoofing Policies to prevent spoofing.
3. Blocked Senders Policies
4. Configuring Email Size Limits Policies
5. Configuring Attachment Management Definitions and Policies
6. Configuring Spam Scanning Definitions and Policies and Configuring Digest Set Definitions and Policies
7. Configuring a Content Examination Definition and Policies and Configuring Document Services Definitions and Policies
8. Configuring Auto Response Definitions and Policies
9. Configuring Stationery to brand emails and add disclaimers.
10. 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.

User Migration

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.

Address Alterations

Depending on the scenarios listed below, you may need to consider different strategies. As an example, Company A (companyA.com) is merging with or has acquired Company B (companyB.com).

Scenario	Considerations
Migrating users keep their 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 to add new users to your Mimecast account.
Migrating Users will be gradually migrated to new 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: Address Alteration: The old address can be automatically rewritten by Mimecast (both inbound and outbound) to the new address. For example, [e-mail] is rewritten to [e-mail]. See the Configuring Address Alteration Definitions and Policies article for more info. Automatic linking of aliases: The user can use a Mimecast app to access their primary SMTP address mailbox if enabled. Any emails for alias address mailboxes linked to this primary address will be displayed within the primary mailbox address. For example, [e-mail] logs in with a Mimecast app and can access emails from [e-mail]. This is controlled through Directory Synchronization. Delegate Mailboxes: The old address mailbox is accessible from the new address Mailbox. For example, [e-mail] can access the mailbox for [e-mail] See the End User Applications: Configuring Delegate Mailbox Access article for more info. Forwarding Address: It may be required to automatically forward all emails from one mailbox to another. For example, emails to [e-mail] are forwarded to [e-mail]. See the Configuring Forwarding Address Definitions and Policies article for more info.
Migrating users have to immediately change their email addresses
All users will move to a unified domain name and new email addresses	The following elements should be considered: Address Alteration: The old address can be automatically rewritten by Mimecast (both inbound and outbound) to the new address. For example, [e-mail] is rewritten to [e-mail]. See the Configuring Address Alteration Definitions and Policies article for more info. Automatic linking of aliases: The user can use a Mimecast app to access their primary SMTP address mailbox if enabled. Any emails for alias address mailboxes linked to this primary address will be displayed within the primary mailbox address. For example, [e-mail] logs in with a Mimecast app and can access emails from [e-mail]. This is controlled through Directory Synchronization. Delegate Mailboxes: The old address mailbox is accessible from the new address Mailbox. For example, [e-mail] can access the mailbox for [e-mail] See the End User Applications: Configuring Delegate Mailbox Access article for more info. Forwarding Address: It may be required to automatically forward all emails from one mailbox to another. For example, emails to [e-mail] are forwarded to [e-mail]. See the Configuring Forwarding Address Definitions and Policies article for more info.

Email addresses must always be unique. For example, when these email addresses exist:

•  
  •  
    • [e-mail]
    • [e-mail]

A new address will need to be considered for one of the two users. For example:

•  
  •  
    • [e-mail] (the user retains their address).
    • [e-mail] (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 the mailbox delegation.

Data Migration

Users may expect to have access to their historical emails within their archives. 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 some 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.

The prerequisites before ingestion can commence include:

•  
  •  
    • Inbound, outbound, and internal email flow need to be fully archived 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 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 a specified period. 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 archive during the time that the old account is available:

Strategy	Advantages	Disadvantages
Allow users to access their Archive in the old Mimecast account.	Users have access to their full historical Archive for their old email addresses.	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 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 addresses.

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 page for more info.

See Also...

• Policies - Address Alteration Configuration