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