Reading Time: 12 minutes

Our law library has a supporting foundation—like a friends of the library group—that has a website. Like so many websites, it’s mostly brochureware. They had a change in their board composition last year and lost the person doing the web work and so I volunteered. It led to me migrating the website. Here’s some of what I learned, particularly with using CPanel and Siteground’s custom hosting portal.

Their website is heavy on images from events and light on text. There are only a dozen or so pages of content all told. If you had to store the website on a storage medium, you could do it on a very small USB drive.

This matters because, when you pay for web site hosting, you are usually paying in the range of US$150-200 a year. That isn’t a huge amount but every non-profit (and law library) should be looking at its expenditures for possible savings. Once I got up to my elbows in the foundation’s website, I realized that it was spending a lot for a very small site.

I should explain at this point that I have drawn a bright line between our law library and our foundation. The law library is a local government agency. The foundation is a privately incorporated 501(c)(3) non-profit. They are staffed only by volunteer lawyers, not with employees. They had, until I arrived last year, relied on our staff to run their administrative activity. This meant that law library staff were being tasked to do what were essentially second jobs. While the foundation supports the law library’s work, it diminishes that support if we are diverting our staff resources to gain it.

The description of a volunteer lawyer, unstaffed non-profit describes most small or local bar associations, I suspect. There are lot of bootstrap organizations whose resiliency depends on the volunteers to maintain continuity. Many are successful so I was confident that our foundation could be too.

This is a tricky distinction to maintain. We want the foundation to be successful but it also has to operate as an arms-length organization. After a year, they have shown themselves completely capable of doing that. So I was about to make a decision to blur that distinction: the foundation’s website was so small that I would rather host it with the law library’s to save the expense of hosting.

Non-profit website continuity isn’t a speculative problem. I know of a law library group that had a domain name and lost it. When you have unstaffed responsibilities and volunteers, it is easily foreseeable that things as simple as paying for website hosting or domain name registrations could fall through the cracks.

The annual savings on web hosting for their site is the value of a couple of books for our law library. If there is any interruption in the volunteer corps at the foundation, we’ll know their website is somewhere that is being paid for and so won’t go dark. It seems like a net positive. Also, it was a confluence where the decision-maker (me) had the skill set to do the migration for free.

But First, We Plan:
Prepare the Domain Names

I first pitched the idea of moving the website in winter of 2022. It was when I’d seen the size of the site and the hosting cost. I’d raised the issue with the foundation volunteers but there had been no action. As the next bills were coming due—for their 5 domain names and the 6 month hosting cost—I emailed the board to let them know I’d go ahead in order to save the money.

I had not at that point decided where to put it permanently. My initial goal was just to move them to a less expensive host. The impetus was the looming deadline to pay for another round of hosting and domains.

In this instance, it wasn’t just the basic hosting cost and limited features. The current site host charged $40 a year for an SSL certificate. Of course, all of your websites are already using SSL and forcing HTTPS, right? There is zero reason to pay for SSL for a brochure website. Siteground, Dreamhost, A2Hosting, and loads of others offer free Let’s Encrypt SSL certificates. This should be built in to the hosting cost. Also, you don’t need WordPress-dedicated hosting in most cases; just choose a shared hosting plan that allows you to install WordPress.

The first thing I did was to move the domain names off GoDaddy. I have mentioned Cloudflare as a registrar before. There are so many good reasons to have your website behind a free Cloudflare account. In this case:

  • domain registrations are automatically private,
  • domain name costs are at cost and so about half of what GoDaddy and other registrars charge,
  • you are also leveraging the firewall and content delivery network functions of Cloudflare, which reduce web hosting resources for bots and help to make your site available.

The reason I did this first was that your domain name(s) rely on the domain name system (DNS). When you move your website to a new host, there is a propagation period that can take a day or more. You are telling your domain name registrar that your domain name has moved from IP address A.A.A.A to IP address B.B.B.B. Your registrar has to let the DNS know, so that people who type in your website domain name go to B.B.B.B (especially if you’re no longer available at A.A.A.A).

Chart showing two models of managing the DNS for your domain name.  In the lower half, a box is inserted for Cloudflare, which takes over the DNS role from the web site hosts
Chart showing how inserting Cloudflare shifts the DNS connector from each web host (in black) to Cloudflare

This means that, in a migration to a new host, you will have two websites running for the propagation period. Your original site at A.A.A.A and your new hosted site at B.B.B.B. This will make the experience invisible to visitors. If you delete the old site before the propagation is finished, your site will appear offline.

Before I used Cloudflare, this would be the last thing I would do, after migrating the website. However, by creating a Cloudflare account for the foundation website, I could just shift the responsibility to Cloudflare. In essence, I was not moving from A.A.A.A to B.B.B.B but just shifting the entity responsible for DNS. Note: you do not need to use Cloudflare as a registrar, but I liked the incremental savings on domain names.

By shifting to Cloudflare, I had shifted the DNS without moving the website. Now I could migrate the website and, when it was ready, just point my Cloudflare account to the new website host (B.B.B.B) when I was ready. The change would be experienced almost instantly by visitors, like trains being shunted on to a new track as soon as the switch was flipped. It eliminates the latency in any future propagation.

Which was great, because I was going to end up migrating the site twice!

Step One and We’ve Only Begun

As I say, the initial goal was just to get it off the original web host. This would mean I could cancel the web hosting contract and look for an alternative. The easiest solution in this instance was to move it to my personal web host (not self-hosted). The cost was already sunk so it wouldn’t cost the foundation anything. And I was comfortable with the tools, for the most part, required to initiate the migration.

I moved the domain names. Then I started working on the site. The foundation uses WordPress and, as I say, it’s a simple site. In essence, all I had to do was:

  • use the Tools menu in the foundation WordPress site to export the posts and media content. This can then be imported into a new WordPress site (also under Tools). You may need to activate the WordPress importer plugin.
  • use a file transfer app (FTP) to download the content of the WordPress site that lives outside the database. This is all of your uploads, themes, and so on. I download the entire site when I migrate, even though I may use only part of it. The benefit of using FTP is that you can also make a backup copy just in case anything goes wonky.
  • create a WordPress site on the new site and import or upload all of the content I need (usually I only upload the wp-contentthemes, wp-contentplugins, and wp-contentuploads folders).

My website host uses CPanel as the administrative interface. It is not a really intuitive interface and, in my case, there were lots of tools I’d never needed to use. To that extent, it might be called complicated or busy because there is so much functionality exposed. This will matter when I get to the next section, below, and talk about Siteground’s approach.

As I was writing this post, it even took me a second to remember how I started the migration! CPanel is not intuitive although you get used to the tools you use often.

The first thing I needed to do, since I run my own WordPress site, was to create a space where I wouldn’t overwrite my own WordPress content. Under CPanel, I went to Domains and added the foundation’s primary domain name. I unchecked the box that said Share Document Root and CPanel created a new folder for the site.

A screenshot of the Domains tool within CPanel, showing a form to receive the domain name and to configure a document root separate from the main website public_html folder.
A screenshot of the Domains tool on the CPanel web hosting portal

By default, the only public-facing website content on my site (and probably most others) is contained in a folder called public_html. That’s where my WordPress site is. If I install a second copy of WordPress, I need to do it by avoiding overwriting my primary site. This process allows me to create a new public-facing folder with a separate domain name. The folder uses the new domain name and is created outside of the public_html folder, at the root of your website host’s folder structure.

You don’t have to do it this way. My WordPress website is configured as a multi-site or WordPress network so I can run many WordPress sites within a single copy of WordPress. Each site can have its own domain name, plugins, look and feel, and has its own WordPress tables in your database. I have often thought this would be a great tool for state-wide law library consortia, to enable small law libraries with part-time or solo law librarians to have well-managed, centrally hosted websites without having to worry about technical overhead and costs. I once taught a WordPress class to law librarians with this in mind.

While WordPress multi-site is an option, I did not want to merge the foundation website with my personal website. Some plugins only run in non-multi-site environments. Also, there’s the potential complications of running a work site with private resources: what happens to the site if I’m hit by a bus? For a variety of reasons, it seemed smarter to keep the site on its own instance of WordPress since (a) that is where it was migrating from and (b) that’s where it would be migrating to.

Once you’ve configured a domain, you can configure the Let’s Encrypt certificates (look under SSL/TLS Status on the CPanel dashboard) and install WordPress. When you install a new version of WordPress, CPanel offers an option but your web host may have a variety of ways to install it. My host has a WordPress Manager as well as the default Softaculous Apps Installer, so you may want to poke around to see which is the more efficient option. If you install it one way, you may limit your access to tools. For example, you can install WordPress manually but if you do, Softaculous and the WordPress Manager may not realize it’s there and so you will not be able to use their administrative functionality.

If you do not have a WordPress site, this is all streamlined. Take the defaults and the installer will take care of the rest. If you do have an existing site you need to make sure to choose the new domain you’ve just created. Once WordPress is installed, you may have a temporary URL or IP address to use to get to the Administrative interface.

Since I had a fresh installation of WordPress, I used my FTP software to upload the wp-content files that were unique to this site. If you have a temporary URL, you can then log in and perform the basic maintenance:

  • import your WordPress export file from the original site;
  • re-apply your theme. In my case, it remembered my custom CSS code but you may want to back that up if you have a lot and it’s within the WordPress customizer. I generally create a WordPress page set to private and keep a copy of the CSS in there so that it gets exported with all of the other content;
  • if you are uploading images, they will be disconnected from your Media Library. Use a free plugin like Media Sync to reimport them into the Media Library. The plugin just scans the files and folders on your site and creates new database records to represent the images. In my case, this immediately fixed all missing images;
  • re-activate any plugins and deactivate unused plugins installed with the default installation. In my case, there was a shortcode used by a plugin that didn’t re-activate, so I had to go into the plugin, re-create the shortcode information (Constant Contact newsletter subscription form) so that I could put the shortcode on the right page;
  • remove any installation content. There is usually a default post, default page, and default comment created.
  • Go through the WordPress Settings menu to rename the website and re-set any home pages or other features. None of these are carried over (so far in my experience).

All in all, not too shabby. A couple of hours work. If you have a temporary URL to use, you can now see if the website looks right. Either way, I could now go to Cloudflare and point the domains to the new website server. Since Cloudflare handles the DNS, as soon as I switched the server IP address, traffic immediately forwarded to the new website.

Step Two: Final Resting Place

By this time, I had researched alternatives and realized how small a website I was having to move. It became a simple decision to repeat the process above but with our law library’s website host. Check your hosting plan but once you move past the starter web hosting plan, you often have access to unlimited sites and domains. That was our situation.

The process is the same so I won’t repeat it. The big difference was that Siteground, the host to which I was migrating, has moved off CPanel. I used to be a personal Siteground customer and, since then, they have created their own application and dashboard. It’s pretty slick, especially if (like me) you didn’t need all the tools that CPanel offered.

 A screenshot showing the Add New Website function on Siteground's web hosting dashboard.  The button on the left under Start New Website is highlighted in a circle.
A screenshot showing the Add New Website function on Siteground’s web hosting dashboard.

One thing I was excited about was the Migrate Website option. The theory is that you can install a plugin on your original site and then connect your Siteground account to it. It will then ingest your website, eliminating the manual export and FTP steps above.

The migration tool did not work for me. While I got what appears to be a common error and attempted to troubleshoot, I had no luck. But since I had recently migrated the site successfully, I wasn’t that worried.

The biggest value to their wizard-based approach is that there was no chance for me to overwrite my current website. The Siteground Add New Website tool merges the Domain name step into the process. This was helpful because I was now installing a new website in parallel to our law library website. It would have been much more catastrophic if I accidentally wiped out the law library website (even though it is backed up).

Once you have installed WordPress on Siteground, the steps are essentially the same. Some of the tools are in different places but the interface is intuitive. I had to park a bunch of alternate domains and this was easy to find, as was the Security area to activate the Let’s Encrypt SSL certificates. A lot of options are just toggle switches, so it’s easy to see what is active and what isn’t.

A screenshot of the Siteground dashboard with the Security menu expanded on the left
A screenshot of the Siteground dashboard with the Security menu expanded on the left

There are fewer tools to see but the lack of clutter and the reorganizing of the menu items seems more intuitive. That was not my first reaction when I saw it, since I worried that some of the CPanel functionality was not just hidden but unavailable. In particular, I thought that it was much clearer how to enable website caching and to invoke Memcache (which seems to be more widely available across Siteground plans than with my current host).

Screenshot of the Memcached page under Siteground's caching menu.  There are two other greyed out tabs for Nginx caching and dynamic cache.
Screenshot of the Memcached page under Siteground’s caching menu.

All in all, the Siteground interface diminished the likelihood I was going to make a stupid and catastrophic error. And the remainder of the migration experience was just the same. You can FTP in and there’s a file manager so you can navigate the folder structure. When I looked there, I saw that it had replicated the identical folder structure (law library was under public_html and the foundation was in its own folder at the root of the web host folder structure, above and outside public_html).

I went back over to Cloudflare and flipped the switch. In this case, there had been some discontinuity with the site because I did not have a temporary URL to access the website. But the downtime was minimal (I think it was about 15 minutes) and was more look and feel than an outage. Once I could access the wp-admin dashboard, it was just a matter of completing the steps around re-applying the theme and plugins and running Media Sync.

One and done. The site can now be administered by me or other volunteers at the foundation. This includes updating the software, running administrative options like database cleaning and speed optimization (using WP Optimize), as well as creating new content and uploading and managing photos from events. I am more confident that the site is more resilient now, since it would require the law library’s own hosting to disappear for the site to go offline.