Applications 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.
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 SQLManaged Instance. We will explore these options in this blog series, diving into the details of each of the respective processes:
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.