• The BIND DNS server has already been deprecated and removed from Plesk for Windows.
    If a Plesk for Windows server is still using BIND, the upgrade to Plesk Obsidian 18.0.70 will be unavailable until the administrator switches the DNS server to Microsoft DNS. We strongly recommend transitioning to Microsoft DNS within the next 6 weeks, before the Plesk 18.0.70 release.
  • The Horde component is removed from Plesk Installer. We recommend switching to another webmail software supported in Plesk.

Best Steps To Perform Migration

D

deeplist

Guest
Okay, let me explain the situation and then I would like to know what the best course of action would be to make this happen with minimal downtime. I currently have a dedicated server (Server A). It is old and outdated, so I purchased a new server (Server B).

My corporate site (Corporate Site), along with all of my client sites (Client Sites) are currently on Server A. My Corporate Site has 4 nameservers currently pointed to Server A's IP addresses. All of the Client Sites use the corporate site's nameservers. I want to migrate the Corporate Site and the Clients Sites to Server B. I already know how to use the plesk migration manager, but what is the best course of action to transfer these sites with very minimal downtime in terms of changing the nameserver IP addresses to Server B's IPs, and when this should be done in relation to running the migration manager from Server B to pull everything over.

Thanks in advance.
 
Run migration manager on server B and migrate all the sites. Then go into each site and fix their SSL settings since the migration manager will have screwed them up by unassigning the certificates and turning off the setting of using the same directory. Once that has been done, go into dns manager for each site on server b and replace the records for the site IP address with the appropriate IP from the old server. Set a low TTL (time to live) value of maybe 200 seconds in the DNS setup settings on server B. Point the name servers for each domain to server B's IP's. Now over the next 24 to 48 hours, the DNS duties for all of the domains will slowly change to server B, but all the email and traffic will continue to go to server A, so no outage or issues while you wait for the change to take effect.

48 hours later, you can do one of two things; 1) sync up anything that has changed in the customer's files, databases and email to server B manually using rsync, mysqldump, etc. Then go into the dns manager for that site and set the IP address back to the server B IP, now the site's traffic and email flip over to the new server within 200 seconds.

Or, delete the site from server B and re-migrate; it will be down for the amount of time from when it's deleted until the migration completes since the DNS will be removed when the site is removed, but that shouldn't be long if they're reasonably sized sites, then once migration is complete the DNS is already set to the appropriate server B info and you're done. Of course this second option is complicated by the fact that the 9.x migration manager is royally screwed up in that it resets the SSL settings for every site on the server each time you do a migration, so if any of your sites use SSL, you're going to have to go through and fix their settings after every single site that you migrate.
 
None of the clients use SSL of any kind, so we're ok there. Here's what I have done so far.

I've gotten Server B ready to go, everything that I need is installed and all the configurations have been made. I logged into Server A and set the TTL value for all of the domains (roughly 16 of them) to 300 seconds, or 5 minutes.

Now, let me know if my logic is correct here. If I run the migration manager on Server B and pull everything over in the middle of the night, say early Sunday morning, and then change the DNS settings for each domain with the new server's IP on Server B, in theory, there should only be a 5 minute delay for anything (such as emails) that are sent during that 5 minute window. Would that work?

I already changed the TTL values to 300 yesterday evening, so I am going to wait out the 48 hours so I knew that there will be no ISPs with the old TTL value cached.
 
Make sure you're serving the 300 second TTL on the NS records in the zone and not just the A records, and that will help, but the next issue you'll face is the fact that name server changes do not make it to all the root servers at the same time; so you're pretty close to optimal if you're serving 300 second TTL on all records including the NS records, but it may be a few hour change over since you still have to wait for the name server change to make it to all root name servers.
 
Back
Top