A Process for Mass Migrations to the Cloud

“We cannot and should not stop people from migration. We have to give them a better life at home. Migration is a process not a problem.” -William Swing

This post outlines a 5-phase “Migration Process” that I hope will help executives who are considering a mass migration to the cloud. You’re reading part two of a three-part series. The first post in this series introduces the concept of a mass migration, which we’ll simply refer to as “migration” throughout the series, and the third post of the series describes the 6 strategies for migrating applications to the cloud. While each of these posts stands on its own, I believe they go better together.

The “Migration Process” combines what we (AWS) know about technology migrations and some of our experience helping organizations migrate their IT portfolios to AWS. This process — while based on experience — is intended to provide some guiding principles to help you approach your migration and not meant to prescribe hard-and-fast rules. Every organization has its own unique blend of constraints, budget issues, politics, culture, and market pressures that will guide its decision-making process along the way.

Phase 1: Opportunity Evaluation

What is the business case or compelling event that will drive your migration to the cloud?

Ideally, you’ll be building off some experience (see Getting Started with the Cloud and 4 Foundational Investments for Your Cloud Journey), and you’ll be able to use that experience to inform your business case. In the formative stages of the cloud market, migrations were often driven by instinct — an executive who felt it was the right thing to do. As the market develops and every enterprise is considering what and how to migrate, the need for business cases and/or compelling events to drive organization-wide behavior are becoming more common.

I’m sure that I’ve yet to see every possible business case or compelling event, but I do see a lot of migrations driven by data center lease expiry, additional developer productivity, global expansion, upcoming M&A activity, and/or the drive for standardized architectures.

One customer we work with, for example, has developed a business case around developer productivity. The customer (rightfully) believes that by migrating its data centers to AWS, and training its developers in the process, each of its 2,000 developers will be 50% more productive than they are today. Driven by the elimination of wait time for infrastructure provisioning and access to more than 80 services they’d otherwise have to build/procure individually, this productivity boost will lead to an additional 1,000 years of developer capacity … each year. The customer intends to use this additional productivity to fund 100 new projects of 10 people each in an effort to find net new growth opportunities. (As a former CIO, this is probably my favorite business case yet; and, if you have a strong interest in hearing about additional business cases, please send me a note and we’ll elaborate on other cases.)

Even if your organization doesn’t require a formal business case to migrate to the cloud, I think it’s important for leaders to provide clarity of purpose and set aggressive — but achievable — goals that their organizations can rally behind. I’ve seen too many migration efforts stall without this.

As you progress in your migration, you can look to hone in on the value you’re creating, how you’re communicating that value to your organization, and become more confident in your approach to procuring IT services in a pay-as-you-go as-a-service model.

Phase 2: Portfolio Discovery and Planning

What’s in your environment, what are the interdependencies, what will you migrate first, and how will you migrate it?

This is when organizations typically inspect their configuration management databases (CMDBs), institutional knowledge, and/or deploy tools (like the AWS Discovery Service and/or RISC Networks) to deeply understand what’s in their environment. Using this knowledge, organizations can outline a plan (which should be considered subject to change as they progress through their migration and learn) on how they’ll approach migrating each of the applications in their portfolio and in what order.

The complexity of migrating existing applications varies, depending on the architecture and existing licensing arrangements. If I think about the universe of applications to migrate on a spectrum of complexity, I’d put a virtualized, service-oriented architecture on the low-complexity end of the spectrum, and a monolithic mainframe at the high-complexity end of the spectrum.

I suggest starting with something on the low-complexity end of the spectrum for the obvious reason that it will be easier to complete — which will give you some immediate positive reinforcement or “quick wins” as you learn.

The complexity will also influence how you migrate. Because it’s easy to lift-and-shift a modern application hosted on a virtualized environment, and there’s typically less technical debt associated with something developed 3 years ago versus 20 years ago, we find a strong bias toward rehosting (aka “lift-and-shift”). And, because it’s simply not possible to lift-and-shift a mainframe, we also find a strong bias toward feature rationalization and re-architecting. We (AWS and APN Migration Partners) are doing everything we can to make mainframes (and other legacy systems) easier to migrate (contact me for more details), but there’s still no silver bullet.

Phase 3 and 4: Designing, Migrating, and Validating Applications

In these 2 phases, which I often refer to together as the “migration factory,” the focus of the migration moves from the portfolio level to the individual application level, and each application is designed, migrated, and validated according to one of the 6 application migration strategies described here.

I recommend taking an approach of continuous improvement. Start with the least complex application, learn how to migrate while learning more about the target platform, and build toward the more complex application migrations as your organization becomes more cloud and migration fluent.

To help scale the “migration factory” quickly, I also recommend creating agile teams focused on some type of “migration theme.” You might have a few teams dedicated to one or more of the migration strategies, to common application types (websites, Sharepoint, back-office, etc.), to different business units, or, in all likelihood, some combination thereof. Finding themes for teams to focus on will increase the chances that they learn from common patterns and accelerate the pace at which the “factory” migrates applications. Ideally, you’ve established a Cloud Center of Excellence that can advise and guide teams on their migrations and what to expect as they progress.

Finally, make sure you have a strategy for testing and decommissioning the old systems. The good news is you shouldn’t have to purchase or wait for new hardware when you’re only going to decommission the old hardware, but you may have to run parallel environments for a period of time while you migrate traffic, users, or content. To minimize this time, make sure that each business owner is involved and ready to validate the migration in real-time, and measure the difference in cost and performance as you go. Over the next few months, I hope to have some guest posts from our APN Partners that will elaborate on the tools and patterns organizations use to do this.

Phase 5: Modern Operating Model

Finally, as applications are migrated, you iterate on your new foundation, turn off old systems, and constantly iterate toward a modern operating model.

When I was at Dow Jones, we used our migration as a forcing function to adopt a DevOps culture (more on DevOps here), and many of the executives I speak to today seek a similar path toward Agile, LEAN, or some other buzzword-friendly approach to application development.

I’d encourage you to think about your operating model as an evergreen set of people, process, and technology that constantly improves as you migrate more applications. You don’t need to boil the ocean early on by trying to solve for every scenario you may or may not encounter. Ideally, you’re building off the foundational expertise you’ve developed before you created your business case. If not, use your first few application migrations to develop that foundation, and your operating model will continually improve and become more sophisticated as your migration “factory” accelerates.