Azure SQL Database
An Azure relational database service.
Migration from Azure SQL Database to SQL Managed Instance on Azure
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(9.6, 13%, 10%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EGS%3C/text%3E%3C/svg%3E)
Georg Sieber
45
Reputation points
We have around 100 database in Azure SQL database in an elastic pool. We want to switch for various reasons to SQL Managed Instance like better support for cross database queries.
Our conditions are the following:
- We can only afford a short downtime (<10 minutes)
- We cannot make the source database read-only during the migration
- Due to size of some databases (~500GB) exporting to bacpac and importing to SQL managed instance takes a long time (multiple hours to export a database, multiple hours to import a database)
Since Azure SQL supports exporting databases only via bacpac we planned to export a current state of the database and import that into our SQL managed instance. Then we wanted to use change-tracking to keep source+target up2date and switch everything over.
However, this approach does not work since change tracking version numbers cannot be preserved while doing bacpac export-->import.
We are now hoping that Azure support has some internal tools to ease the switch from Azure SQL database to Azure SQL Managed Instance.
Best regards
Georg
Azure SQL Database
-
Ace Jerraldven C. Enoc 420 Reputation points2026-04-16T08:01:45.44+00:00 Hi Georg Sieber
There is no native, online, near‑zero‑downtime migration path from Azure SQL Database (single DB / elastic pool) to Azure SQL Managed Instance (MI). Azure Support does not have internal tooling that bypasses this limitation. With your constraints, BACPAC is not viable, and incremental replication must be implemented outside the built‑in migration stack.
Given your constraints:
- < 10 minutes cutover
- No read‑only window during migration
- Databases up to ~500 GB
- ~100 databases in an elastic pool
This is the most common approach when staying fully within Azure.
Pattern:
- Perform an initial bulk load of all tables from Azure SQL DB to SQL MI (parallelized; takes hours but no downtime).
- Enable Change Tracking on the source databases.
- Use ADF incremental pipelines to pull deltas and
MERGEthem into MI on a schedule (minutes). - At cutover, briefly pause writes, apply the final delta, and switch connection strings.
Why this fits your requirements:
- No need to make the source read‑only during the migration phase
- Downtime is limited to the final cutover (typically minutes)
- Scales to large databases and many databases
- Fully supported components (ADF + CT)
This approach requires engineering effort but is reliable and widely used.This is the most common approach when staying fully within Azure.
Pattern:
- Perform an initial bulk load of all tables from Azure SQL DB to SQL MI (parallelized; takes hours but no downtime).
- Enable Change Tracking on the source databases.
- Use ADF incremental pipelines to pull deltas and
MERGEthem into MI on a schedule (minutes). - At cutover, briefly pause writes, apply the final delta, and switch connection strings.
Why this fits your requirements:
- No need to make the source read‑only during the migration phase
- Downtime is limited to the final cutover (typically minutes)
- Scales to large databases and many databases
- Fully supported components (ADF + CT)
This approach requires engineering effort but is reliable and widely used.
I hope you find this helpful
♠ ♠ Ace ♠ ♠
-
Ahamed Musthafa Careem 481 Reputation points2026-04-16T08:46:29.0833333+00:00 Hi Georg,
You’re right to flag that moving from Azure SQL Database (elastic pool) to SQL Managed Instance isn’t as straightforward as a bacpac export/import, especially with large databases and strict downtime requirements. Bacpac is really designed for archival or smaller migrations, not for near‑zero downtime cutovers.
Supported migration options
1. Azure Database Migration Service (DMS)
- DMS supports online migrations from Azure SQL Database to SQL Managed Instance.
- It continuously replicates changes from source to target while keeping the source writable.
- At cutover, you stop replication and redirect connections.
- Learn more: https://learn.microsoft.com/en-us/data-migration/sql-server/managed-instance/guide#azure-database-migration-service-azure-dms
2. Transactional Replication
- You can configure replication from Azure SQL Database to Managed Instance.
- This keeps the target in sync until you’re ready to switch.
3. Log Replay Service (LRS)
- For very large databases, LRS can apply transaction log backups continuously to Managed Instance.
- This reduces downtime at cutover.
- Learn more: https://learn.microsoft.com/en-us/data-migration/sql-server/managed-instance/guide#log-replay-service-lrs
Suggested path forward
- Use Azure DMS in online mode to replicate your elastic pool databases into Managed Instance.
- Run continuous sync until the target is caught up.
- Plan a short cutover window (<10 minutes) to stop sync and redirect connections.
- Test with one or two databases first before moving all 100.
Let me know if you have other questions or any doubts.
Thanks
-
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(12.8, 24%, 11%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EPP%3C/text%3E%3C/svg%3E)
Pilladi Padma Sai Manisha 7,310 Reputation points Microsoft External Staff Moderator2026-04-16T08:51:44.9+00:00 Hi Georg Sieber,
Thankyou for reaching microsoft Q&A!
Could you please share requested details in private message -
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(208, 49%, 30%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ESJ%3C/text%3E%3C/svg%3E)
SAI JAGADEESH KUDIPUDI 2,535 Reputation points Microsoft External Staff Moderator2026-04-19T20:49:09.12+00:00 Hi Georg Sieber,
Thanks for the detailed explanation — this really helps clarify what you're trying to achieve.
You’ve already identified the key blocker correctly, and I want to validate that:
Your approach (BACPAC → import → Change Tracking sync) unfortunately won’t work because Change Tracking version metadata is not preserved across BACPAC operations
There is no supported method to export Azure SQL Database as a
.bakfile for restore into Managed InstanceThere is no internal or support-only tool that enables backup/log shipping–style migration from Azure SQL Database
Transactional replication is not a viable option here, as Azure SQL Database cannot act as a Publisher for this scenario
The only Microsoft-supported solution that aligns with your requirements is:
Azure Database Migration Service (Online Migration Mode)This approach is specifically designed for minimal downtime migrations and works as follows:
- Initial Load – Data is copied from source to target while the application remains online
- Continuous Sync – Ongoing changes are replicated to the target system
- Cutover – A short downtime window is used to finalize synchronization and switch connections
In summary, your original approach using BACPAC with Change Tracking isn’t feasible due to platform limitations, as key metadata cannot be preserved during migration. There’s also no internal Microsoft tool or supported method to enable backup or log shipping–style migration from Azure SQL Database. The recommended and fully supported solution is to use Azure Database Migration Service in online mode, which is designed to provide continuous data synchronization and a minimal downtime cutover.
Microsoft Reference Links:
Azure Database Migration Service documentation
https://learn.microsoft.com/azure/dms/
Migration to Azure SQL Managed Instance - SQL Server migration in Azure Arc
https://learn.microsoft.com/en-us/sql/sql-server/azure-arc/migrate-to-azure-sql-managed-instance?view=sql-server-ver17&tabs=mi-link
Azure SQL Database export limitations
https://learn.microsoft.com/azure/azure-sql/database/database-export
Replication limitations in Azure SQL Database
https://learn.microsoft.com/azure/azure-sql/database/replication-to-sql-database
Hope this helps. If you have any follow-up questions, please let me know. I would be happy to help. -
Georg Sieber 45 Reputation points
2026-04-20T07:07:53.23+00:00 Azure DMS cannot be used if Azure SQL database is the source.
-
SAI JAGADEESH KUDIPUDI 2,535 Reputation points Microsoft External Staff Moderator
2026-04-20T15:00:02.7766667+00:00 Hi Georg Sieber,
Azure Database Migration Service does not support Azure SQL Database as a migration source. For this scenario, supported alternatives include BACPAC export/import for offline migrations, Azure Data Factory with Change Tracking or CDC for low‑downtime migrations, and third‑party replication tools for near‑zero downtime requirements.
Since Azure SQL Database is not supported as a source for Azure Database Migration Service (DMS), the recommended and supported approach for this scenario is to use Azure Data Factory (ADF) to perform a phased migration with minimal downtime.
At a high level, the migration approach would be as follows:
- Initial full load We start with a one‑time full copy of the data from Azure SQL Database to the target Azure SQL Managed Instance using Azure Data Factory. This establishes a baseline copy of the data on the Managed Instance.
- Incremental synchronization After the initial load, Change Tracking (or CDC if required) is enabled on the source Azure SQL Database. Azure Data Factory pipelines are then configured to copy only incremental changes (inserts, updates, and deletes) from the source to the Managed Instance on a scheduled basis. This allows both environments to stay closely synchronized while the application remains online.
- Validation and monitoring While incremental synchronization is running, we monitor pipeline executions and validate data consistency between the source and target to ensure the Managed Instance remains fully up to date.
- Cutover Once the data difference is minimal, a short maintenance window is scheduled. During this window, application writes are paused, a final incremental sync is executed, and the application is switched to connect to the Azure SQL Managed Instance.
This approach is fully Azure‑native, scalable, and commonly used to achieve near‑zero downtime migrations when Azure SQL Database is the source.
https://techcommunity.microsoft.com/blog/azuredbsupport/migrating-an-azure-sql-db-to-a-sql-mi-by-ut…
Hope this helps. If you have any follow-up questions, please let me know. I would be happy to help.
Sign in to comment
2 answers
Sort by: Most helpful
-
Deleted
This answer has been deleted due to a violation of our Code of Conduct. The answer was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Comments have been turned off. Learn more
-
Deleted
This answer has been deleted due to a violation of our Code of Conduct. The answer was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Comments have been turned off. Learn more