IP migration scenarios

Created:

2017-04-18 13:41:39 UTC

Modified:

2017-08-08 13:23:04 UTC

0

Was this article helpful?


Have more questions?

Submit a request

IP migration scenarios

Applicable to:

  • Plesk for Windows
  • Plesk for Linux

Method 1. Migration to new IPs

  1. You have real public IPs on the destination server (same amount of exclusive and shared IPs or different than on the source server).
  2. Optionally decrease the TTL for DNS zones, for details please refer KB #213912645
  3. Migrate to these IPs
  4. Verify how websites work locally on the destination server by adding the other IPs into the hosts file.
  5. Point websites in DNS to the new IPs after migration.
  6. If DNS could not be switched for a domain for a long time and the content got out of sync - it is possible to sync web/databases/mail data with the source server without starting full migration anew. For details please refer KB #213403989 .

This method is recommended and used commonly, as it is safe and flexible and requires minimal services interruption so you can switch websites one by one at any time when verified that they were migrated fine. If there is a problem to switch DNS only for several domains, then the "Step 6." would be the best option.

Method 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)

Method 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 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.

Method 2c. Migration to same IPs with isolation without 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 most simple, 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)

Have more questions? Submit a request
Please sign in to leave a comment.