Sql-server – Migration to SQL Database using Transaction Replication – down time

azuremigrationsql servertransactional-replication

I am looking to migrate two on-prem SQL Servers into Azure Hyperscale. Both 28 cores, 1.5 TB of RAM with 10TB data disks.

I can NOT afford any downtime during the migration and have heard transaction replication method might do the trick.

Has anyone had a scenario like this where they used this process?

There really isn't a quiet time. It's a cell phone sub carrier with roughly 2,000,000 users. There is roughly 30GB of data updated twice per minute. Currently on SQL Server 2014 Enterprise Edition.

Best Answer

If you configure replication, replicate to the external site, keep the replication going until a quiet time then stop it and reconfigure the destination as not replicated. There are some limits replicating to Azure, see https://docs.microsoft.com/en-us/azure/sql-database/replication-to-sql-database to see if they apply to you. There are also some differences between on-prem SQL Server and Azure SQL, they are minimal-to-nothing for most simple databases these days but do check the documentation (and test the application thoroughly before switching over) to make sure they don't affect you.

There will be a small amount of downtime as you stop replication and reconfigure your application to point to the new database, but that should be minimal.

Obviously you'll want to test this out: point a second instance of your application at the target DB and test thoroughly. Once you are convinced all is well wipe it down (as it will now be out of date) and build a new replica (or have the new replica building while you perform the testing). You may need a couple of iterations of this do->test->fix->do loop if there are problems with the replication or your app reconfiguration, or you need to make changes to account for differences in Azure SQL.