Migrating from hosted VPS services to a Public Cloud Provider

I originally wrote this blog post for my employer, before they abandoned the blog section of their website, so ‘We’ and ‘Our’ = my Employers organisation rather than multiples of me.

At the time of writing, we have pretty much successfully migrated all of our web resources (both ours and the web resources of customers that we host) from our dedicated VPS (virtual Private Servers) instances to a couple of Public Cloud services.

Why the big move?

Did anyone ask the question, well, actually, none of our customers asked the question. But that’s because we started the conversation with them by explaining what we were going to be doing and why.

Linux

When we started hosting websites, it was initially just as a staging ground whilst testing things for ourselves or our customers. We subscribed to a VPS and our resident Linux expert built up a Debian server, Nginx, LetsEncrypt and a few other things. It worked pretty well. So well that we realised we could save our customers money (at least some of them) by offering to host their sites on devices that we controlled. It’s not that we could always undercut a hosting companies price, but the time we spent accessing that environment to perform updates etc was reduced when we controlled the environment.

We never really had any trouble with either the service provider or the hosted websites, it all ticked along just fine.

However, what we’ve seen over the last couple of years is that customers (and their customers) want more from their websites, the load on our VPS ‘boxes’ was increasing. That’s not a bad thing, if we need to increase our resource pool, we can, we just build in the new pricing into service renewals etc, as most businesses would. But it was getting complicated and ‘time-expensive’ to maintain.

Can we do it better?

Well, yes, it turns out we can. Cloud services are known to be complex when it comes to pricing. Initially it seems cheap, but then you look under the hood and there’s more and more complexity, in terms of both service offerings and pricing.

We always felt that we could deliver everything we needed with our VPS instances, but as more customers leaned on us, we needed more and more. So we decided to look closer at cloud providers. The main benefit for us was to remove the underlying server admin activities because it’s not really a service we offer directly, therefore it has little benefit to our business as a whole if we’re using resources to do something we don’t directly benefit from. Indirectly, of course, we benefit from customers wanting to host websites with us, so we don’t mind keeping our people sharp when it comes to web technologies. The underlying Linux boxes are pretty much rock solid, but the time we spend keeping them up-to-date, administering users, etc, is time that our team isn’t delivering directly to the customer.

Continuous Integration

Another thing we were looking for from our hosting partner was continuous integration for both us and our customers, allowing updates to webpages to be pushed out as soon as the customer was ready, not as soon as we were ready which didn’t always line up if a customer had a sudden need or desire to push a change out to their site and couldn’t manage it themselves. The new hosting platform is a little simpler to get updates into the wild than the previous VPS instances.

How did we do it?

Initially we had an all-hands call back in February 2023 to discuss the migration. We’d already identified a potential new host as we’ve found a few customers that have existing web resources and we were just helping them with some new features or so. This all-hands call was essentially our project kick-off session. We flagged risks, things that we knew would cause us issues and came up with a high-level strategy for how we’d deal with those.

One problem we already knew was that our preferred new host didn’t like PHP sites, which meant we should target any existing PHP sites as a project in their own right.

We identified a number of high-level activites, assigned owners and due dates and threw everything onto an AirTable project planner.

Our most pressing task was to reach out to all of our customers and explain what we were doing and the timelines involved. We had 3 sites that were PHP sites, nothing that couldn’t be replicated in React, but more of a legacy thing. We targetted those customers with an offer of a free re-write (creating like-for-like, anything extra would be billed at our agreed rates).

PHP or React

Of those 3, 1 settled for a simple HTML re-write, there really wasn’t anything interesting about that site (in that they didn’t need anything more than HTML, CSS, JavaScript), we simply migrated their legacy site to our VPS as a part of another service we had previously offered some time in the past. So this first PHP site was an easy fix.

The 2nd and 3rd were more complicated, but it turns out that the second had already been working on a redesign (currently at design stage) anyway and will not look anything like it’s current self, for that site we have agreed to migrate it to another VPS and maintain it until the customer is ready to move beyond a design and into a build at which point we will offer our services if required.

The 3rd PHP site was again, a victim of legacy, however it was more interactive than the first and they took us up on our offer of working with them on a re-build using React.

The crash-test-dummy

We chose our site as the first for migration to the new host. We ensured our git repo was up-to-date and pushed the main branch through to the new host whilst keeping our DNS records pointed firmly at the old host.

That test couldn’t have been more successful. Everything worked right off the bat. Continuous Integration allows for new pages (or blog posts) to be pushed directly from our terminal through to our git repo and then from the repo to the hosting service.

Time for DNS

We promptly updated our DNS records to point to the new host and retired our old website from the VPS.

Customer Resources

We followed our own tests with rapid deployment of customer websites, initially the HTML/CSS/JS sites and then any React sites. Again using a dummy DNS entry for testing and sign-off by the customer, followed quickly by an updated DNS entry and the retirement of the original from our VPS service.

Those pesky PHP sites?

• Number 1 = rebuilt in raw HTML/CSS/JS and migrated to a new home
• Number 2 = temporarily hosted on another VPS awaiting customer redesign
• Number 3 = completely re-written and re-imagined as a React website (and deployed to new home)

What did we learn?

• Always keep the customer updated
• Plan well in advance (it gives everyone time to wriggle)
• Offer a sweetner - we offered to rebuild legacy sites at our own cost
• Test, test, test.