Cloud solutions have very little barrier to entry, but their barrier to exit can be considerable.

My first corporate web server, set up before the days of “the cloud” and AWS, cost my company nearly $10,000 and months of time. Not only did we have to order and pay for the entire machine, we had to wait for its delivery, configure it, run wires, and find a place on our rack for it. Then we had to pipe a dedicated T-1 link into our offices, a process that was unbearably frustrating and time consuming, not to mention costly.

And the beast in the closet spewed heat like a dragon, and it ate parts for snacks.

Yesterday, I spun up a mid-level web server in the cloud. It cost me $34, and was charged to my credit card. In return, I got a Linux login, virtual RAM, virtual storage, and all the bandwidth I can eat. The entire process, from sign-up to operational “hello, world” site took less than five minutes.

The contrast is astounding. Earlier me, who had to come up with the cash for full machine purchases and dedicated broadband installation, would have loved to have had access to the cloud-based services we have today.

In many ways, the cloud is incredibly empowering. Breathless stories (and even HBO TV shows) highlight the nimbleness of modern-day tech entrepreneurs, who simply need a Kanban board, a credit card, coding skills, and a barrel of snark to create the next Pied Piper or Hooli.

But what very few “gee wow” cloud stories discuss is the lock-in that comes from adopting cloud solutions. It might take five minutes and $34 to spin up a new server for a website, but it could take months and thousands of dollars to move that site to a new service, if that becomes necessary.

A lock-in example

Building a website is a complex process, involving many technologies and configurations, running on top of a server environment provided by a hosting provider. The switching cost is the time, effort, and dollar cost of switching to a new provider. The inability to easily switch is called lock-in.

As I originally discussed in my article on how to create a website, if you run an active website for any number of years, it is almost guaranteed that you’ll need to switch hosting providers. These are just a few of the reasons you might need to switch:

– Your provider may become unreliable, may increase prices, or may start to offer reduced quality support.
– Your site might simply outgrow the provider’s capacity.
– The hosting provider’s server software might not keep up with the security requirements of a payment processor.

You may work with one provider for three, four, five years, or more. But if you’re running a site for the long haul, it’s rare to stick with one hosting provider unless you simply have no way out. So, planning to be able to switch is useful.

Many web builders are proprietary, so if you want to switch to another service, you’ll have to rebuild your site either mostly or entirely from scratch. At the very least, there will be a ton of cutting and pasting between services.

For smaller sites, that’s not much of an issue. Rebuilding five or 10 webpages is no big deal. But if your site is 50, 100, or even thousands of pages, that’s a lot of copying and pasting (or, if you’re very lucky, exporting and importing). Think about this: If you do one blog post every weekday, you’ll have at least 261 pages by the end of a year. Content expands very quickly.

The above example sums up the concept of switching cost. Moving that 261 pages, especially if you have to either cut and paste everything or pay a service to automate it, costs both money and time. The fact is, you’re likely to decide to say, “F-it” and stick with the existing host. That’s how switching costs become lock-in.

More lock-in examples

Use of cloud-based storage services often leads to lock-in, especially if you have a lot of data in the cloud. Moving a few gigabytes from one server to another is no big thing, but if you have tens of terabytes of backed up video files, moving that is going to take months of effort.