Migrate Amazon RDS for SQL Server to Azure SQL Managed Instance – Part 1 (Overview)
Published Apr 28 2022 09:04 AM 9,124 Views

sqlmi.pngApplications are closely dependent on the databases and application evolution is frequently connected with an upgrade of the application database. Database migration is process of moving customer’s database from a source instance to a destination instance. This process includes not only the move from one instance to another, but also a modernization process - from one version of SQL Server to a newer one (or from a legacy & unsupported to a supported one). 


This is the first post in the series on the Amazon RDS for SQL Server to Azure SQL Managed Instance migration that will serve as an introduction and an overview of the series.
In the later posts of these series, we compare different migration methods to help you to understand the features, benefits, nature of complexity, trade-off's involved in each of them.


There are multiple ways to migrate databases hosted in Amazon Relational Database Service (Amazon RDS) for SQL Server to Azure SQL Managed Instance. For use cases such as migrating from Amazon Elastic Compute Cloud (Amazon EC2) to SQL Server on Azure SQL Managed Instance, you can use a number of ways and tools, including Database Migration Assistant (DMA) Link feature for SQL Managed Instance or Log Replay Service. When it comes to migrating RDS for SQL databases, we cannot use DMA or Log Replay Service methods because RDS SQL Server takes backups without checksum enabled and both of these methods require backups to have the checksum enabled in order to verify the consistency at the restore time.  


Azure SQL Managed Instance is the intelligent, scalable cloud database service that combines the broadest SQL Server database engine compatibility with all the benefits of a fully managed and evergreen platform as a service. SQL Managed Instance has near 100% compatibility with the latest in-market available SQL Server database engine (Enterprise Edition) and always up to date with the latest SQL features and functionality, so you never have to worry about updates, upgrades, or end of support again. It’s fully-managed, meaning the service performs many time-consuming and complex tasks on your behalf – boosting DBA productivity and helping you operate more efficiently.  

It provides an entire SQL Server instance within a managed service, so you can continue using familiar tools and SQL Server features – and it not only maintains the highest compatibility levels (160) corresponding to SQL Server 2022 but also the lowest (100) giving widest support for the application written and compatible for the SQL Server since 2008. This enables you to move your on-premises workloads without worrying about application compatibility or performance changes. 


Migration processes can be split into 2 main categories – Online and Offline. 
Execution of the migration processes typically imply a certain amount of downtime for the database access and those processes which imply some downtimes are called Offline migration processes. For the business-critical processes that can have no downtime, the situation can be mitigated by using Online processes that will imply almost to none of database downtimes. 


Different migration processes allow the migration to be executed for the whole database completely or partially, as in just a subset of the database (on the table and schema-level). A complete database migration means we are working on all-or-nothing level, meaning no data or schema can be left behind and once we finish the migration, every bit of the source database information is landing as a complete copy on the destination database. In the case of the partial migration process, customer can choose the information from the source database that will be delivered to the destination database. Customer can choose every single object from the source database to be copied over to the destination database and in this case a partial migration process will mimic the complete database migration process. Partial migration process might allow a more granular control over the migration process impact and execution, but it will certainly imply more work and higher risk for the customer. 
The impact on the database downtime will largely depend on the selected migration option and will range from Online to multiple hours of downtime for the Offline process. 


The following table summarizes currently available methods to migrate to Azure SQL Managed Instance. We will explore these options in this blog series, diving into the details of each of the respective processes: 

Migration option 



Backup and Restore 

Supports all database sizes.


Complete migration process only. 


Offline migration. 


ADF (Azure Data Factory) 

Supports copying at table level. 

Partial or Complete migration processes. 

Offline migration.

Requires downtime
that can be lowered by parallelizing the process. 


Database needs to be pre-created at destination 


Additional configuration to setup Self-hosted IR 

Smart bulk copy 

Supports copying data at database level. 

Partial or Complete migration processes. 

Offline migration.

Requires downtime
that can be lowered by parallelizing the process. 


Database & schema need to be pre-created at the destination 



In the next posts we shall go over each of the above listed tools and consider in detail their usage, their advantages, and their limitations. 

The choice of migration method depends on ease of use, business and technical requirements, application, and migration complexity, and of course, budget. This choice and the respective strategy can be very different even for the same customer, but for the different applications.  


In the next post, we will dive into using SQL Server native backup & restore method for migration from Amazon RDS for SQL Server to Azure SQL Managed Instance 

Version history
Last update:
‎Sep 27 2022 04:55 AM
Updated by: