Guest post by Katherine

We recently migrated our WordPress site to a new hosting platform. In the interest of sharing information, we’ve documented what it was like in detail. While the particulars may vary, hopefully you will find the following information useful. In our specific situation, the previous hosting platform was GoDaddy, and we chose to migrate to Bluehost.

Why migrate our WordPress site to a new hosting platform:

• Site was slow probably due to their not having enough servers. When we asked about it, they suggested buying a premium package.
• Site required us to pay $75 a year for a SSL certificate. They should be standard these days.
• Improved customer support.

The actual migration could have been done by:

• paying for someone else to migrate it,
• purchasing a plug-in,  or 
• doing it myself with free stuff. 

Lessons (luckily, many of these I didn’t need to learn the hard way):

1. Work in a test area, establish that your website is functioning, then move your domain over.
2. Changing the background color on the test area website is a great idea since I was never confused about which one I was working on.
3. Make back ups before you start. Make back ups when you come to a stable point. And then make a back up when you’re done. And then make sure you have a back up strategy on your new hosting search site even if you didn’t have one on your last but especially if you used the old site’s default and the new one is different
4. Don’t forget to establish HTTPS redirect since people might be accessing your site from a URL that begins with http: which browsers do NOT like.
5. Use a free plugin to bring over the base of your website including navigation quickly and easily.
6. Migrate at least a month before your service contract is up so you can keep your files with your old provider just in case you missed something.

I chose the do it myself option since I had migrated my personal website several months ago and used the opportunity to make some changes. Also, once I had ‘most’ of it migrated, it seemed silly to start over with a paid plug-in, or to pay someone else to migrate it. 

The migration would have been simpler if our website was mainly a series of links to other sites, which was the original vision. But, we host the course material from our partner, PRC, that otherwise wouldn’t be publicly available. (Barry keeps the material up-to-date with PRC’s courses on their private server.) And all of our photos of bridges, and conferences, and other things meant that our media files were larger than could be easily imported into WordPress with the WordPress provided tools.

There was a neat looking plug-in called “all in one” that allowed downloading the entire website without paying for the plug-in. However, when it came time to upload the website, the file was too big for the free version. I did download a smaller set of pages and then uploaded it with the free version. It kept the navigation which would be useful, but I had already done that manually taking the opportunity to clean it up a little.

Using the regular WordPress download/upload tool, I had difficulty uploading media files. There was some internal limit that I was hitting even after I made the files smaller by only loading a month’s worth of media at a time. I did a little searching and came up with parameters to change. I wasn’t familiar with editing those files and was worried that I would lose the considerable work I had already done. Next time, I’d start with the media files, and a bare-bone website so if I lost it, it wouldn’t matter. I did have a test website to try things out, but the one I was migrating was already pretty far along when I ran into trouble. So I brute-forced it uploading the files multiple times until all the media came across.

Barry handled the export & import of the participants database. This involved generating a CSV file from the old site, making sure that the proper fields were selected for export, then using that as the basis for an import on the new site. The only thing that didn’t come over were the logo files that had been in the database, so these had to be loaded into the database manually.

I encountered a few PowerPoint files it wouldn’t upload so I converted them to PDF since I figured the author might be doing something that made it more susceptible to hacking since it wasn’t passing safety checks and I’d rather not go around them

I added a couple of pages to the site while it was under development. Once the site became associated with its real domain, the URLs for those pages had to be changed by hand. So I don’t recommend adding pages while you’re migrating.

Since we like to have the page URL be the title of the page rather than just a number, I made that change in the word press settings. But the homepage wasn’t correct. I tried several different things, knowing that I probably should stop and come back another day. But instead I tried something that locked me out of my site. This is where having good customer support helps. (Both in house–thanks, Barry!–and from the hosting provider.) I was able to turn the problem over to Barry who contacted customer support. I’ll let him tell it.

Barry says “I used the chat features and phone calls, and the bluehost support folks were very friendly and helpful. In the case where the site was locked out, they quickly resolved the lock-out issue and the original issue with the URL address properly reflecting our domain name. I was very impressed by Katherine’s ability to hand it off calmly. When I’ve done things that result in a major loss of functionality, I sometimes have a hard time letting it go while the resolution is in progress.”

Once we had a version of our site in the test location and it looked reasonable, it was time to move our domain. We started by telling the old host that we wanted to move it. Instructions for doing this are available on the site of the hosting domain. After moving the domain, the files were still available through FTP on the old site. We kept them there for two months just to ensure we hadn’t missed anything in the migration.

A few days after migrating, we noticed that old links to the site were going to non-secure pages. I had missed bringing over the plug-in that handled HTTP to HTTPS. Once that was installed and activated, the problem went away. Our contact forms required a little tweaking as well.

Overall, migrating to a new host was easier than I expected. It is best to do it with a concentrated push but allow time during the migration to step back and think about what might make things easier.