# SQL Server database migration methods
There are various methods to migrate your SQL Server databases to AWS. You can choose from AWS services and SQL Server native features based on your assessment and requirements. This section describes some of the most common methods, which are summarized in the following two tables. Detailed discussions of some of these methods are included in the sections on Amazon EC2 and Amazon RDS later in this guide.
**AWS services**
****
| Migration method | Target | Features and limitations | More information |
| --- | --- | --- | --- |
| **AWS DMS** | Amazon EC2 Amazon RDS Amazon RDS Custom Amazon Aurora | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/prescriptive-guidance/latest/migration-sql-server/methods.html) | [AWS DMS](heterogeneous-migration-tools.md#aws-dms) section |
| **AWS Migration Hub Orchestrator** | Amazon EC2 Amazon RDS | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/prescriptive-guidance/latest/migration-sql-server/methods.html) | [AWS Migration Hub Orchestrator](mho.md) section |
| **AWS Application Migration Service** | Amazon EC2 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/prescriptive-guidance/latest/migration-sql-server/methods.html) | Not covered in this guide (see [Application Migration Service documentation](https://docs.aws.amazon.com/mgn/index.html)) |
| **AWS Snowball Edge** | Amazon EC2 Amazon RDS Amazon RDS Custom | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/prescriptive-guidance/latest/migration-sql-server/methods.html) | [Snowball Edge](snowball-edge.md) section |
**SQL Server native methods**
****
| Migration method | Target | Features and limitations | More information |
| --- | --- | --- | --- |
| **Native backup and restore** | Amazon EC2 Amazon RDS Amazon RDS Custom | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/prescriptive-guidance/latest/migration-sql-server/methods.html) | [Native SQL Server backup/restore](native-backup-restore.md) section (you can use [AWS Migration Hub Orchestrator](mho.md) to automate native backup and restore) |
| **Log shipping** | Amazon EC2 Amazon RDS Amazon RDS Custom | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/prescriptive-guidance/latest/migration-sql-server/methods.html) | [Log shipping](log-shipping.md) section |
| **Custom log shipping** | Amazon RDS Amazon RDS Custom | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/prescriptive-guidance/latest/migration-sql-server/methods.html) | [Automate on-premises or Amazon EC2 SQL Server to Amazon RDS for SQL Server migration using custom log shipping](https://aws.amazon.com/blogs/database/automate-on-premises-or-amazon-ec2-sql-server-to-amazon-rds-for-sql-server-migration-using-custom-log-shipping/) (AWS blog post) |
| **Database mirroring** | Amazon EC2 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/prescriptive-guidance/latest/migration-sql-server/methods.html) | [Database mirroring](db-mirroring.md) section |
| **Always On availability groups** | Amazon EC2 Amazon RDS Custom | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/prescriptive-guidance/latest/migration-sql-server/methods.html) | [Always On availability groups](always-on.md) section |
| **Basic Always On availability groups** | Amazon EC2 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/prescriptive-guidance/latest/migration-sql-server/methods.html) | Not covered in this guide (see [Basic Always On availability groups for a single database](https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/basic-availability-groups-always-on-availability-groups) in the Microsoft documentation) |
| **Distributed availability groups** | Amazon EC2 Amazon RDS Custom (migration only) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/prescriptive-guidance/latest/migration-sql-server/methods.html) | [Distributed availability groups](distributed-groups.md) section |
| **Transactional replication** | Amazon EC2 Amazon RDS Amazon RDS Custom | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/prescriptive-guidance/latest/migration-sql-server/methods.html) | [Transactional replication](trans-rep.md) section |
| **Bulk copy program (bcp)** | Amazon EC2 Amazon RDS Custom | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/prescriptive-guidance/latest/migration-sql-server/methods.html) | Not covered in this guide (see [Importing and exporting SQL Server data using other methods](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/SQLServer.Procedural.Importing.Snapshots.html), *Bulk copy* section in the Amazon RDS documentation) |
| **Detach and attach** | Amazon EC2 Amazon RDS Custom | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/prescriptive-guidance/latest/migration-sql-server/methods.html) | Not covered in this guide (see [Database Detach and Attach](https://learn.microsoft.com/en-us/sql/relational-databases/databases/database-detach-and-attach-sql-server) in the Microsoft documentation) |
| **Import/export** | Amazon EC2 Amazon RDS Amazon RDS Custom | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/prescriptive-guidance/latest/migration-sql-server/methods.html) | Not covered in this guide (see [Importing and exporting SQL Server data using other methods](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/SQLServer.Procedural.Importing.Snapshots.html#SQLServer.Procedural.Exporting.SSIEW) in the Amazon RDS documentation) |
# Native SQL Server backup/restore
Amazon RDS supports native backup and restore operations for Microsoft SQL Server databases using full and differential backup (.bak) files. It also supports differential restore and log restore options on an Amazon RDS for SQL Server DB instance or Amazon EC2 SQL Server instance, to minimize downtime for your application.
**Note**
You can perform full, differential, and log restore operations on Amazon RDS for SQL Server. However, you can perform only full and differential backup (not log backup) at this time.
Using native .bak files is the simplest way to back up and restore SQL Server databases. You can use this method to migrate databases to or from Amazon RDS. You can back up and restore single databases instead of entire DB instances. You can also move databases between Amazon RDS for SQL Server DB instances.
When you use Amazon RDS, you can store and transfer backup files in Amazon Simple Storage Service (Amazon S3), for an added layer of protection for disaster recovery. For example:
+ You can create a full backup of your database from your local server, copy it to an S3 bucket, and then restore it onto an existing Amazon RDS SQL Server DB instance.
+ You can take backups from an Amazon RDS for SQL Server DB instance, store them in Amazon S3, and then restore them wherever you want.
+ You can implement [Amazon S3 Lifecycle](https://docs.aws.amazon.com/AmazonS3/latest/dev/object-lifecycle-mgmt.html) configuration rules to archive or delete long-term backups.
Amazon RDS for SQL Server supports restoring SQL Server native backups onto SQL Server DB instances that have read replicas configured. This means that you don’t have to remove the read replica before restoring the native backup file onto your Amazon RDS for SQL Server DB instance.
**Note**
You can use Migration Hub Orchestrator to automate and orchestrate your SQL Server database migrations to Amazon EC2 or Amazon RDS by using native backup and restore. For more information, see the [AWS Migration Hub Orchestrator section](mho.md).
The following diagram shows the native SQL Server backup/restore process. You can use Migration Hub Orchestrator to automate this process. You can use this process to back up and restore SQL Server databases to Amazon EC2 as well.
![\[SQL Server migration process with native SQL Server backup/restore\]](http://docs.aws.amazon.com/prescriptive-guidance/latest/migration-sql-server/images/sql-native-backup-restore.png)
To automate backup and restore, see the [Migration Hub Orchestrator documentation](https://docs.aws.amazon.com/migrationhub-orchestrator/latest/userguide/what-is-migrationhub-orchestrator.html).
To set up native backup/restore using Amazon S3, see the [Amazon RDS documentation](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/SQLServer.Procedural.Importing.html#SQLServer.Procedural.Importing.Native.Enabling).
For limitations when using SQL Server native backup and restore, see [Limitations and recommendations](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/SQLServer.Procedural.Importing.html#SQLServer.Procedural.Importing.Native.Limitations) in the Amazon RDS documentation.
# Log shipping
You can use log shipping to send transaction log backups from your primary, on-premises SQL Server database to one or more secondary (warm standby) SQL Server databases that are deployed on EC2 instances or Amazon RDS for SQL Server DB instances in the AWS Cloud. To set up log shipping on Amazon RDS for SQL Server, you have to use your own custom scripts.
In this scenario, you configure a warm standby SQL Server database on an EC2 instance or Amazon RDS for SQL Server DB instance, and send transaction log backups asynchronously between your on-premises database and the warm standby server in the AWS Cloud. The transaction log backups are then applied to the warm standby database. When all the logs have been applied, you can perform a manual failover and cut over to the cloud.
This option supports all versions and editions of SQL Server. After you have migrated the database to the AWS Cloud, you can add a secondary replica by using an Always On availability group for high availability and resiliency purposes.
![\[SQL Server migration process with log shipping\]](http://docs.aws.amazon.com/prescriptive-guidance/latest/migration-sql-server/images/sql-migration-log-shipping.png)
For more information about using this method to achieve high availability, data protection, and disaster recovery for your SQL Server databases on Amazon EC2, see [Log shipping](ec2-log-shipping.md) in the *Amazon EC2 for SQL Server* section.
# Database mirroring
You can use database mirroring to set up a hybrid cloud environment for your SQL Server databases. This option requires SQL Server Enterprise edition. In this scenario, your principal SQL Server database runs on premises, and you create a warm standby in the cloud. You replicate your data asynchronously, and perform a manual failover when you’re ready for cutover. After you have migrated the database to the AWS Cloud, you can add a secondary replica by using an Always On availability group for high availability and resiliency purposes.
For more information about using this method to achieve high availability, data protection, and disaster recovery for your SQL Server databases on Amazon EC2, see [Database mirroring](ec2-db-mirroring.md) in the *Amazon EC2 for SQL Server* section.
# Always On availability groups
SQL Server Always On availability groups is an advanced, enterprise-level feature to provide high availability and disaster recovery solutions. This feature is available if you are using SQL Server 2014 and later versions. You can also use an Always On availability group to migrate your on-premises SQL Server databases to Amazon EC2 on AWS. This approach enables you to migrate your databases with minimal to no downtime.
If you have an existing on-premises deployment of SQL Server Always On availability groups, your primary replica and secondary replica will be synchronously replicating data within the availability group. So, to migrate your database to AWS Cloud, you can extend your Windows Server Failover Clustering (WSFC) cluster to the cloud. This can be temporary, just for migration purposes. You then create a secondary replica in the AWS Cloud and use asynchronous replication, as shown in the following diagram. After the secondary replica is synchronized with the primary on-premises database, you can perform a manual failover whenever you are ready for cutover.
![\[SQL Server migration process with Always On availability groups\]](http://docs.aws.amazon.com/prescriptive-guidance/latest/migration-sql-server/images/sql-migration-always-on.png)
For more information about using this method to achieve high availability, data protection, and disaster recovery for your SQL Server databases on Amazon EC2, see [Always On availability groups](ec2-always-on.md) in the *Amazon EC2 for SQL Server* section.
# Distributed availability groups
A distributed availability group spans two separate availability groups. You can think of it as an availability group of availability groups. The underlying availability groups are configured on two different WSFC clusters. The availability groups that participate in a distributed availability group do not need to share the same location. They can be physical or virtual, on premises or in the public cloud. The availability groups in a distributed availability group don’t have to run the same version of SQL Server. The target DB instance can run a later version of SQL Server than the source DB instance.
A distributed availability group architecture gives you a flexible way to rehost a mission-critical SQL Server instance or database on AWS. It provides a hybrid solution for lifting and shifting (or lifting and transforming) your critical SQL Server databases on AWS.
Using a distributed availability group architecture is more efficient than extending existing on-premises WFSC clusters to AWS. Data is transferred only from the on-premises primary to one of the AWS replicas (the *forwarder*). The forwarder is responsible for sending data to other secondary read replicas in AWS.
In the following diagram, the first WSFC cluster (WSFC 1) is hosted on premises and has an on-premises availability group (AG 1). The second WSFC cluster (WSFC 2) is hosted on AWS and has an AWS availability group (AG 2). [Direct Connect](https://aws.amazon.com/directconnect/) is used as a dedicated network connection between the on-premises environment and AWS. The on-premises availability group (AG 1) has two replicas (*nodes*). The data transfer between the nodes is synchronous, with automatic failover. Similarly, the AWS availability group (AG 2) also has two replicas, and the data transfer between them is synchronous with automatic failover. The distributed availability group keeps the databases in sync in an asynchronous manner. Data is transferred from the SQL Server primary replica in AG 1 (which is on premises) to the primary replica (the forwarder) in AG 2 (which is on AWS). The forwarder is responsible for sending data to other read replicas on AWS and keeping them updated. After the on-premises and AWS databases are synchronized, you can perform a manual failover of the distributed availability group to AWS. The AWS database becomes the primary database for read/write access from applications.
![\[SQL Server migration process with distributed availability groups\]](http://docs.aws.amazon.com/prescriptive-guidance/latest/migration-sql-server/images/sql-migration-distributed-availability-groups.png)
**Note**
At any given point of time, there is only one database that is available for write operations. You can use the remaining secondary replicas for read operations. To scale out your read workloads, you can add more read replicas in multiple Availability Zones on AWS.
For more information about distributed availability groups, see:
+ [Microsoft SQL Server documentation](https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/distributed-availability-groups)
+ [How to architect a hybrid Microsoft SQL Server solution using distributed availability groups](https://aws.amazon.com/blogs/database/how-to-architect-a-hybrid-microsoft-sql-server-solution-using-distributed-availability-groups/) on the AWS Database blog
+ [Migrate SQL Server to AWS using distributed availability groups](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/migrate-sql-server-to-aws-using-distributed-availability-groups.html) on the AWS Prescriptive Guidance website
# Transactional replication
Transactional replication is a SQL Server technology that is used to replicate changes between two databases. These changes can include database objects like tables (primary key is required), stored procedures, views, and so on, as well as data. The replication process involves a *publisher* (the primary database that publishes data), a *subscriber* (a secondary database that receives replicated data), and a *distributor* (a server that stores metadata and transactions for transactional replication). You can use transactional replication for SQL Server on Amazon EC2 and Amazon RDS for SQL Server DB instances.
Transactional replication creates a snapshot of the objects and data in your on-premises (publication) database and sends it to the subscriber database. After the snapshot is applied to the subscriber, all subsequent data changes and schema modifications made at the publisher are sent over to the subscriber as they occur. The data changes are then continuously applied to the subscriber in the same order as they occurred at the publisher.
After synchronization is complete, you perform validation on the target SQL Server DB instance. When the two databases are in sync, you stop stop the activity on the on-premises database, ensure that replication has completed, and then perform the cutover to the target SQL Server DB instance. You can then stop the push subscription, delete it, and start using Amazon RDS for SQL Server.
Subscriber databases can also be used as read-only databases. The distributor, which records synchronization jobs, is recommended to be on a separate server. If your target database is on Amazon RDS for SQL Server, you can set up a push subscription to propagate changes to the subscriber.
We recommend that you use transactional replication when you want to:
+ Perform a one-time migration of your data to Amazon RDS or Amazon EC2.
+ Migrate schema-level or table-level objects to AWS.
+ Migrate a portion of a database to AWS.
+ Migrate with minimal downtime using existing SQL Server replication strategies by adding additional subscribers.
If you’re planning to use transactional replication for one-time migration of your data to Amazon RDS for SQL Server, we recommend that you set up a Single-AZ configuration for the replication. After the replication process is complete, you can convert your environment into a Multi-AZ architecture for high availability.
The following diagram shows the transactional replication process for databases on Amazon RDS and Amazon EC2.
![\[SQL Server migration process with transactional replication\]](http://docs.aws.amazon.com/prescriptive-guidance/latest/migration-sql-server/images/sql-migration-transactional-replication.png)
For more information about transactional replication, see the [Microsoft SQL Server documentation](https://docs.microsoft.com/en-us/sql/relational-databases/replication/transactional/transactional-replication) and the post [How to migrate to Amazon RDS for SQL Server using transactional replication](https://aws.amazon.com/blogs/database/how-to-migrate-to-amazon-rds-for-sql-server-using-transactional-replication/) on the AWS Database blog.
# AWS Migration Hub Orchestrator
**Note**
AWS Migration Hub is no longer open to new customers as of November 7, 2025. For capabilities similar to AWS Migration Hub, explore [AWS Transform](https://aws.amazon.com/transform/).
AWS Migration Hub Orchestrator helps you orchestrate and automate the migration of SQL Server databases to Amazon EC2 or Amazon RDS. This feature of AWS Migration Hub helps you get started quickly by using predefined workflow templates that are built based on best practices. Migration Hub Orchestrator automates error-prone manual tasks involved in the migration process, such as checking environment readiness and connections. You can also use Migration Hub Orchestrator to orchestrate and accelerate migrations for .NET applications, SAP workloads, and virtual machine images, in addition to your SQL Server databases. You can access this tool through the [Migration Hub Orchestrator console](https://console.aws.amazon.com/migrationhub/orchestrator/).
For SQL Server migration, Migration Hub Orchestrator supports three use cases:
+ Rehost SQL Server on Amazon EC2. You can choose specific SQL servers and rehost them on Amazon EC2 by using automated native backup and restore in Migration Hub Orchestrator. To learn more, see [Rehost SQL server on Amazon EC2](https://docs.aws.amazon.com/migrationhub-orchestrator/latest/userguide/rehost-sql-ec2.html ) in the Migration Hub Orchestrator documentation.
+ Replatform SQL Server on Amazon RDS. You can choose specific SQL Server databases and replatform them on Amazon RDS by using automated native backup and restore in Migration Hub Orchestrator. To learn more, see [Replatform SQL server on Amazon RDS](https://docs.aws.amazon.com/migrationhub-orchestrator/latest/userguide/replatform-sql-rds.html) in the Migration Hub Orchestrator documentation.
+ Rehost Windows and SQL Server applications on Amazon EC2. You can lift and shift your Windows servers running .NET and SQL Server to Amazon EC2 by using the *Rehost applications on Amazon EC2 template*. To learn more, see [Rehost applications on Amazon EC2](https://docs.aws.amazon.com/migrationhub-orchestrator/latest/userguide/rehost-on-ec2.html) in the Migration Hub Orchestrator documentation.
Migration Hub Orchestrator helps avoid schedule and budget overruns in your SQL Server migrations. Other key benefits include:
+ Migrate applications by using a prescriptive methodology. You can get started quickly with the predefined workflow templates, which are based on proven migration best practices. You can also customize your migration workflow by adding, reordering, and removing steps based on your needs. For example, you can add a step for cutover approval.
+ Automate manual steps. Migration Hub Orchestrator automates manual tasks such as installing agents, importing on-premises images, provisioning your target environment on AWS, and verifying source and target environments. Automation saves you time and costs while reducing errors.
+ Orchestrate migration workflow. Migration Hub Orchestrator orchestrates the tools used in migration steps by reusing the inventory metadata, configuration specification, and environment context to minimize the number of inputs that these tools require.
For additional information, see the following resources:
+ [Migration Hub Orchestrator console](https://console.aws.amazon.com/migrationhub/orchestrator/)
+ [Rehost applications on Amazon EC2](https://docs.aws.amazon.com/migrationhub-orchestrator/latest/userguide/rehost-on-ec2.html) (*Migration Hub Orchestrator User Guide*)
+ [Replatform SQL server on Amazon RDS](https://docs.aws.amazon.com/migrationhub-orchestrator/latest/userguide/replatform-sql-rds.html) (*Migration Hub Orchestrator User Guide*)
+ [Migration workflows](https://docs.aws.amazon.com/migrationhub-orchestrator/latest/userguide/migration-workflows.html) (*Migration Hub Orchestrator User Guide*)
+ [Using Migration Hub Orchestrator to simplify and accelerate Microsoft SQL Server migrations](https://aws.amazon.com/blogs/modernizing-with-aws/aws-migration-hub-orchestrator-sql-server-migrations-to-aws/) (AWS blog post)
+ [Simplify migrating your Windows Server images with AWS Migration Hub Orchestrator](https://aws.amazon.com/blogs/modernizing-with-aws/simplify-migrating-your-windows-server-images-with-aws-migration-hub-orchestrator/) (AWS blog post)
# AWS Snowball Edge
**Note**
AWS Snowball Edge is no longer available to new customers. New customers should explore [AWS DataSync](https://aws.amazon.com/datasync/) for online transfers, [AWS Data Transfer Terminal](https://aws.amazon.com/data-transfer-terminal/) for secure physical transfers, or AWS Partner solutions. For edge computing, explore [AWS Outposts](https://aws.amazon.com/outposts/).
You can use AWS Snowball Edge to migrate very large databases (up to 210 TB in size). Snowball has a 10 Gb Ethernet port that you plug into your on-premises server and place all database backups or data on the Snowball Edge device. After the data is copied to Snowball Edge, you send the appliance to AWS for placement in your designated S3 bucket. You can then download the backups from Amazon S3 and restore them on SQL Server on an EC2 instance, or run the `rds_restore_database` stored procedure to restore the database to Amazon RDS. You can also use [AWS Snowcone](https://aws.amazon.com/snowcone/) for databases up to 8 TB in size. For more information, see the [AWS Snowball Edge documentation](https://docs.aws.amazon.com/snowball/latest/developer-guide/whatisedge.html) and [Importing and exporting SQL Server databases](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/SQLServer.Procedural.Importing.html#SQLServer.Procedural.Importing.Native.Using), *Restoring a database* section, in the Amazon RDS documentation.