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.

  • Could you clarify what your question is? Are you asking what the expected downtime would be if you use transaction replication? Commented Sep 3, 2019 at 20:08

2 Answers 2


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://learn.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.

  • 1
    Then you'll have to reconfigure the application very quickly to minimise the downtime! IIRC OnPrem->Azure replication only supports read-only (one-way) replication so you can't set some application nodes using Azure first under load balancing and then switch the rest, as you might be able to do with bi-directional replication. The other issue will be: does your network have the throughput and latency to Azure that would allow this amount of data to flow - otherwise the replica would never finish building. Something to test before you consider going further. Commented Sep 3, 2019 at 17:17

You say you have two servers, and you can not afford any downtime so I am going to make the leap and guess you are using AlwaysOn, on your existing on prem servers.

You can include/add Azure databases in your on prem AG, if you are using a listener, you could just failover to Azure when you are ready. Later drop the on prem servers. Near Zero downtime, and quick fail back if Azure will not handle your workload.

Extend on-premises Always On Availability Groups to Azure

Note I have never tried this, but it should work in theory.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.