Migrating SQL Server - AWS Prescriptive Guidance
AssessMobilizeMigrate

Migrating SQL Server

In your journey to the cloud, you have multiple options for migrating your SQL Server environments to AWS. A successful migration is based on generating a detailed inventory of your SQL Server workloads and their dependencies, identifying your authentication scheme, capturing your high availability and disaster recovery (HADR) requirements, assessing your performance targets, and evaluating your licensing options. This inventory helps you determine the target database platform and define your migration options.

You have many options to consider when migrating your SQL Server workloads to AWS, each resulting in optimized price/performance, a more intuitive user experience, and a lower TCO. You can choose to deploy SQL Server on the following: Amazon EC2, Amazon RDS for SQL Server, or Amazon RDS Custom for SQL Server.

Assess

To implement a successful migration, it's important to evaluate your existing infrastructure and understand the key features required for your environment. We recommend that you review the following key areas before choosing a migration plan:

  • Review existing infrastructure – Review your existing SQL Server infrastructure by using data collected in the discovery phase of your migration (see Windows environment discovery). We recommend that you use the Microsoft prescribed sizing for SQL Server infrastructure on AWS. Understanding current utilization of your on-premises SQL Server instance—including memory, CPU, IOPS, and throughput—is very important to right size your SQL Server instance on AWS.

  • Review existing licensing – You can take advantage of the complementary AWS Optimization and Licensing Assessment (AWS OLA) to build a migration and licensing strategy on AWS. AWS OLA provides you with a report that models your deployment options using existing licensing entitlements. These results can help you explore available cost savings across flexible AWS licensing options.

  • Review existing SQL Server architecture – If you're using a SQL Server failover cluster with shared storage or SQL Server Always On Availability group architecture, then understanding your current high availability architecture requirements will help you define the SQL Server deployment options on AWS.

  • Develop backup strategies – You can use native backup in SQL Server to back up your databases to cloud. There are various options to back up databases to Amazon EBS, Amazon FSx for Windows File Server, Amazon FSx for NetApp ONTAP, and Amazon S3 using Storage Gateway. Additionally, you can back up your SQL Server instance by using a snapshot approach. For more information about SQL Server backups, see Backup and restore options for SQL Server on Amazon EC2 on AWS Prescriptive Guidance.

  • Understand disaster recovery (DR) needs – If you're moving your existing SQL Server workloads to AWS, then you can use a secondary AWS Region and connect the two Regions by using Transit Gateway (which allows replication to occur). You can use SQL Server distributed availability group architecture within SQL Enterprise edition to set up DR, or you can use log shipping based on your RTO and RPO requirements. Additionally, you can use AWS Elastic Disaster Recovery as an active/passive implementation where you leave your DR as a failover environment. For more information, see the Architect a disaster recovery for SQL Server on AWS: Part 1 post on the AWS Database Blog.

Mobilize

There are three main migration options that we recommend you consider for your SQL Server workloads:

  • Rehosting (lift and shift) – This involves migrating your on-premises SQL Server databases to SQL Server on an Amazon EC2 instance in the AWS Cloud. This approach is useful if a faster migration to AWS is your priority.

  • Replatforming (lift and reshape) – This involves migrating your on-premises SQL Server databases to Amazon RDS for SQL Server in the AWS Cloud. Replatforming is best suited for when you want to continue using SQL Server but want to offload the undifferentiated heavy lifting tasks, such as installation, configuration, patching, upgrades, and setting up high availability. For a feature comparison of SQL Server on Amazon EC2, Amazon RDS, and Amazon RDS Custom, see Choosing between Amazon EC2 and Amazon RDS on AWS Prescriptive Guidance.

  • Refactoring (re-architect) – This typically involves application changes and modernizing by using open-source databases or databases built for the cloud. In this scenario, you modernize your on-premises SQL Server databases to use either Amazon RDS for MySQL, Amazon RDS for PostgreSQL, or Amazon Aurora. By moving to an open-source database you can reduce licensing costs and prevent unnecessary vendor lock-in periods and licensing audits.

Migrate

As you migrate your SQL Server workloads to AWS, take into consideration the following items on configuration and tooling.

Rehosting

Rehosting is homogeneous. Choose this approach when you want to migrate your SQL Server database as-is without changing the database software or configuration. For example, in large-scale legacy migrations, you might want to move quickly to meet your business objectives and choose to rehost most of your applications.

Migrating SQL Server using Amazon EC2

If you migrate to Amazon EC2, you can bring your existing SQL Server licenses. This is known as the Bring Your Own License (BYOL) model. Alternatively, you can purchase License Included (LI) instances from AWS. For more information, see the Cost optimization with SQL BYOL using license included Windows instance on Amazon EC2 Dedicated Hosts post on the AWS Cloud Operations & Migrations Blog. The BYOL option enables you to reduce costs by using your existing SQL Server licenses. AWS License Manager assists in controlling the allocation of your available licenses when instantiating VMs with SQL Server in Amazon EC2. License Manager helps ensure compliance with licensing rules that you specify.

You can rehost SQL Server to shared-tenancy (default) EC2 instances by using BYOL only if you have Microsoft Software Assurance (SA). If you don't have SA on your SQL licenses, you can rehost to Amazon EC2 Dedicated Hosts, as long as the licenses were purchased prior to October 1, 2019, or added as a true-up under an active Enterprise Enrollment that was effective prior to October 1, 2019.

There are ways to migrate a SQL Server database to an Amazon EC2 instance by using SQL Server features like backup and restore, log shipping, and Always On availability groups. These options are appropriate if you're migrating a single database or set of databases to a new SQL Server instance running on Amazon EC2. These options are database-native and dependent on specific SQL Server versions and editions. In addition to the database migration, you could also be required to perform steps to migrate objects such as logins, jobs, database mail, and linked servers.

The following approaches are available for rehosting your SQL Server databases on AWS:

You could also use AWS Launch Wizard for SQL Server to guide you through the sizing, configuration, and deployment of Microsoft SQL Server on Amazon EC2. It supports both SQL Server single instance and HA deployments on Amazon EC2.

Migrating SQL Server using Application Migration Service

AWS Application Migration Service is a good option if you want to lift and shift one or more large-scale machines from an on-premises environment to AWS without changing the SQL Server version, operating system, or code in the databases with near-zero or minimal downtime. You can use Application Migration Service to quickly lift and shift physical, virtual, or cloud servers without compatibility issues, performance impact, or long cutover windows. For guidance on migrating a SQL Server database from an on-premises environment to an Amazon EC2 instance by using Application Migration Service, see Migrating Microsoft SQL Server databases to the AWS Cloud on AWS Prescriptive Guidance. You can also refer to best practices when you use Application Migration Service to migrate Microsoft SQL Server database workloads to AWS.

SQL Server on Linux

The SQL Server database engine basically runs in a similar way on both Windows Server and Linux. However, there are some changes to certain tasks when using Linux. Launch Wizard can help you adjust to these changes and configure highly available solutions. If you have in-house Linux administration expertise, rehosting to Amazon EC2 Linux is a good choice to save on Windows Server licensing costs. Consider using the Windows to Linux replatforming assistant for Microsoft SQL Server Databases tool to automate this process. For more information, see Migrate an on-premises Microsoft SQL Server database to Microsoft SQL Server on Amazon EC2 running Linux on AWS Prescriptive Guidance.

Replatforming

Replatforming is a homogeneous approach that's best suited for reducing the time you spend managing database instances by using a fully-managed database offering. A fully-managed database in Amazon RDS for SQL Server limits you from accessing the underlying operating system, system volume, or installation of custom drivers. For more information, see Amazon RDS for Microsoft SQL Server in the Amazon RDS documentation. If fully-managed database capabilities are necessary for your use case or if you want to use existing SQL Server licenses, consider replatforming to Amazon RDS Custom for SQL Server.

The Bring Your Own Media (BYOM) option is available for Amazon RDS Custom for SQL Server. BYOM enables you to use your own installation media and licenses, but the licenses must comply with Microsoft's License Mobility terms. You can either replatform SQL Server to Amazon RDS for SQL Server or to Amazon RDS Custom for SQL Server. The choice depends on whether you require access to the underlying operating system, require database customization, or want to use your existing SQL Server licenses by using BYOM.

The following methods are available for migrating SQL Server to Amazon RDS for SQL Server:

To replatform your SQL Server databases to run on Amazon RDS for SQL Server, consider using the approaches provided in Amazon RDS for SQL Server resources. For information about how to migrate end of support workloads, see the Migrate end of support Microsoft SQL Server databases to Amazon RDS for SQL Server confidently post on the AWS Database Blog. For information about on-premises databases, see Migrating an on-premises database to Amazon RDS Custom for SQL Server in the Amazon RDS documentation.

Refactoring

Refactoring is heterogeneous. Choose this approach when you're ready to restructure, rewrite, and rearchitect your database and application to take advantage of open-source and built-for-the-cloud database offerings. If you're open to refactoring your database and respective applications, you can modernize your SQL Server workloads to either Amazon RDS for MySQL, Amazon RDS for PostgreSQL, Amazon Aurora MySQL-Compatible Edition, or Amazon Aurora PostgreSQL-Compatible Edition. You can refactor depending on many modernization timelines and performance requirements.

Amazon RDS for MySQL and Amazon RDS for PostgreSQL are fully-managed database offerings for their respective open-source databases. Amazon Aurora is a relational database management system (RDBMS) built for the cloud with full MySQL and PostgreSQL compatibility. Aurora features a fault-tolerant storage system and gives you the performance and availability of commercial-grade databases at one-tenth the cost.

You can also use Amazon Aurora Serverless to run your database on AWS without managing database capacity. Amazon Aurora Serverless v2 scales instantly to hundreds of thousands of transactions in a fraction of a second. You pay only for the capacity your application consumes, and you can save up to 90 percent on database costs compared to the cost of provisioning capacity for peak load.

To refactor your SQL Server databases to one of these offerings, consider using AWS Schema Conversion Tool (AWS SCT) with AWS DMS. For more information, see AWS SCT in the Migrating Microsoft SQL Server databases to the AWS Cloud guide.

If your goal is to accelerate your application and database migrations to AWS, consider using Babelfish for Aurora PostgreSQL. Babelfish enables applications that were originally written for SQL Server to work with Aurora with minimal code changes. As a result, the effort required to modify and move to Babelfish for Aurora PostgreSQL applications developed for SQL Server 2019 or older is reduced, leading to faster, lower-risk, and more cost-effective refactoring.

Consider the following resources for migrating with Babelfish:

Additional resources