More for my own benefit than for anyone else, in case I need to do it again, these are the steps I used in migrating my web site from one hosting provider to another, keeping the same domain name. In practice it was a bit more bothersome than what’s described below, as I took a few wrong paths and had to backtrack. The two pages that I found useful in doing the migration were …

• Moving WordPress
• Moving a WordPress Website Without Hassle

In summary, the steps I took were …

1. Sign up with a new hosting provider, choosing the option to use an existing domain and configure DNS to point to the new site when ready.
2. On the old site/host:
   1. Get a backup of the WordPress database on the old host, using the host control panel.
   2. Get a backup of the files on the old host by using FTP.
3. I added temporary entries to my \windows\system32\etc\drivers\hosts file to point my domain name to the new host.
4. On the new site/host.
   1. Create a new MySQL database, with the same name, user, password as on the old site. All the details I needed were in the “wp-config.php” file in the root directory.
   2. Use FTP to upload the files to the new site.
   3. Use phpMyAdmin to import content from the old database into the new database.
   4. Test that everything is working OK on the new host.
   5. Add a new blog post
5. Remove (or comment out) the temporary host entries in my \windows\system32\etc\drivers\hosts file.
6. With my domain name registrar, change the DNS settings to point to the new hosting provider’s name servers.
7. Wait for the new site (with its new blog post) to appear when the DNS change has propagated. (The domain registrar page suggested that this can take up to 48 hours, in my case I made the change about 8pm one night, and it had propagated by the time I got up the next morning.)

One minor obstacle I had in attempting this migration was that after uploading the content to the new server in step 4 above, the front page of the site was working OK, but clicking on any links to content elsewhere resulted in a “404 not found” error.

It turned out that in step 4.B above, when I was uploading the website files, I didn’t upload all the files in the root directory, as I knew that some of them were specific to the old server not the new server. e.g. files like the error log, or config files for the fantastico installer. I got this mostly right but unfortunately one of the files that I thought I didn’t need to upload was “.htaccess” – but as this forum article steered me straight – it is needed. After uploading the “.htaccess” file, the site sprang to life as it should have.

UPDATE 06-Jun-2014

For another WordPress site where I wanted to create a copy of the site for dev/test purposes I used the Duplicator plugin, which was pretty straightforward.

I run a WordPress based website that uses the wp-events plugin to manage a calendar of events. It’s been mostly working well, but recently after some update of WordPress, and I’m not sure which one, I found that on the Dashboard page of my WordPress site that I wasn’t able to toggle the various modules to expand or collapse them.  By a process of trial and error and comparing a few different WordPress sites that I have access to I found that the problem was the wp-events plugin – if I deactivated the plugin my problem on the dashboard page went away.

Unfortunately the wp-events plugin is no longer actively maintained, the author having moved on to other things, so I decided to see if I could locate/fix the problem.

Be warned – although I am an experienced programmer, I am a complete newbie in the world of WordPress plugin development, so there’s no guarantee that my ‘fix’ below won’t do really bad things.

Anyway, again by a process of trial and error, commenting out various bits of the plugin code I found that commenting out a single line of code in the wp-events-functions.php file fixed the problem …

function events_editor_admin_init() {
  wp_enqueue_script('word-count');
#  wp_enqueue_script('post');
  wp_enqueue_script('editor');
  wp_enqueue_script('media-upload');
}

After making this change, deactivating and reactivating the plugin, my dashboard was working again, and the events plugin appears to be working the same as before.

Conjecture mode ON

As far as I can tell this function is including a link to a script file in the page for the purpose of enabling rich text functionality in the event editor form, but I suspect that some update to WordPress made linking to this script redundant, and worse made it break stuff because different scripts were being loaded in the wrong order

Conjecture mode OFF