About a month ago, I received an email letting me know that my host, Media Temple, is discontinuing their (dv) Dedicated Virtual 3.0-3.5 servers. Everyone hosted on the old servers must migrate to the new (dv) 4.0 servers. The friendly (mt) email says:
The migration is a fairly simple process and you’ll have until early summer to complete it.
Having now perfromed the migration, I can assure you that solid preparation is required to make it a smooth and “fairly simple process”. Based on experience, I suggest getting started on this asap rather than waiting “until early summer” to make your move..
There are a lot of pieces to the puzzle, and the goal of this article is to help bring them together into a supplementary guide — refer to the (mt) KnowledgeBase for official information about the (dv)-4.0 server-migration. There you’ll find definitive guides for each aspect of the process, but researching and bringing it all together takes some time. Hopefully this informal guide will help fill in the gaps and save some time. Here is the menu:
- Auto migration vs. Manual migration
- Pre-migration Questions & Answers
- Changes in Plesk
- Previewing your sites on the new server
- Optimize before switching DNS
- Checking everything
- Final steps
- Wrap up
- Useful Resources
Note that this article is meant only for informational purposes. Please refer to the official (mt) documentation for authoritative information. Always remember to make good backups and take precautionary steps before making any changes on your server. I provide this information freely and without guarantee; by using any of the information or code presented in this article, you fully agree to accept all liability.
Auto migration vs. Manual migration
There are basically two ways to go about migrating from (dv) 3.x to 4.0: manually or by using the Plesk Migration manager. Comparing these two methods against the relative scope and complexity of my server setup, I opted for the “auto” migration. There are pros and cons to each method, so examine each method carefully and choose the one works for you. This article pertains primarily to the auto-migration method, but may also prove helpful for a manual move.
Notes about the Plesk Migration Manager:
- Requires “shared IP” on both 3.x server and new 4.0 (dv) server
- Transfers most everything, but not any “high-level server settings” that you’ve made
- Transfers client data such as domains, subdomains, mailboxes, databases, and so on
- “You must have a new IP address on your new server” (not the same one as your old server)
- The auto-migration docs mention several important “gotchas” or snags known for certain setups
If you go the auto-migration route, take the time to grab (and backup) any custom firewalls, PHP settings (
php.ini), Apache settings (
httpd.conf), and so forth. Once the Plesk auto-migration is complete, use these backups to restore your high-level server settings. Also note that “contacts and spam filter settings for email users using the Horde Webmail client are not copied over”, so you’ll have to manually transfer those as well.
Pre-migration Questions & Answers
Going the Plesk auto-migration route, I had initial some questions:
- Do I have to switch to an exclusive IP?
- Yes, on both old and new servers. The documentation specifies that a shared IP (as opposed to exclusive) is required on both 3.x and 4.0 servers for the auto-migration. But after the migraation “you can set the IP’s from shared to exclusive and visa versa whenever you want,” so it’s all good.
- What happens to my account if I do nothing before the deadline?
- “If the server is not migrated prior to the deadline, we will make an attempt to migrate your content automatically using the Plesk migration manager. Once the migration is complete, we’ll need to close the old service. The problem with this is that if there are any complications during the auto-migration, there’s not much time to work on them before the old server goes down.”
- Do I have to revert a PHP upgrade?
- In the documentation, it explains that, “If you upgraded your (dv) 3.0 to PHP5, you will need to revert this. Your site will break. Please see: Reverting PHP5 for (dv) 3.0 after a migration.” I wasn’t sure about this, so submitted a ticket for clarification: “..because your server is a (dv) Dedicated-Virtual Server 3.5, not a 3.0, your server was already running PHP 5. You do not need to take the actions explained in this article.” So basically PHP-reversion may only apply to (dv)-3.0 servers.
- Questions about lowering TTL (time-to-live)
- The (mt) KnowledgeBase article recommends lowering the TTL before beginning with the migration process. This sounds simple, but there are some additional useful things to know beforehand: 1) a good lower TTL value is 5 minutes, 2) it takes 12 hours for the lowered TTL to kick in, 3) the lower TTL remains in effect for 3 days, then automatically increases to the default value.
After resolving these initial questions, grabbing copies of my high-level server configuration files, and making a complete pre-migration backup, it was time to jump in and get it done. For this, I followed as closely as possible the (mt) guide to using the Plesk Migration manager. Other than a couple of hiccups, the auto-migration went amazingly well. The first bit of confusion happened during the pre-migration configuration steps, where the screenshot in the (mt) docs didn’t coincide with the new settings for the Migration Manager:
As seen here, the current version of Plesk changes some default settings and provides some additional options. Basically I just went with the default settings (rolled the dice!) and the migration went flawlessly, aside from the following two (minor) errors:
Error: client "username" The password was generated for user 'Domain Administrator (example.com)'. New password is '*******' Error: client "username" The password was generated for user 'Domain Administrator (domain.tld)'. New password is '*******'
The (mt) docs include many different troubleshooting tips for things that could go wrong, so I was prepared for the worst. I was unable to find any information regarding these specific errors, but they were the only ones, so I just said “whatever” and moved along with business at hand. Warm buttermilk biscuit to anyone who knows more about these mysterious “password-generated” errors.
Changes in Plesk
After completing the migration and resolving any reported errors, the first thing you’ll notice is the brand-spankin’ new Plesk control panel interface. Basically everything is different now, requiring no doubt a massive amount of time cumulatively spent for everyone to figure out where everything is located. And they bury some stuff deep, so be prepared to guess well, or search quickly. Most of the interface changes are sort of intuitive once you get the gist of how things are organized.
The main thing that threw me off was Plesk’s new “Power User Mode”, which organizes and displays your settings in some sort of special way that I have yet to understand fully. Until then, I can share some useful snippets and tidbits that helped me find my way around the new Plesk interface.
- Pay attention during pre-migration setup
- During the pre-configuration of the Migration Manager, it asks about “Power User Mode”, which sounded great at the time, but caused confusion after the migration because none of my domains were listed (as they usually are) under the “Domains” tab.
- Getting domains to appear after migration
- To get the domains to appear, I had to disable power-mode, which has various restrictions and limitations that affect which customers can view which subscriptions can include which domains, or whatever. Frankly it’s confusing, and I don’t have the luxury of spending another chunk of precious hours studying the Plesk documentation.
- Disabling and enabling “Power User Mode” via command line
- To disable power-mode: “
usr/local/psa/bin/poweruser --on” and to enable power-mode: “
usr/local/psa/bin/poweruser --off” (no quotes!)
- Change Power Mode settings
- This may only work during setup, but you can change the default Plesk control-panel view by accessing the user-interface switcher directly at “
https://123.456.789.123:8443/server/uiswitcher.php#” (no quotes) — replace the IP address with that of your new (dv) 4.0 server.
- Switch user mode directly via URL
- Not sure if this works in every case, but I was able to switch back and forth between power-user and normal-user mode by changing the port appended to the URL:
https://123.456.789.123:8443/— Regular User Mode
https://123.456.789.123:4643/— Power User Mode
Once you’ve got your way around the new Plesk (currently at version 10.4.4), take the time to preview your sites, resources, and settings to make sure everything is functioning properly.
Previewing your sites on the new server
To check your sites on the new server before switching the DNS, you have several options, including fiddling with name servers in Plesk, finding where Plesk hides the “site-preview” links, or handling it locally via your computer’s
I went the
hosts file route because it’s completely noninvasive, efficient and effective. Using Terminal, here is how to edit the
hosts file on a Mac (OS X):
- Open Terminal: Applications -> Utilities -> Terminal
- Open the
hostsfile (from Terminal):
sudo nano /private/etc/hosts
- Edit the hosts file: move the cursor to the bottom of the file and add your new IP/domain mappings, which look like this: “
123.456.789.123 example.com” (no quotes) for each of your domains (one per line).
- Save the hosts file: after editing, press control-o to save the file, and press enter when prompted.
- Exit the text editor: press control-x to exit the editor and return to the command prompt.
- Flush the DNS cache: at the command prompt, enter “
dscacheutil -flushcache” (no quotes) to flush the cache immediately.
Once you’ve checked your sites, databases, settings and so forth, it may behoove you to optimize your server before switching the DNS..
Optimize before switching over to new server
Before your new server goes live, you may want to further optimize some things to improve performance. Here are some recommended techniques for making your (dv) 4.0 even better:
- General MySQL Tuning
- General Apache Tuning
- Install Plesk Health Monitor
- Even more official optimization tips (full list)
In addition to these improvements, I used this guide to enable compression of web pages via Apache’s
mod_deflate. As may be verified using this online mod_deflate test,
mod_deflate reduces page size by over 70%. Well worth it.
Just a note about this: the RAM-optimization technique given in the first part of the Apache-tuning article result in the following changes made to your
<IfModule prefork.c> StartServers 1 MinSpareServers 1 MaxSpareServers 3 ServerLimit 50 MaxClients 50 MaxRequestsPerChild 2304 </IfModule>
<IfModule prefork.c> StartServers 1 MinSpareServers 1 MaxSpareServers 3 ServerLimit 50 MaxClients 50 MaxRequestsPerChild 4000 </IfModule>
Also, for the “removing-modules” optimization method, remember to check the list of disabled modules before going live. For example,
mod_speling is commonly used in .htaccess files, but is included among the disabled modules for this technique. If your
.htaccess file calls for any of the disabled modules, loading any page on your domain(s) will trigger the dreadful 500 Error – Internal Server Error. So to fix, just re-enable the module by removing the pound-sign (
#) appearing before its name in your main configuration file.
Another potentially useful optimization method is to install and configure Google’s mod_pagespeed, described as:
mod_pagespeed is an open-source Apache module that automatically optimizes web pages and resources they use. Optimization is done by rewriting the resources using filters that implement web performance best practices. Webmasters and web developers can use mod_pagespeed to improve the performance of their web pages when serving content with the Apache HTTP Server.
Deciding to give it a go, I successfully installed the pagespeed module via SSH. It required a significant amount of time to configure and get everything working. After experimenting with the different settings and running plenty of tests, it’s clear that, in this case,
mod_pagespeed really isn’t necessary. The resources required to run pagespeed outweigh the minor performance improvements. Here are some before/after screenshots showing Firebug “Net” results of loading the Perishable Press home page (click either thumbnail for full-size view):
Turn off the “named” service
Another potentially useful tip is to disable the resource-hungry “named” service. Named is used to run private nameservers, and should be disabled if you’re not using them. As explained in the (mt) docs:
The 64-bit version of named is quite the resource hog, and Plesk automatically turns on the service when you add your first domain.
The mailman program is used for organizing mass-email campaigns and gobbles up significant memory doing so. If you don’t use mailman, I suggest removing it if possible (it isn’t). If that turns out to be impossible, another effective option is to disable it. Here’s how to do it via SSH:
- Disable mailman:
- To prevent mailman from restarting:
chkconfig -—del mailman
- To enable mailman to be restarted:
chkconfig —-add mailman
- Enable mailman:
If you would rather remove it completely, you may try following the current (mt) guide for (dv) 3.5, but it doesn’t seem to work for the new (dv)-4.0 servers. If you try it, you should see the following error:
error: Failed dependencies: mailman >= 2.1 is needed by (installed) psa-mailman-configurator-10.13.4-cos5.build1013120126.11.x86_64
After finding zero info about this online, I contacted (mt) support to learn that this dependency is required by Plesk and should not be removed.
After fiddling, you may need to restart Apache. Either of these commands will work:
In the end, disabling mailman seems the way to go (if you’re not using it).
Further optimization tips
After inquiring with (mt) support about further ways to improve/enhance performance, the following KnowledgeBase tutorials were provided:
- Using MySQL Report on a (dv) Dedicated-Virtual Server
- Using MySQLTuner
- Basic MySQL performance tuning (MySQLd)
- (dv) Increasing Max MySQL Connections
Additionally, you may want to install an application for monitoring your server. Here’s a short-list of recommendations:
Other suggestions? Shout ‘em out in the comments :)
There may be a million things to check, but there’s no point in trying to second-guess what you might be looking at, so just take your time and be as thorough as possible before making the final switch to your new server. There are a few interesting little things that didn’t go as expected, however, and they’re worth mentioning them here.
Check PHP Safe Mode
While checking my sites before the switch, I noticed that several PHP-related scripts stopped working. After some sluething, I discovered that, during the auto-migration, Plesk seemed to have “missed” my old PHP settings for “Safe Mode”, which I had disabled on several WordPress-powered sites. Here are screenshots to help visualize:
Safe-mode settings after migration
Safe-mode settings set to ‘Default’
As seen here, the imported safe-mode settings looked like they were correct, but in fact were not being applied for PHP script processing. It’s as if the setting was actually set to “On” somehow behind the scenes.. but rather than dwell on the issue, I decided that a quick “toggle” to the ‘Default’ setting was worth a shot. And you know what, it worked — after setting the safe-mode to default, PHP once again worked properly for each site. Btw, in the new Plesk, the ‘Default’ setting is the same as disabling Safe Mode.
WordPress Database Manager
One PHP script that was affected by the safe-mode issue is the backup plugin, WP DBmanager. On Media Temple servers, the following paths are used by this plugin:
- Path To mysqldump:
- Path To mysql:
Yet even with these paths defined, WP DBmanager could not create a backup on the new (dv)-4.0 server. After trying all of the usual tricks to get backups working again, I finally flipped that “Safe Mode” setting to ‘Default’ and suddenly backups started working again.
While on the subject of WordPress, I also noticed that plugin and core updates were not working after the migration. After trying many things, adding the following line to each site’s
wp-config.php file did the trick:
Of course, if you use this, remember to edit the path with that of your own.
Remove unused added empty directories
After migration, check each of your sites for two newly added empty directories,
Plesk takes some liberties by adding two empty directories to every migrated site
These may be deleted if not used, and don’t seem to get re-created once gone.
Memory warning in the Account Center
Tired yet? Another thing that I found interesting (and slightly disturbing) is the new “Server Status” alert in the Account Center:
The server-status alert in the (mt) Account Center
The dot/icon changes from green to yellow to red, depending on the status of your server. Clicking that status icon pops open more info:
Click the server-status alert for more info
I kept seeing yellow status indicators while working on the migration, and would sort of panic.. eventually learned that the memory status shown in the Account Center reflect only the “guaranteed maximum memory” purchased for the account. There is generally more than this amount of “burstable” memory available, however it is “not guaranteed”. Also keep in mind that (dv)-4.0 is 64bit and requires more resources than the old 32bit (dv)-3.x servers.
Monitoring server resources
For a sweet way to monitor all of your system resources in real-time, connect via SSH and enter the “top” command. It shows all running processes, displays real-time memory usage and much more. Very useful for tracking down processes that are consuming too much memory. Here are some helpful commands:
- Run top: enter
topin Terminal (or whatever)
- View by memory used: press
shift-mon your keyboard
- Quit top: type
qon your keyboard
It’s one of those programs that’s just simple and awesome.
Once everything is looking good on the new server, it’s time to complete the process and “flip the switch,” as it were. I’ve broken this down into five essential steps..
Change DNS Settings
To point your domains to your new server, follow the steps in this article if you host your DNS with Media Temple; otherwise, “if you host DNS elsewhere, update your DNS records to use your new IP address(es).”
So for example, at my domain-name registrar — which is not (mt) — I use the following Nameservers for sites hosted at Media Temple:
When looking at these Nameserver entries, you may notice that neither of the associated IP addresses are the same as those of your server. This is normal, so everything is good if your Nameservers are correct (as shown above).
So with proper Nameservers in place, it’s time to change the DNS settings, which are in my case hosted at Media Temple. It is actually trivial to make this change by simply logging in to the Account Center and using the “Point to another server” tool. Here is the official (mt) guide.
This is technically all that’s required to get traffic flowing to your new server. And you have granular control in doing so, as the “Point to another server” tool must be used for each site hosted on your new server. I took advantage of this by first switching over all of my low-level-traffic sites, monitoring and watching the server load, and then when everything proved stable, switched over the heavier-traffic sites. They call it “OCD” ;)
Change Primary domain
Once traffic is flowing and everything is flowing smoothly, you may also want to change your primary domain. During the migration process, I used an arbitrary temporary name for the primary domain. After the migration is complete, the temporary domain name continues to be used until you change it. To do so, follow these instructions.
Note that after you change your primary domain, your server’s hostname will also be changed (automatically). This will cause problems with services like email unless you immediately change your server’s Reverse DNS to match the new hostname..
Change Reverse-DNS Records
As soon as possible after making changes to your primary domain, you should update your server’s Reverse DNS (PTR Records) to match. Here is the offical guide. Once that is complete, reboot your server to “make it so”:
At this point, all of your domains, DNS, hostnames, and so forth should all match up swimmingly, as reflected in both Plesk and the Account Center. To verify that the new DNS settings are working, enter the following command via Terminal or your favorite app:
Replacing the x’s with your IP address, you should see results similar to this:
123.456.789.abc-def.whatever domain name pointer current.example.com
For more info on this, check out this mind-blowing KnowledgeBase article.
Remove tempoary domain from Plesk
After everything was complete and the dust had settled, I logged in to Plesk to find that the temporary domain used for the migration (the one we changed in a previous step) was still listed among my other domains. After completing the server transfer, this remnant domain is no longer necessary, but apparently can’t be removed without causing problems for other actual domains. After a call to (mt) support, a technician looked into this situation and confirmed that there is no way to remove the temporary domain:
I was unable to remove the primary domain on my (dv) Dedicated-Virtual 4.0 Server without causing any issues to my domains underneath the subscriptions.
Oh well, if that’s the worst side-effect of transferring to a better server, well.. I can live with that. It would be nice to remove it though, seems sloppy to have to leave it there just for Plesk to work (imho).
Close your 3.x (dv) service
Finally. Once everything is complete and running tuff, don’t forget to close your old (dv) account. Depending on how things went, you may also want to take a long vacation somewhere, or maybe a nice nap.
Update your affiliate links
Lastly, don’t forget to update any affiliate links with your new primary domain. For example, my old affiliate link was this:
..and now after the migration, it’s this:
The system may redirect your affiliate links automatically, but keeping them current is probably the best way to go.
I hate this article! But it feels good to bring it all together for the record, plus provide some closure to the process further justified as a learning experience. Migrating to the new (dv) server is a lot of (unexpected/uplanned) work, but it’s worth it, in my opinion. So far I couldn’t be happier with the new (dv)-4.0 server.
Thank you Huge thanks to the super-awesome (mt) support staff. They are one of the main reasons why I continue to recommend Media Temple to customers and visitors. If you’ve found this article helpful and plan on hosting with (mt), please use my affiliate link so I can help provide for my family. Thanks!
Here are some additional resources that proved useful during the migration process.
- Plesk 10 Administrator’s Guide
- Default System Paths for (dv) 4.0
- Connecting via SSH to your server
- Tips on migrating to a (dv) 4.0 from a (dv) 3.x
- Using MySQL Report on a (dv) Dedicated-Virtual Server
- Using MySQLTuner
- Basic MySQL performance tuning (MySQLd)
- (dv) Increasing Max MySQL Connections
- How do I enable or disable Power User mode for my (dv) 4.0?
One more tip! You can see a complete list of all default system paths on your server. Just log in to the Account Center and click on the “System Guide” icon thing:
The System Guide in the Account Center lists many useful bits of information