How to choose IP migration scenario in Plesk

It is recommended to have the same amount if dedicated and shared IP on two servers, but this is optional. This scenario is recommended and used commonly. It is the safest for websites availability, causes minimal services downtime: the websites can be switched to the new IP one by one at any time when verified that they were migrated correctly.

1. (optional) Decrease TTL for DNS zones to 1 hour or less (step #9 of this article). Low TTL value will allow clients to get the DNS updates faster.
2. Perform migration to these IPs
3. Verify how websites work locally on the destination server by adding the other IPs into the hosts file (verification will be done automatically, if Check the operability of services after migration checkbox was selected before migration).
4. Point websites in DNS to the new IPs after migration.
5. If DNS could not be switched for a domain for a long time, sync web/databases/mail data with the source server without starting full migration anew.

Scenario 2a. Migration to same IPs using interim internal IPs

1. Have temporary internal (not routable) IPs on the destination server (same amount as on the source server)
2. Migrate to these internal IPs
3. Verify how websites work locally on the destination server by adding the internal IPs to the hosts file.
4. Remove the real IPs from the old server or shutdown it (to avoid IP conflict when we bring the IPs on the destination server online).
5. Add the real IPs to the new server.
6. Change IPs of Plesk subscriptions on the new server from temporary to the real.

This method is applicable if you do not have enough additional public IPs for the destination server to migrate to.
Another case is if there is a problem to switch DNS for most of the domains to the destination server IPs in a timely fashion (for example, domains’ DNS is hosted by different DNS providers and it takes a time to organize switching each one). This method requires services interruption between steps 4. and 5. (Switching subscriptions’ IP can take up to half an hour depending on the number of websites)

Scenario 2b. Migration to the same IPs with isolation

1. Add same IPs on the destination server that are on the source but isolate them (avoid IP conflict by placing the IPs on the destination in a different VLAN or by blocking arp requests)
2. Add two more different public IPs – one on the source (IP1) and one on the destination server (IP2)
3. Perform migration of all websites to IP2, starting the migration from the source server via IP1
4. Verify how websites work locally on the destination server by adding IP2 to the hosts file.
5. Switch subscriptions’ IPs on the destination server from IP2 to the real IPs
6. Shutdown (or isolate IPs on) the source server and make IPs routable on the destination server

This method is the same as the previous one, but it requires less downtime because IPs are switched before shutting down services on the old server (as the IP switch procedure may take up to half an hour depending on amount of websites) So if you can isolate same IPs on the destination server to avoid conflict - it is a better option than the previous one. But it requires two more IPs.

Scenario 2c. Migration to same IPs with isolation without the ability to manually verify websites on the destination server before going online

1. Add same IPs on the destination server that are on the source but isolate them (avoid IP conflict by placing the IPs on the destination in a different VLAN or by blocking ARP requests)
2. Add one more public IP on the source (IP1)
3. Perform migration starting it from the source server via IP1
4. Shutdown (or isolate IPs on) the source server and make IPs routable on the destination server

This method is the simplest, however, the drawback is in impossibility of live manual checking how migrated websites work on the destination server (adding to the hosts file will not work, as the websites still work on the same IPs on the source server at that moment)