7. Final configuration
7.1 Redirects
I needed to make sure that people using my existing URI could find my new site. As I was just losing the /blog/, I created a /blog directory in my new WordPress root and put a redirect in there in an .htaccess file.
Options +FollowSymLinks
RewriteEngine on
RewriteRule (.*) http://yourdomain.com/$1 [R=301,L]
The text of the redirect I lifted from Blogging Tips. Kevin over there is a great help.
7.2 Permalinks
If you’ve got pretty permalinks on your existing site you need to make sure that your .htaccess file is copied over in 3.1. Pretty permalinks don’t work without that .htaccess file.
8. Communication
8.1 Prepare some “move” posts for your blog
If you’ve planned this well, you will have prepared two blog posts:
- one to announce your impending move, and
- another one to announce your arrival at the new host.
You’ll publish the “departure” post just before step 3.4, or maybe just before you change the nameserver in step 9, and schedule your “arrival” post to be published in a day’s time. Your “arrival” post will say something like “if you can read this, I’m at my new webhost. Please report any bugs by leaving a comment below”.
Before you change the nameserver (step 9 below), you’ll want to delete the “arrival” post from your old WordPress installation so that it doesn’t pop up there and confuse the hell out of everyone if the propagation of the DNS changes takes longer than a day.
8.2 Tweak your new header.php
Just so that I know when all the DNS stuff has propagated, using my FTP software (or cPanel file manager) I edit the header.php in the copy of my active theme which I’m going to send over to my new webhost: I add “(at new webhost)” after the < ?php bloginfo(’description’); ?> tag. I’ll delete it once everything’s working satisfactorily.
9. Finally…
The moment of truth…
Update the nameserver and hope for the best. Go and have a beer. You’re going to need to conserve your energy for cleaning up all the bugs.
For me, it took less than twelve hours before the proverbial hit the fan. A heavy-duty cleanup was required, but unfortunately the hit squad was just me…
10. Lessons learned
Maybe if I’d had my time again, my test blog would have been on my new VPS rather than at my existing host. I thought I’d minimised the risk by moving over another live blog before doing my big site. But the small blog used very few plugins and so did not really test the limitations of the default VPS configuration.
If, like me, you’re focused on the content rather than the infrastructure, you’ll know very little about server configuration. It’s strange when you have two apparently identical WordPress installations – including the same file permission settings – but on one website a plugin works and on the other it doesn’t…
So, maybe if I’d had my time again I’d have tried to run a parallel installation of my big website on the VPS before changing the DNS settings. But I’m guessing that if I did that, I’d have spent so long ironing out the problems on the test site that I would never have made the move. In a test environment, there’s no real time pressure to get things working, whereas when you crash land there’s immediate pressure to get the bugs fixed. I’d paid for about 6 months of VPS space before I started doing anything with it. I’d spent too long dithering and it was time to make a move. It’s been a learning experience.
Post a Comment