Overview
Tenant registration in Druva for Microsoft 365 establishes a secure connection to your M365 tenant using Global Administrator credentials. Currently, Druva operates on a one-to-one connection model per instance. This means it is not possible to concurrently manage and back up users from multiple M365 tenants within a single Druva configuration for workloads like Exchange Online and OneDrive.
During a Microsoft 365 tenant-to-tenant (T2T) migration, you cannot simply append the new target tenant alongside the source tenant. Instead, you must point your Druva application to the new target tenant or register it separately, map the new identities, and manage the lifecycle of your historical source data.
This guide outlines the critical stages to successfully transition your Druva backup infrastructure during an M365 T2T migration.
1. Preparation and Source Tenant Data
Before initiating the cutover, you must plan how to handle the historical backup data residing in the source tenant.
Maintain Access: Do not delete or immediately unregister the source tenant or its users from Druva. Keep the source tenant backups active to preserve historical data until your retention requirements are met.
Historical Data Retention: Because Druva treats the target tenant users as entirely new entities, historical continuity within the same backup thread is not maintained. If you require access to old backups indefinitely, you can either keep the source configuration in a deactivated/read-only state marking the users as Preserved within Druva or export critical data before disabling the source environment.
2. Setting Up the Target Tenant & App Reconfiguration
To point Druva to your new environment, you will need to reconfigure or establish the Microsoft 365 application link using global admin credentials from the target tenant.
Register the New Tenant: Log in to your Druva Management Console and initiate the tenant registration process using the new target tenant's Global Administrator credentials to grant the required permissions.
Configure the Druva App: Review your backup scope requirements and choose the appropriate Druva app deployment method:
Advanced App: Required if you need comprehensive protection across Exchange Online, OneDrive, SharePoint Online, Teams, and Azure AD/Entra ID directory sync.
Basic App: Suitable if your backup needs are strictly limited to Exchange Online and OneDrive without broader directory integration.
💡 Note: For specific, step-by-step app authorization steps and credential updates, refer to the Configure Druva inSync for Microsoft 365 guide.
3. Identity and Profile Mapping
Because Druva tracks users based on unique system identifiers and their User Principal Names (UPNs) or email addresses, changing tenants fundamentally changes the user entity.
User Identity Change: Even if a user keeps the same prefix (e.g., from user@source.com to user@target.com), Druva’s backend treats the target user as a completely new entity.
Profile Mapping: Once the target tenant is successfully connected and users are discovered via Azure AD/Entra ID, you must explicitly map these new target users to your corresponding Druva backup profiles to initiate their initial target backups.
4. Post-Migration Cleanup
Once the migration cutover is complete and data availability in the target tenant is verified, tidy up the source tenant infrastructure to optimize license usage.
Disable Source Users: Update the status of the source tenant users in Druva to prevent further backup attempts (which will fail post-migration anyway).
License Management: You can preserve the inactive source users to retain historical recovery points. Alternatively, if historical compliance is met, you can delete the inactive source users to free up your Druva license seats.
See Also