SaaS Cloud Migration: The Sticker Price
By: Drew Johnson
Tags: Gcp, IoT, Cloud

In 2019, we made a strategic decision to move from AWS to GCP as our primary cloud provider. There are many reasons why a company might choose to switch providers. For us the decision was primarily strategic. Now that we have completed the migration, we are ready to share the framework that we used to estimate migration costs — and how our estimates compared to actual costs. We hope our experience will be helpful to others who are considering a similar switch.

For context, Aeris is an IoT technology provider that delivers products as services, so we are effectively a SaaS company. (You can read more about the products we offer here: www.aeris.com). As such, our needs are different from those of companies who are considering migrating internal IT workloads. We will highlight some of those differences later in this article.

Our products have been deployed primarily to the cloud since about 2012. We had a substantial footprint in Virtual Machines (we call this Cloud 1.0) as well as Docker Containers managed by Rancher. We quickly decided against a basic “lift-and-shift” approach since we had become convinced that Cloud 2.0 was definitely becoming established as Docker Containers orchestrated by Kubernetes. We decided to incorporate the migration to Kubernetes into our cloud migration.

To plan for the migration, we established the following major work categories and costs:

Cloud Governance: This covers items such as the overall account organization, access control, behavior monitoring as well as cost monitoring, networking approach, and security approach.

Base PaaS: We have a multi-cloud strategy; however, there are many PaaS services that make sense to leverage as common elements across our products. These include SQL-based storage, object storage, load balancers, DNS, and others that we have internally approved for use.

Continuous Build/Integrate/Deploy: We have standardized on Jenkins. We needed to move Jenkins into GCP as an early precursor to moving our deployments.

Team Productivity: We tracked this as a cost and time category because we have had over 100 engineers working for many years in AWS. There is a large accumulated knowledge and productivity that is impacted by this migration.

Products: Finally, we get to the category of the actual product migrations. Here is where it is important to note again that we are a SaaS company, and have lifecycle phases of our product deployments. For example, we have at least Development, Quality, Performance, PreProduction, and Production deployments for each product.

Operations Overlap: Since we cannot have downtime, we have to run the services simultaneously in both cloud services so for a period of time we are double-paying.

Every one of the categories above deserves its own blog, but we can share that overall this set of categories proved effective. Here is a quick overview of two things we could have improved:

One item that we did not call out in our plan (but should have) was the Kubernetes migration. We had some effort overrun that would have been better estimated if we had specifically called out this item in our analysis.

Operations Overlap: The actual cost overlap was less than we anticipated. However, we had some AWS Reserved Instances that expired later than we planned. This has ended up about even.

The Team Productivity category turned out to be a really good one. We estimated a 10% impact in productivity over a six month period. We were thinking this would start relatively large at the beginning of the six months and then go down … with average being 10%. This category helped mitigate the gap for not explicitly including Kubernetes.

In the end, our migration cost was slightly above the plan but our post-migration cloud operating costs are significantly better than we had planned. We hope you have similar success!