Migrating Azure SQL Database Across Tenants Using Subscription Transfer

Moving an Azure subscription between Microsoft Entra ID (formerly Azure Active Directory) tenants is a common requirement during:

• Mergers and acquisitions
• Organizational restructuring
• Enterprise Agreement (EA) enrollment realignment
• Lighthouse or multi‑tenant operating model changes

However, when that subscription hosts Azure SQL databases secured using Microsoft Entra ID authentication, the migration becomes identity‑dependent and must be executed carefully.

Microsoft Entra ID identities are tenant‑scoped. During a cross‑tenant subscription transfer, identities from the source tenant are no longer trusted by the target tenant. This directly impacts:

• Azure RBAC role assignments
• Azure SQL Entra ID logins
• Managed identities
• Application authentication tokens

If authentication sequencing is not handled correctly, administrators and applications can lose access to Azure SQL immediately after the migration.

This article provides a proven enterprise‑tested 8‑step migration playbook to safely migrate Azure SQL workloads across Microsoft Entra ID tenants without administrative lockout or application downtime.

Migration Overview

The migration follows a three‑stage operating model:

Before Subscription Transfer (Source Tenant)

• Export RBAC assignments and SQL identity configuration
• Perform and validate a SQL backup

During Migration

• Temporarily enable SQL Authentication
• Ensure administrative access independent of Entra ID

After Subscription Transfer (Target Tenant)

• Configure new Entra ID administrator
• Recreate RBAC assignments and database principals
• Validate application connectivity

The diagram represents three distinct phases, which are explained below exactly as they appear in the flow.

Phase 1 – Pre‑Migration Preparation

Step 1 – Export SQL Server Logins, Database Users, Roles, and Permissions

Before initiating the subscription transfer, export all identity‑related configuration from the source Azure SQL Server.

This export serves as:

• A rollback reference
• A rebuild blueprint for the target tenant
• An audit artifact for change tracking

Capture the following:

Server Level

• Microsoft Entra ID users
• Microsoft Entra ID groups
• SQL Authentication logins

Database Level

• Contained database users
• Database role memberships
  • db_owner
  • db_datareader
  • custom roles

Azure RBAC Assignments On

• SQL Server
• Resource Group

Database Permissions

• GRANT
• DENY
• EXECUTE
• Object‑level access

✅ Subscription transfers always remove Microsoft Entra ID–based role assignments. Treat this export as mandatory.

Step 2 – Perform SQL Database Backup

Take a fresh backup immediately before migration.

Recommended enterprise options include:

• BACPAC export to Azure Blob Storage
• Native BACKUP TO URL
• Long‑Term Retention (LTR) snapshot

⚠️ A backup that has not been test‑restored is not a valid rollback strategy. Always validate restore operations in a non‑production environment before migration day.

Phase 2 – Migration Day Execution

Step 3 – Switch Authentication Mode (Entra ID ➜ SQL Authentication)

This is the most critical step in the entire migration workflow.

Before initiating the EA subscription transfer:

• Disable Entra ID–only authentication
• Enable SQL Authentication
• Validate SQL Administrator login

Why This Is Required

Microsoft Entra ID identities exist only within their original tenant.
Once the subscription is transferred:

• Source tenant identities become invalid
• Azure SQL logins mapped to those identities stop functioning

SQL Authentication provides a:

• Tenant‑independent authentication method
• Temporary administrative access path

Skipping this step may result in complete administrative lockout.

Step 4 – Migrate Subscription via EA Transfer

The EA transfer moves the subscription to the target tenant directory.

Preserved During Migration

• Azure resources
• SQL databases
• Database data
• SQL Authentication logins

Removed During Migration

• Azure RBAC assignments
• Entra ID SQL logins
• Managed Identity bindings

Phase 3 – Post‑Migration Configuration

Step 5 – Configure Microsoft Entra ID Administrator (Target Tenant)

After migration:

1. Assign a new Microsoft Entra ID Administrator to the Azure SQL Server
2. Use an Entra ID Group instead of an individual user
3. Optionally re‑enable Entra ID‑only authentication after validation

Using groups ensures identity continuity if administrators change or accounts are disabled.

Step 6 – Re‑Create RBAC Assignments and Database Identity Configuration

Using the exported configuration:

Reapply:

• Azure RBAC role assignments
• Microsoft Entra ID SQL logins
• Database users
• Role memberships
• Object‑level permissions

✅ Automation is strongly recommended for environments hosting multiple databases or elastic pools.

Phase 4 – Validation and Testing

Step 7 – Database Integration Testing

Validate:

• Entra ID administrator connectivity
• Application identity access
• Read and write operations
• Stored procedures
• Backup and restore functions
• Firewall rules
• Private endpoint connectivity

Step 8 – End‑to‑End Application Testing

Perform full application validation including:

• Authentication via Entra ID tokens
• Business transaction workflows
• Scheduled jobs and background services
• Performance baselines
• Error telemetry

Migration should be considered complete only after application owner sign‑off.

Common Migration Pitfalls

Migration Checklist

Pre‑Migration

• Export SQL logins, users, roles, permissions
• Export Azure RBAC assignments
• Perform full database backup
• Test restore in lower environment
• Enable SQL Authentication
• Validate SQL Admin login

Migration Day

• Switch authentication mode
• Store SQL admin credentials securely
• Initiate EA transfer
• Accept transfer in target enrollment
• Confirm subscription visibility

Post‑Migration

• Configure Microsoft Entra ID Admin
• Reapply RBAC assignments
• Recreate SQL Entra ID logins
• Recreate database users
• Reassign roles and permissions

Validation and Sign‑Off

• Database validation complete
• Application validation complete
• Performance baseline verified
• Security review approved
• CAB approval obtained
• Migration documentation completed

Conclusion

Cross‑tenant Azure SQL migrations succeed or fail based on authentication sequencing.

Temporarily switching from Microsoft Entra ID authentication to SQL Authentication prior to subscription transfer—combined with disciplined RBAC export and re‑application—provides a:

• Safe
• Repeatable
• Auditable

migration strategy.

This approach scales from single‑database migrations to enterprise‑wide SQL estates and is particularly suited for regulated environments where downtime and access risk must be tightly controlled.