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.
Some services, like Amazon's AWS long-term Glacier service, even monetize their lock-in. While the company does charge a monthly storage fee based on how much you're storing, they don't charge anything for uploading data to the service. You can upload a gigabyte or 100 terabytes and still pay the same $0.00 transfer fee.
But data transfer above 1GB/mo out of Glacier to the rest of the internet is charged, ranging from $90 per terabyte transferred down to $50 per terabyte, depending on how much you're moving. Granted, it's not a tremendous fee for the amount of data, but it's still shows how Amazon wants to reduce the friction of uploading data, and increase the friction of moving it back out.
Another example is cloud accounting service QuickBooks Online. QuickBooks seems to regularly increase its pricing, but moving ten years of data out of QBO to some other service can be prohibitive or impossible.
For example, if you want to move a decade of QBO to FreshBooks, it's pretty much a non-starter. On the other hand, Xero offers a QBO migration service that can help you move to their competing service (with some limits), but what kind of lock-in situation are you going to wind up in there?
This brings up a corollary to the cloud lock-in theory: where there is lock-in, there is likely to be a fee-based service that will help you to overcome it.
I migrated my company's surprisingly large email store twice, first when I moved from a third-party Exchange hosting provider to Office 365, and again when I moved from Office 365 to Gmail. In both cases, I used a service called YippieMove. I sent them a few bucks and they made it all happen. Unfortunately, they shut down in 2019.
I also moved my help desk library from one provider to another using a migration service. This, too, involved paying a fee, waiting a week, and letting them do their job.
Another way of overcoming lock-in is to use open source products. I talk about this at length in my article about how to create a website guide. Many web hosts (like SquareSpace and Wix) lock you in because all your pages are constructed using their proprietary CMS.
But if you use an open source CMS like WordPress, you can move the files and database to any other WordPress-compatible host. The migration will still be time-consuming and painful, but possible.
Words of advice
When signing up for a cloud service, you're usually just trying to get a problem solved. But keep in mind that solving one problem opens up the potential for future problems -- particularly if your cloud vendor goes under, changes policies, changes prices, or just pisses you off.
It's always good to evaluate how risky the choice of vendor is, and whether the risk you're taking is an acceptable risk. Are you okay with losing the data entrusted to the cloud vendor? Are you okay with the cost and effort in migrating off? Do you have a backup plan in place?
Finally, develop strategies that will allow you to implement a migration plan relatively quickly. At least yearly, evaluate the validity of those strategies (for example, my email migration service of choice is no longer operating, so I need to find a new option).
The bottom line is this: be aware and be prepared. Cloud solutions have very little barrier to entry, but their barrier to exit can be considerable.
What cloud services do you use? Have you ever experienced lock-in or switching costs? Share with us in the comments below.
You can follow my day-to-day project updates on social media. Be sure to follow me on Twitter at @DavidGewirtz, on Facebook at Facebook.com/DavidGewirtz, on Instagram at Instagram.com/DavidGewirtz, and on YouTube at YouTube.com/DavidGewirtzTV.