A couple weeks ago, we introduced the first two steps of a framework we’re sharing with IT teams to help them work through their cloud migration.
In steps 1 and 2, we covered why creating a baseline is important for planning your migration and how creating a business case will establish the projected benefit of a cloud migration across operational, architectural, and economic axes. (See An economic framework for cloud migration, part 1.)
Now let’s talk about where the rubber meets the road. After you’ve established a business case for moving your organization to the cloud, forecasting the opportunity in cost savings and organizational leverage, the real work is just beginning.
To start getting value immediately, think about your overall cloud shift as many smaller movements. Each of these ‘mini-migrations’ will help you validate that you’re on the right path. The important thing is to get started, and learn along the way.
»Related content: Watch the AWS + Deloitte webinar "Accelerating cloud migration: from random acts of cloud to the new normal"
Let’s take a look at the next step in your migration.
Step 3: Migrating at scale
Hopefully, your completion of the business case has shown that a cloud migration is a great opportunity to drive innovation for your business while saving money at the same time. But to capitalize on that opportunity, you’ll actually need to start migrating workloads to the cloud. To migrate at scale, there are two main sub-components: Building an actionable plan for migration, and measuring the value of the migration as time goes on.
In Step 1: Pre-migration, we talked about discovering economic inflection points that can be used to find good potential targets for migration ahead of the comprehensive business case. Now that we’re ready to begin moving workloads, that roadmap and migration needs to be revisited. How do you decide which infrastructure, applications, and/or services move first? Where do they move? How do they move?
There’s no universal answer to these questions—you’ll want to evaluate your roadmap across a few different dimensions in this phase. This is a sample of the types of drivers that can affect your roadmap and overall migration plan:
- Economically driven: Equipment and facility leases, enterprise agreements, infrastructure depreciation, etc.
- Operationally driven: Software and hardware lifecycles, equipment or software instability, workload profiles (low/high risk, dev/test, etc.)
- Capabilities driven: New business requirements, technical limitations, etc.
- Opportunistically driven: Dev/test workloads, other “low-hanging fruit”
Having a system in place to see your various workloads, organized by these dimensions is critical to prioritizing your migration. And remember that those priorities are fluid. It’s not uncommon to reorganize your migration based on any number of factors and events that unfold over time.
There’s not a single ‘correct’ way to migrate workloads to the cloud. Some of your most valuable services will be factors for refactoring. This process, where an application is optimized to run on a cloud platform, offers great benefits that often result in better performance and scalability at an (often) lower price. But that agility and long-term cost savings opportunity may come at a hefty upfront cost to design and architect the new application.
Other applications (for some, most applications) will initially move to the cloud in a “lift and shift” model. These applications will essentially be re-hosted onto the cloud of your choice. These migrations are usually faster and require less upfront work. Once in the cloud, perhaps they’ll be refactored to a cloud-native architecture at a later time, or maybe they’ll run as-is until no longer needed. (Exploring various forms of cloud migration is a topic for another day, but if you’d like to read ahead you can find a great overview here: 6 Strategies for Migrating Applications to the Cloud.)
Regardless of how you prioritize your application migration or the method in which you move them to the cloud, it’s crucial that you be able to explain to business partners the value of your cloud migration. Value can mean a lot of things to a lot of people but at its core, think about how to communicate why the move to cloud is a good decision for your business. Here are a couple questions that may be key indicators of value:
- Are you actually seeing the cost savings you expected from the business case in step 2? If you forecasted a 30% cost savings, but are able to measure that you’re actually saving 34%, those additional funds can be invested in accelerating your migration; bringing on additional developers, investing in new tools, etc.
- Can you quantify the operational benefits of the cloud? By outsourcing core infrastructure roles to your cloud provider, most teams see improved application uptime. Measuring that improvement tracked over the migration of key applications is another simple way to showcase the value of the cloud for your business.
- Has the cloud helped you drive innovation into the business? This is one of the most important factors, and initially feels hard to measure. One obvious result might be that your developers can now adopt new agile development methodologies to deliver innovation built with cloud native services. You can use data from those services to track the pace of that innovation through metrics like code commits, quality, release cadence, etc. You’ll likely see that the pace of innovation for cloud-based applications is much faster than their on-premises (on-prem) brethren.
There’s a lot in this step—it’s the core of what you typically think of as a ‘cloud migration.’
However, we’re not quite finished.
Step 4: Evergreen
Unlike traditional on-prem deployments of infrastructure, legacy middleware, and classic stack-based applications, applications on the cloud enable you to continually improve the services you’re delivering by optimizing the underlying infrastructure.
In a way, this optimization is not only enabled, but encouraged. You may find that in your initial move the cloud, you over-spec’d the underlying infrastructure for an application that was lifted-and-shifted to your provider of choice. In an on-prem world, such a mistake could have lasting economic penalties. In the cloud, conditions like that are remedied by simply picking a new instance type and seeing the rate change accordingly.
That kind of optimization is more operational in nature. Other scenarios may be economically-driven. Most providers include different pricing models that reflect the kind of workloads best suited for them. For example, the AWS Reserved Instance model rewards always-on workloads with discounted pricing via upfront payment. Google’s Preemptible VMs are priced as a low-cost option for workloads that are ephemeral by nature and can be disrupted as needed.
For most teams, this step never really finishes. Workloads evolve and cloud providers continue building new and innovative services. That churn makes it important to continually iterate on the best way to deliver your services to the stakeholders in your business.
I hope that as you’ve read through this two-part series, you’ve been able to imagine how you can apply this framework to your own organization. This approach should be taken as one of many inputs into your overall cloud migration strategy. Feel free to adapt it to work for your specific situation, and let me know if this was helpful as you make your way to the cloud.
Want more? Download the white paper: Using AWS & Azure tagging to track business value of cloud spend