Directory Synchronization - Using Multiple Directory Synchronization Connectors

Updated August 18, 2026 13:41

This article explains how to safely use multiple Directory Synchronization Connectors in a single Mimecast tenant, with a focus on migrations between Microsoft 365 (Azure AD / Entra ID) and Google Workspace. It covers how Mimecast handles users, attributes, and groups from different directory sources, the risks of long-term coexistence, and migration planning patterns
It also explains how to plan and execute a controlled migration and cutover between Azure AD and Google Workspace environments, and when to contact Mimecast Support or Professional Services.

Overview

Mimecast supports synchronizing directory data from multiple identity providers (IdPs), such as Microsoft 365 (Azure AD / Entra ID) and Google Workspace, into a single Mimecast tenant. This is especially useful during migrations and cutovers when you need both platforms active for a limited time.

Considerations

When using multiple Directory Synchronization Connectors, keep the following in mind:

Attribute conflicts: If the same user exists in multiple directories with different attribute values (for example, job titles), Mimecast uses the value from the most recent synchronization. The last sync to run overwrites previous values, and conflicts continue as long as overlapping syncs remain active.
Separate groups: Groups from different directory Connectors remain separate objects in Mimecast, even if they share the same name. They are not merged and can be mapped independently in policies.
Overlapping identities: If both directories contain the same user records or share the same email domains, overlapping syncs can introduce duplicate records, attribute inconsistencies, and group membership changes over time.
Long-term coexistence risk: Running Directory Synchronization from both Microsoft 365 and Google Workspace for the same user set is technically possible, but not recommended as a long-term configuration due to fragility and administrative complexity.
Scoped user sets: If Microsoft 365 and Google Workspace serve different user populations (for example, distinct domains or business units), scoping each Connector by domain can safely separate them and reduce conflict risk.
Migration-only overlap: Multiple Connectors should be used as a temporary measure during migration and testing. Plan to disable or remove legacy Connectors once the new directory is validated.

Prerequisites

Before configuring or changing multiple Directory Synchronization Connectors, ensure you have:

Access to configure Directory Synchronization Connectors for Microsoft 365 (Azure AD) and / or Google Workspace in Mimecast.
Access to configure mail routing, delivery routes, and journaling in your email platforms (Microsoft 365 or Google Workspace).
Clear understanding of which domains and user populations each directory will manage, especially when separating user sets by domain.
Knowledge of existing Mimecast policy scopes, domains, and groups that depend on directory synchronization.
Alignment between your directory environments (for example, on-premises AD and Azure AD) so data is consistent before switching Connectors.

How Mimecast handles multiple directory sources

Mimecast can simultaneously synchronize from more than one directory source into a single tenant. This section explains how users, attributes, and groups behave when multiple Connectors are in use.

Multiple connectors in one tenant

Mimecast supports having multiple Directory Synchronization Connectors in a single tenant. You can configure both Microsoft 365 (Azure AD) and Google Workspace to sync into the same Mimecast environment at the same time. This is particularly useful during migrations and cutovers where you need to test or run both platforms temporarily. Mimecast does not require you to remove an existing Connector before adding another.

Users and attributes from different sources

Mimecast accepts user attributes from more than one directory source. Attributes from Microsoft 365 (Azure AD), Google Workspace, and other directories can coexist in Mimecast. You do not need to delete or remove attributes from one directory before introducing another.

To distinguish attributes from each source, use the attribute configuration’s group column. This lets you separate or identify which attributes originate from each directory.

When the same user exists in more than one directory and those accounts have different attribute values (for example, different job titles or departments), Mimecast applies the value from the most recent synchronization. The last sync to run “wins” and overwrites the previous value for that attribute. Attribute conflicts will persist as long as overlapping Directory Synchronizations are active for the same users.

Groups from multiple connectors

Groups imported from different directory Connectors are kept separate inside Mimecast. Each directory source has its own unique identifier, so groups from different sources are not merged, even if they share the same name. A group from Google Workspace and a group from Microsoft 365 (Azure AD) with the same name remain distinct objects and can be mapped separately in Mimecast policies.

If you have overlapping user objects across directories (for example, the same email address represented in both Microsoft 365 (Azure AD) and Microsoft 365 (Azure AD), synchronization can introduce inconsistencies. Duplicate user records and mismatched attributes can cause users to be removed from or added to different group memberships over time. You should verify that overlapping users are reconciled and aligned before relying on cross-source group membership behavior.

Risks and limitations of running overlapping connectors

While Mimecast allows overlapping Connectors, long-term coexistence for the same user set introduces several risks and limitations.

Why long-term coexistence is discouraged

Running directory synchronization from both Microsoft 365 (Azure AD) and Google Workspace for the same user population is not recommended as a long-term configuration. Although Mimecast can technically sync from both sources at once, this creates multiple risks:

Attribute conflicts: Differences in user attributes between directories (such as job titles or departments) result in the most recent sync overwriting the other source’s values. Data can repeatedly change as different syncs run.
Fragile configuration: In theory, coexistence can work if both directories contain identical attributes and groups for each user. In practice, this is fragile and can easily break with normal directory updates or changes.
Administrative confusion: Because groups from each directory are separate and policies can be mapped to either, maintaining multiple active connectors can lead to confusion about which directory is driving specific policies.

A safer approach is to use a single Directory Synchronization for a given user population and disable or remove the old connector once migration and testing are complete. Leaving unused Connectors in place can also lead to stale or duplicate sync entries over time.

Scope and separation of user sets

If your Microsoft 365 (Azure AD) and Google Workspace environments serve completely different user sets (for example, different email domains or business units), Mimecast can keep them separate. When configuring or updating a Directory Synchronization Connector, you can restrict which domains are synchronized so each connector is responsible only for its intended domains. This helps avoid accidental overlap and reduces the risk of conflicting data for the same users.

Planning a migration between Microsoft 365 (Azure AD) and Google Workspace

When moving Directory Synchronization between Microsoft 365 (Azure AD) and Google Workspace (in either direction), you should plan for a controlled period during which both Connectors are present but tightly managed. The following best practices apply when:

Migrating from Google Workspace to Microsoft 365 (Azure AD).
Migrating from one Microsoft 365 tenant to another.
Consolidating Google Workspace domains into a single tenant.

Across these scenarios, the guidance is consistent; introduce and validate the new connector first, allow a controlled overlap for testing and cutover, then remove the legacy Connector after validation.

High-level migration pattern

Create and configure the new Directory Synchronization Connector for the target platform (for example, Azure AD when moving from Google Workspace, or a new Azure AD tenant when changing Microsoft 365 tenants).
Keep the existing connector (for example, Google Workspace or the old Azure AD tenant) in place while you test the new connector and confirm that users and groups are syncing correctly.
Remap Mimecast policies and routing to use groups and domains from the new directory.
Once mail flow, policies, and directory objects are confirmed and stable, remove the legacy Connector so that only the new Connector remains.

Cutover checklist - Google Workspace to Microsoft 365 (Azure AD)

This section provides a step-by-step cutover checklist for migrating from Google Workspace to Microsoft 365 (Azure AD) or for similar scenarios where Google Workspace and Microsoft 365 (Azure AD) coexist during migration.

1. Add and configure the new Azure AD connector

When migrating from Google Workspace to Microsoft 365 (Azure AD), begin by creating a new Microsoft 365 (Azure AD) Directory Synchronization Connector in Mimecast. See Administration - Managing Connectors.
Do not delete the existing Google Workspace Directory Synchronization at this stage. Mimecast supports multiple directory integrations, so both providers can be configured during the cutover.
When adding Microsoft 365 (Azure AD), Mimecast automatically creates a new root folder for the .onmicrosoft directory under the root in Directories. This reflects the new tenant’s directory structure within Mimecast.

2. Configure Google Workspace routing and directory sync (when adding Google to an Azure tenant)

In scenarios where you are adding Google Workspace to a Mimecast tenant that already syncs Microsoft 365 (Azure AD), you must complete the full Google integration alongside directory sync. This includes:

Setting up inbound mail for the Google Workspace domain.
Configuring a delivery route for Google Workspace.
Configuring Directory Synchronization for Google Workspace.
Adding the Google Workspace domain to Mimecast Authorized Outbounds (completed by Mimecast Support).
Configuring journaling for Google Workspace.

Follow the relevant product documentation for each of these steps, based on your specific migration direction:

3. Validate synced objects and attributes

After creating the new Connector:

Confirm that users and groups from the new directory appear correctly in Mimecast.
Use the attribute configuration’s grouping to distinguish attributes from each source, rather than deleting existing attributes from the previous directory.
Check that group memberships align with expectations and that overlapping users do not show unexpected group changes.

If the same users exist in both directories, be aware that any differences in attributes can cause Mimecast to switch values based on whichever directory sync runs last.

4. Remap group-based policies

When transitioning from one directory source to another, e.g., from Microsoft 365 (Azure AD) to Google Workspace, or from on-premises AD to Azure AD, any Mimecast policies that reference groups must be updated to point to groups from the new directory. Because Mimecast keeps groups from each directory separate and does not merge them, this remapping step is essential.

The recommended approach is:

Configure the new directory Connector and confirm that it has imported the required groups.
Update policies so that their scopes reference the equivalent groups in the new directory.
Remove or retire the legacy directory Connector once all policy scopes have been updated and validated.

This avoids reliance on legacy groups and keeps the policy configuration aligned with the new authoritative directory.

5. Handle domains, routing, and journaling changes

When changing platforms (for example, moving between Google Workspace and Microsoft 365 (Azure AD) or consolidating Google domains), Directory Synchronization is only one part of the migration. You must also update mail routing and journaling for the new platform:

Ensure inbound mail routes are correctly configured for the new platform’s domains.
Update or configure delivery routes for the new environment.
Confirm journaling is set up for the new platform and that Mimecast is receiving journal messages as expected.
Work with Mimecast Support to add any new domains to Authorized Outbounds where required (for example, when adding Google Workspace domains).

In domain consolidation scenarios within Google Workspace, ensure all users from the domain you plan to remove are fully synced into the target tenant first. After that, you can safely disable or remove the Directory Synchronization Connector for the retiring domain.

6. Test in a controlled environment

To reduce risk, test new Directory Synchronization configurations before broad deployment:

Where possible, test the Google Workspace or Microsoft 365 (Azure AD) sync against a non-production or test email domain first and verify results before fully switching over.
Perform major changes during a maintenance or non-impact migration window.
Confirm user and group synchronization, as well as related features like authentication and lookups, after changing connectors.

This controlled testing phase allows you to validate configuration and behavior while retaining the option to roll back if needed.

7. Disable and remove the legacy Connector

Once the new Directory Synchronization Connector is stable and your policies, routing, and journaling all align with the new platform:

Delete or remove the old Directory Synchronization integration used for the source tenant or previous platform.
This applies when moving between Microsoft 365 tenants, switching from Google Workspace to Microsoft 365, or consolidating Google domains.

Removing unused Connectors prevents stale or duplicate sync entries and keeps your Mimecast directory configuration clean. It also stops ongoing attribute conflicts where the original directory might otherwise continue to overwrite values from the new authoritative source.

Warnings and recommendations

This section summarizes key best practices for safely using multiple Directory Synchronization Connectors.

Use one authoritative directory per user set

For any given user population, designate a single directory source as authoritative. While Mimecast supports multiple Connectors, running syncs from two platforms for the same users should only be a temporary state during migration. Plan to disable the original sync once the new directory is fully validated and in production.

Avoid unmanaged overlap

If both IdPs contain the same user records and share the same email domains, exercise particular caution. Without clear scoping (for example, by domain) and a defined cutover plan, you can encounter duplicate entries, attribute conflicts, and group membership inconsistencies. Ensure overlapping identities are reconciled and that the new environment has the correct data before you configure Mimecast to use it as the primary source.

Plan and document before switching

Before making any major change to Directory Synchronization, review and document:

Existing policy scopes, domain mappings, and rules that depend on specific groups or alias domains.
Any features or workflows that rely on Directory Synchronization, such as authentication or user lookups.
Any attributes or group structures that must be preserved in the new directory.

Plan changes for a maintenance window and ensure your directory environments (for example, on-premises AD and Azure AD) are consistent before switching Mimecast to a new Connector.

Field / Option	Description
Attribute configuration group column	Use this column to separate or distinguish attributes coming from each directory source (e.g., *Microsoft 365* (*Azure AD) vs Google Workspace) instead of deleting attributes from a previous Connector*.
Directory domains scope	Controls which domains are synchronized by each *Connector, allowing you to keep different user sets separate and avoid overlap between Microsoft 365* (*Azure AD) and Google Workspace*.

Frequently asked questions

Q:	Can I run Microsoft 365 (Azure AD) and Google Workspace directory sync at the same time in one Mimecast tenant?
A:	Yes. Mimecast supports multiple *Directory Synchronization Connectors* in a single tenant, including *Microsoft 365* (*Azure AD) and Google Workspace*, and they can be active at the same time. This is typically used during migrations and cutovers. However, for the same user population, this overlap should only be temporary due to the risk of attribute conflicts and administrative complexity.
Q:	What happens if the same user exists in both Microsoft 365 (Azure AD) and Google Workspace with different attributes?
A:	If the same user exists in multiple directories and their attribute values differ, Mimecast uses the value from the most recent synchronization. The last sync to run overwrites the prior value for that attribute, which can cause data such as job titles or departments to change repeatedly as different syncs run.

When to engage Mimecast Support or Professional Services

In some migration or multi-Connector scenarios, it may be helpful to involve Mimecast Support, or Professional Services.

Mimecast Support

Contact Mimecast Support in the following situations:

You need to add new domains (for example, Google Workspace domains) to Authorized Outbounds.
You are changing or migrating server Connectors and want configuration tested and validated.
You encounter unexpected behavior during or after directory Connector changes that you cannot resolve through standard configuration steps.

Mimecast Professional Services

If you prefer structured, project-style assistance for complex migrations (such as running Google Directory Synchronization and Azure AD Directory Synchronization side by side and planning the cutover), engage Mimecast Professional Services. They can guide the end-to-end implementation, help design the migration plan, and support testing and validation activities tailored to your environment.