I have a physical server that the company wants to move to virtual - currently, it is a subscriber in Transactional Replication on a very large database. What would be the best way to minimize the downtime?

Initialization from backup will still take ~ 30 minutes for the backup, 2 hours for the restore. I do have the virtual server available to me - would it be possible to set the database that is being Replicated to Log Ship to the new virtual server (to keep it in sync), then when we get ready to do the cut over somehow just re-create the Replication and have it "pick up" without having new snapshots/etc?

  • So the virtual server name will be different from the physical server ? Why not just do a P2V (Physical to virtual) so the name is same along with IP. This way you just have to disable log reader agent and once the server is up as virtual, replication will pick it up. I have done this many times and I did not encounter any problems with replication.
    – Kin Shah
    Feb 9, 2017 at 14:42
  • Kin, from what I understand P2V will take quite a while because of the size of the databases, unless I am misunderstanding... I could have the Server guy give the "new" Server the same name/IP but I do not understand how that would "fool" replication... Feb 9, 2017 at 14:44
  • 1
    Depends on the size .. check with your sysadmin on how long will it take. If you rename the server with same name and IP, replication will automatically pick it up. It relies on the name of the server instance. The distribution database knows where the subscriber is. So once the subscriber is up, it will just catch up.
    – Kin Shah
    Feb 9, 2017 at 14:54
  • I just checked with our admin and he is saying ~4 hours since the size of the DB's are so large... But - on that same page, if I put the "new" virtual server and log-shipped the database involved in replication from old physical -> new virtual to keep it synced up, then when the downtime starts bring the physical server down, rename/ip the new virtual the same as the old one is there a way I could copy the replication subscription and jobs to the "new" server and have it just pick up and go? Feb 9, 2017 at 14:57
  • 1
    Why don't you simply set up your VM as a second subscriber, with initialize from backup like you suggested? Once that completes, both subscribers are pretty much in sync at that point, redirect read activity to the VM subscriber, then shut down physical subscriber.
    – Greg
    Feb 9, 2017 at 20:11

1 Answer 1


You could add the new virtual server as a subscriber and once all of the data is replicated to the new virtual server you can switch connections and delete the old subscriber server.

  • One of the problems we have is the database that is housing the replicated tables also has other live data, they didn't put the replicated data into its own DB. Could I add the subscription database as a log shipped secondary on the new virtual server then on the downtime create a new subscription with the sync_type = 'none' since they are already basically in sync? Feb 10, 2017 at 19:27
  • This should not affect the data. All you are doing is adding another subscriber and replicating the same data as the old server to the new server. Your way is possible but you will be taking unnecessary steps.
    – JAY
    Feb 10, 2017 at 20:37
  • I believe Greg above mentioned this also - I'm not quite understanding, could you give a more detailed "for dummies" answer? First time trying to do anything with replication other than just configuring it. Feb 23, 2017 at 15:02

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.