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 Pressalone 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.conf file 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).

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

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!

Other resources..

Here are other resources that I found most useful during the migration process:

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.

Check it out

Comments

@Eric: Currently, I’m comfortable hosting as many sites as possible, until the RAM usage begins to top 70% or so. Right now I have 24 sites, some small, some large, all served via 512MB (dv) and the usage stays less than 50%. I think it’s $500/yr for the Base (dv) I’m enjoying now.

@Chase: I’ve had no issues with upload-directories/permissions, but I haven’t really looked too closely at it. Once I get to that point, I’ll report back if there are any issues.

@Skye: Mint is definitely my favorite, but GA is also tops. I just prefer the simplicity and elegance of Mint, and watching people surf around my sites in real-time is SO much fun!

@Peter Bockenhauer: I thought about switching everything over to a MU setup, but many of my WP sites really need to remain independent. I like having each site isolated from the others. It helps to keep things streamlined and organized, updates are usually a breeze, and issues don’t spill over to affect other sites. But MU is awesome and keeps getting better, and I’ll continue to use it for clients and/or when needed.

@Jeff: RE: MU/Multisite, yes I will probably have to keep some sites as an individual install. I can think of some sites that I have customized the plugin (and unfortunately have to remember to customize every time I update them). So since multisite uses one set of plugins for all sites, that won’t work so well for sites that use the same plugin.

Being able to setup a new WP install in like 2 minutes is just crazy… definitely worth it for most of the sites we do.

The only thing that drove me crazy when I switched a single WordPress site (I know, small migration) was the path of the media folder hidden in the WP settings. I wasn’t able to upload any image untile I figured out. :D

Re IPs showing as 0.0.0.0 : If your [v]server is behind a proxy or load balancer [e.g. Netscaler], misconfigured device doesn’t translate client IP number to the app-server, as a result of which your machine doesn’t know where the package of data is originated from. If this problem persists system-wide [every app on server], then the situation is as described, i.e. it is network configuration related. If it is persisting only for a certain app(s) [mostly those which you installed, those that don’t come pre-installed with the server itself], then it’s application related. In this case, most probably certain network related settings need to be made in your application. There might be a situation where client IP address is translated via some other proxy header, instead of “Remote-Host:”. I think it’s worth checking out…

I freed up about 10% memory usage after disabling DNS and SpamAssassin.

Looked into MySQL optimizing. I’ve noticed on (dv) that core and plugin upgrades take longer than they should. The upgrade from 3.0.3 to 3.0.4 took 3mins30secs on (dv) and only about 30secs on my Go Daddy shared hosting. I contacted support and they pointed me to these optimizing docs. As far as I can tell caching was already enabled. Installed MySQLTuner and will look into other changes I can make.

@Shehi: Thank you for sharing that information. I dread the thought of having to hack the app or the extension to fix the 0.0.0.0, but I’m thinking you’re right that it’s an app issue and not a (dv) issue.

@Peter: Yes, that article helped me during the transfer/setup process, but somehow it didn’t turn up while writing the article. The link is now included in the “resources” section of the article. Thanks for the link and for the tips!

Books

Links

About the site

Perishable Press is the work of Jeff Starr, professional developer, designer, author, and publisher with over 10 years of experience. Check out some of Jeff's books and projects, follow on Twitter, or learn more »

Fun fact: Perishable Press has been online since 2005, and now features over 700 articles and more than 11,000 comments. More stats »