This post on cloud migration originally appeared on the SparkPost Blog and has been adapted for GrowthBits.

It’s tempting to focus your energy on technology and architecture decisions. Certainly those matter (a lot), but cloud migration also involves major changes to business processes and company culture that require buy-in across the organization.

The Great Cloud Migration

The cloud has quickly become the de facto platform for launching apps and services, in both B2B and B2C. Today’s service providers can quickly offer the necessary computing power and scalability, as well as increased flexibility and speed-to-market. But what about an existing offering that’s been around for a while? What’s the best approach for migrating it—or even multiple apps and services—to the cloud?

It’s tempting to focus your energy on technology and architecture decisions. Certainly those matter (a lot), but cloud migration also involves major changes to business processes and company culture that require buy-in across the organization. If that doesn’t happen, you could be in for a bumpy ride resulting in a half-baked product that frustrates your development team and your customers.

SparkPost’s Cloud Migration Journey

I’d like to share some of my own company’s experiences with this sort of transition that will hopefully resonate across your executive team to help your CEO, CFO, CIO and others be an active part of the cloud conversation.

SparkPost released the first beta version of our cloud-based email delivery service almost five years ago. When we launched, a handful of customers sent a few million emails a month. Now, our email API is used by tens of thousands of customers—including Pinterest, Zillow,, Intercom, and The New York Times —to send more than 20 billion emails a month.

In that time, our business made the shift from providing on-premises email infrastructure to operating as a fully cloud-based email delivery and analytics service.

I recently wrote about some of the more technical decisions we made regarding service architecture and API design (and evolution)  at DevOps.com. In this post, I thought I’d take a step back and look at some basic questions that informed our business and technology choices when moving to the cloud.

Here are four questions to ask before embarking on your cloud migration adventure:

1. Why do you want to migrate to the cloud?

“Because other companies are doing it” isn’t the best response here. “Because the rest of our company is doing it” is a better one, especially if there’s a push for a standard architecture across all of your offerings. Here are some other good reasons to consider a cloud migration:

  • You want to reduce operational overhead and the need to manage underlying infrastructure.
  • You’d like more agility and flexibility when it comes to deploying (or decommissioning) services.
  • You need elastic resource scaling because customer demand is increasing, and sometimes it really spikes.
  • You need a disaster recovery system for a data center, and the cost to implement a physical setup is daunting.
  • You want to expand into new geographic territories and the thought of setting up infrastructure in each one fills you with dread.
  • A data center lease is expiring in several months, so an opportunity has opened up.

Whatever the reason is, just make sure it’s a compelling one. You don’t want to find yourself knee-deep in a migration project only to wonder why you’re even doing it.

2. Have you considered the potential drawbacks?

I’m all-in on the cloud. But there are trade-offs—and some apps or services face extra challenges in a cloud setup. You may want to be careful of issues such as:

  • The virtual network and hardware paradigm is radically different from classic models developed in the on-premises world. Do you have expertise in-house to avoid making fundamental mistakes early on?
  • The costs of cloud infrastructure can be surprisingly high, especially if you try to simply replicate a traditional server model (“lift and shift”) rather than architecting and fine-tuning for the cloud.
  • The cost structure of the cloud can change how IT spend is recognized on your financial statements, which has implications around capitalization and amortization.
  • You store sensitive data and could face additional questions, processes, and changes to your operational tooling due to privacy laws and other regulations.

3. Are you prepared to audit your apps and services?

Before you say “yes” to a cloud migration, conduct a thorough audit of the apps and services on your list, along with any related technologies used at your company. You’ll soon discover that some migrations aren’t too complicated, while others will be heavy lifts.

Whenever possible, start by migrating the low-complexity apps and services first, which will not only give you some morale-boosting quick wins but also offer valuable lessons for the next products on the list. You may learn along the way that your high-complexity apps require more effort than they’re worth – it could even make sense to retire ones that really don’t serve a purpose anymore, or whose functionality could be covered by another app that runs on a modern platform. That’s especially likely to be true in the case of highly demanding functions that require specialized infrastructure and expertise. These use cases might be better served by a specialist provider (such as in the case of running email in the cloud).

Start by migrating the low-complexity apps and services first to give you some morale-boosting quick wins and offer valuable lessons for the next products on the list.

4. Are you prepared to make a serious cultural shift in your company?

If your apps and services have been around for a while, there’s a good chance that some teams have become entrenched in their businesses processes. Before beginning the technical migration process, make sure you plan out the cultural migration process, too.

Success in the cloud requires a move toward loosely coupled, independently scalable services that can take advantage of benefits such as auto-scaling, containerization, and serverless technology supported by your cloud provider. Moving in that direction takes a different mindset than traditional development and sysadmin roles in the on-prem world.

This is why most cloud businesses have adopted the DevOps philosophy. DevOps makes it easier to implement continuous deployment and a microservice-based architecture, both of which enable teams to work more independently and at a faster pace. Microservices increase flexibility – you can develop and deploy smaller units of functional value, with the ability to quickly roll back a release if show-stopping errors are found, without impacting other microservices in the product.

Since Making the Leap

Increased speed, agility, and flexibility are big wins for businesses that move to the cloud. When launching our email API and SMTP service in 2014, we decided not to build out our own data center and instead to build on top of Amazon Web Services (AWS). This choice has given us a lot of flexibility and enabled us to grow our service rapidly. Since we’re not splitting our focus between our core business and the details of operating a data center like redundancy, security and disaster recovery, we can keep our technical staff focused on building new features and improving the overall customer experience.

While important to recognize them, the real advantages are not in the immediate hardware cost savings. When using the cloud, you only pay for what you use and can get it as soon as you need it.  We have found this to be very useful in simplifying our capacity planning, eliminating extra purchase orders and avoiding waiting for servers to be shipped and racked.  We can use the AWS console or APIs to spin up new servers or databases in minutes, including automatically using Amazon’s autoscaling capabilities.

And we can reduce our costs even further by purchasing Reserved Instances (RI) on one- and three-year terms. For capacity we know we will need on an ongoing basis, this significantly reduces our baseline costs. We also maintain the flexibility of on-demand pricing or the use of Spot instances for when we need to spin up a new virtual server to handle peak workloads. Additionally, as we have focused more on our email analytics products we have found AWS to be a good platform for building our data lake and do large scale data crunching.

Here’s the Bottom Line.

Shifting focus from data centers to building the leading cloud email delivery and analytics service on AWS is one of the best decisions we’ve made. It greatly reduced our time to market and continues to help fuel our ongoing agility in meeting customer needs.  And while the tech challenges are a big part of that change, they’ve got to be made with a good understanding of cultural and process issues as well. Think about the questions outlined here to help you begin the cloud conversation at your company and lay the foundation for a successful migration to the cloud.