Notes on Switching Servers
Switching servers & migrating sites can be a HUGE deal (or not), depending on things like:
- Number of sites to transfer
- Size and complexity of sites
- Who is hosting your sites
- Experience
I recently did this, switching from a 3-year run at ASO to my new home at Media Temple. Total of 24 properties, with WordPress running on around 10 sites. Past experience with VPS servers really had me paranoid about running out of memory. A few years ago, Perishable Press alone gobbled up 256MB of RAM at WiredTree, so add another 23 sites on top of that and needless to say I was extremely concerned about the migration from a shared-hosting environment to a (dv) Base account limited to 512MB RAM.
Fortunately, the transfer was a success, and all of my sites (including a few client sites) have been running great ever since. I’ve been keeping a close eye on server memory usage, which averages between 35 – 50% for my entire operation. A much, much better switch than a few years ago, and still plenty of room to grow.
Every little thing..
So how did I do it? I mean, some of my sites (like this one) are 5+ years old, and come with a LOT of baggage. Websites are very much like trees: over time, directory structures grow increasingly complex, with increasing numbers of interconnected files and scripts requiring plenty of resources to thrive. One of my main goals while switching servers was to consolidate and streamline as much as possible. My general migration strategy went something like this:
- Setup new domain in Media Temple account and in Plesk
- In Plesk, setup & configure any extra services or packages
- In Plesk, create the database, mail account, and any subdomains
- Prepare the website to be transferred, upgrade WP, plugins, etc.
- Repair & export database, then import & check
- Clean up files, grep & update any changed paths, etc.
- Check/update htaccess files, database config files, and so on
- Upload entire site (including subdomains) to new server
- Setup any password-protected directories in Plesk
- Check new site using Site Preview (or via hosts file)
- Once everything looks good, switch DNS to (mt) servers
- Keep a close eye on things (like RAM) as traffic rolls in
- Once fully propagated, delete old files, db, etc.
- Have a snack, take a nap
By following this procedure carefully for each site (improvising when needed), I was able to shift my entire online operation from a shared hosting account to a (dv)-Base server with virtually no problems. There was some confusion over subdomain canonicalization, but really that’s about it. Everything else I needed was readily available online (except for one thing, explained in the next section).
Timewise, I think the entire process took about three days. I know that some migrations happen much faster, but I really wanted to take the time to do it right. Some transfers were pretty simple, just static/small sites or whatever. Other sites didn’t make the cut, and others were transferred but soon will be sold (or just deleted). But the main sites required some serious time, focus, and effort. It’s not easy rooting around old files and trying to figure out just what the heck was I thinking when I did that, and then taking the time to re-do it the right way. Tedious, yes, but my sites are in much better condition now than before the switch.
Other notes..
Just to keep it all in one place, here are some of the little things that are too useful to forget.
Keeping an eye on DNS/domain propagation
Throughout the migration process, the following online tools were indispensable:
These tools really helped while evaluating server resources and knowing when DNS propagation was complete.
Previewing the site on the new server
There are at least two ways to preview the site on the new server. The first is to just use Plesk’s built-in Site Preview feature, which makes your pages available at a temporary URL. That worked great for simple/static sites, but for WordPress-powered sites, it is much easier to just modify your computer’s hosts file, as explained here.
Increasing PHP memory on VPS/(dv)
By default, Media Temple’s (dv) server limits each site’s PHP to 32MB. For most sites, this is fine, but when that extra boost of memory is needed, here is the easiest way to make it happen:
- Enable root-access and log in as root via SSH
- Create a
vhost.conffile at/var/www/vhosts/domain.com/conf/ - Add this line to the file:
<Directory /var/www/vhosts/example.com/httpdocs/>php_value memory_limit 64M</Directory> - As root, run this command:
/usr/local/psa/admin/sbin/websrvmng --reconfigure-vhost --vhost-name=example.com - Restart Apache
Of all the different ways to increase PHP memory, this is what actually works on (dv) servers.
Unresolved issues
As mentioned, so far there is only one unresolved issue, and a small one at that. For several of my sites, I’m running Shaun Inman’s Mint Statistics, and everything is working great except for one thing. For some reason, the IP addresses recorded by the Session Tracker extension are shown as 0.0.0.0. About half of the IPs are recorded properly, but the other half are just zeros.
I’ve scoured Google for a solution, but found nothing that seemed to help. So if you have any ideas, please share them in the comments. Thanks!
Quick summary and I’m out..
Transferring my sites to a new server was a great decision. Everything is faster, cleaner, and more secure than ever before. The key to making this happen is finding a good host and taking your time during the migration process. Especially with hosting, time is money, and you get what you pay for.
19 responses to “Notes on Switching Servers”
Exactly what I needed. I may just make use of this President’s day after all! Thanks for sharing. I expected that you’d have to make use of all sorts of nginx and caching related stuff in order to even breath within 512mb, but it’s reassuring to know that it sort of worked out of the box on their servers. I’m sure those things won’t hurt, but it will save having that work upfront. Thanks again, Jeff.
I have been contemplating a similar switch however I have been thinking the cost would be prohibitive. I have 15 sites working pretty well on a shared server (legacy plan at Joyent). When I looked at upgrading it seemed to me that I would need a virtual server for each site which would be very expensive.
It seems that is not the case after reading your post. How many sites are you comfortable with hosting on one server? And if you do not mind, how much are you paying now for your hosting?
Cheers,
Eric
Nice article! I just recently switched over to Media Temple (dv) as well. I’m curious: did you have upload folder permission issues from the get-go? I sure did. Maybe it’s just my lack of experience with advanced server administration, but I had a heck of a time getting WordPress to upload/update without error. I ended up having to set permissions via root access. I wonder if this is a common issue with Media Temple/Wordpress installations or just my lack of experience…
Glad everything went smoothly.
Jeff how do you like Mint? Better than the WP Plugin versions? Statpress etc. Or Google Analytics or StatCounter?
Weird issue with the IP addresses. I don’t use Mint so not sure what it could be. Sounds like a software issue if only half are being recorded.
@Chase – I noticed the same upload folder permission problems with (dv). It is because php is running as the apache user, rather than the domain/FTP user (like on most shared hosting). Apparently you can run PHP as FastCGI and this solves this problem. I never wanted to go through this change, so instead I just make sure my upload folder is set to 777 permissions and that allows WordPress to write to the directory just fine. Seems like bad practice, but I haven’t found a better way. I also noticed that theme files need to be set to 666 in order to be writable from inside the WordPress admin. I think this is pretty common for VPS setups. All the shared hosting I’ve used is setup differently and doesn’t require these permission changes.
Jeff – I recently got WordPress Multisite working on my (dv). So far so good. I currently have about 15 individual WP installations on my (dv) and a few more on Go Daddy. I plan on rolling them all into this multisite. Looks like it will make my life so much easier. Keeping all these upgraded has become a full time job.
@Chase – Forgot to mention. For doing auto-updates in WordPress, you can add your FTP credentials in wp-config and that will solve that problem. You can find instructions here on digwp ( https://digwp.com/2010/11/ftp-in-wpconfig/ ).
Jeff, like Peter B, the client sites I manage are on a Multisite install.
Consolidating seven upgrades into one reduces maintenance time substantially, although one MS upgrade requires more care than one standalone upgrade.
Donncha’s domain mapping plugin is a godsend.
@Peter B – Thanks for the input. That’s similar to what I did as well. I followed this tutorial to get things running properly. The only issue is that I have to do that with each new wordpress install which is a bit annoying, but I suppose that’s how it goes.
@Chase – But I wonder if giving the apache user group rights is softening the security on the (dv). Just thinking that this is by design for a VPS? Having the apache user no group rights in say shared hosting is less secure than the default VPS setup? Maybe Jeff knows more about this and can chime in. I haven’t done much research on it myself. I’m always hesitant to mess around with too much on the backside with root access. I’ve managed servers in the past, but now with (mt), I’d hate to f something up and then (mt) support come back and say “sorry can’t help you, you knew the risks of root when you enabled.”
@Peter B – You may be 100% correct. I’ll keep digging around. I definitely want to find the “right” way to do it (SOMEONE must know, since I’m sure there are tens of thousands of wordpress sites hosted via Media Temple). That’s why I initially thought it was just inexperience on my part, since everyone seems to be pretty silent about it.
Great post Jeff!
Will help the next time I’m switching servers.
Do you have any content on IPv6?