Moving Toward Modern - How to Get to the Cloud as a Large Software Company

Have you ever played buzzword bingo?

It’s a fun and simple game that involves a bingo card with a bunch of tech buzzwords on it. If you hear one of those buzzwords in a meeting, mark it off. First one to get a bingo wins!

If you are lucky enough to get the cloud buzzword bingo card, you’re probably going to win in the first 5 minutes of almost any meeting in a large software company. Buzzwords like “to the cloud”, “vendor lock-in”, and “lift and shift” seem to infinitely echo off meeting room walls.

For good reason.

At this point in 2020, the reasons for moving your software to the cloud should be obvious. Enhanced security, better scalability, reduced costs, and fast turnaround are all immediate benefits when you start hosting with a cloud vendor.

But I don’t need to tell you that. You’ve heard that 500 times. Probably today.

What we are going to talk about though, are specific strategies you can use as a medium to large software company to break into the cloud. You likely have a legacy application with lots of momentum that would be risky to just “put in the cloud”. So we’re going to talk about how we play this chess game.

First, let’s talk about your options.

Photo by Barth Bailey on Unsplash

Types of Cloud Migration

Before we talk about how to move into the cloud, I want to touch on the types of cloud migration. There are varying degrees of getting to the cloud that you and your company will consider. The three primary migration types are:

Lift and Shift
Cloud Build
Hot Swap

While there are likely many more variations of migrating to the cloud, they all can be rolled up in some way or another to these three. So let’s learn a little bit about them, shall we?

Lift and Shift

Also known as rehosting, the lift and shift approach to cloud migration is often the most common. This migration strategy involves taking your application servers from either on-prem or hosted in a datacenter and moving them to a cloud vendor as-is. The servers are made virtual and are hosted the exact same as they were on-prem.

While this is technically a cloud migration strategy, I tend to think it is not going to quickly progress you toward modernization. What it will do, however, is get your software hosted by a cloud vendor, and likely reduce costs on both you and your customers.

Lift and shift could be thought of as simply moving boxes. I’ve picked it up from this location and put it down in that location. Nothing changed except where the box is sitting.

As a large software company, this approach is often the least disruptive and offers the least amount of risk.

Cloud Build

On the other end of the spectrum, we have a cloud build. The start from scratch with nothing but lessons learned approach.

This method involves literally starting from nothing and using cloud services to build your application. It could involve containers, lambda functions, kubernetes, API Gateway, MongoDB, DynamoDB, or anything in-between.

The advantage to this approach is when you’re done, you have a cloud-native application. An application that that scales gracefully, takes full advantage of being in the cloud, and is actually a modern application. It is hosted by a cloud vendor, takes advantage of managed cloud services, and is secure.

Being a large software company, you will of course have to maintain your legacy software until the deprecation date, but you’ve made a significant commitment toward modernizing and realizing the benefits of the cloud.

This approach can be thought of as ripping off the band-aid. Just do it quick to get it over with.

As you might imagine, a cloud build from scratch is the most disruptive and has a significant amount of risk.

Hot Swap

Let’s say you have your application in production right now. It’s a big app, with 20+ years of development in it and maintained by dozens of developers.

As a company, you’ve committed to modernizing by a certain date, but know you can’t do a new cloud build and feel like a lift and shift isn’t enough.

What do you do?

Break your application up into small chunks and start moving them to the cloud

Does your application allow uploading and maintenance of files? Create a new cloud-native build that only handles document management. Once it’s built and in the cloud, update your application to use the new service instead of the legacy document management code. Do a hot swap.

This approach is the lego method. You build a bunch of services in the cloud that may or may not have feature parity with what you currently have, and start moving the legacy app to use those instead.

By hot swapping, you give yourself the ability to move at your own pace, and over time migrate your entire app into the cloud using cloud-native features. Win-win!

The hot swap approach can be disruptive and risky if you don’t play it right. But we’re here to talk about what you can do to mitigate the disruption and risk.

Photo by Eddy Lackmann on Unsplash

Start With One

You likely have many small development teams at your organization. Each team is responsible for a specific area, or domain, of your large application. This is great.

If you want to take a big step toward modernization, create a “guinea pig team” to figure it all out. A team to pioneer the unknown cloud space.

Create a small team of engineers and let them do R&D for a set period of time. After the set amount of time, have them use their new skills and knowledge to build the first hot swappable service.

While this team is off researching, developing, and progressing toward the cloud, the remainder of your development teams should be business as usual. Keep working toward your commitments, enhance the main app, and don’t deviate.

Continue building your application as you normally would, but keep in mind that something new is coming.

Photo by S O C I A L . C U T on Unsplash

The Inner Startup

Think of this team as a startup. Don’t put restrictions on them. Let them learn at their own pace.

A deadline is fine, but don’t add your current legacy processes on top of what they are doing. This team was assembled to learn how to modernize. In addition to the domain knowledge they are expected to learn, they are also going to learn about:

A startup is not only focused on development. It is a business. It has to deal with monitoring and support, cost forecasting, go to market strategy, technical writing and release notes, and much more.

This is your opportunity to iron out your cloud strategies with a limited scope. Have people from around the organization work with this “startup team” to nail down how things are going to operate in the future.

Don’t stress about getting it right. Things will most certainly change as you learn more. But having an initial plan in place early will allow you to iterate and improve the strategy over time. Building on your ideas will lead to a stronger, more mature process when the time comes.

If you have the resources available, the inner startup approach will yield exceptional results. Having a team dedicated to proving out best practices and cloud norms for the company will cause significantly fewer disruptions when you start branching out and having more development teams adopt them.

Photo by CHUTTERSNAP on Unsplash

Adopt and Expand

The inner startup was successful. They built a hot swappable piece of software in the cloud.

They did the research, established cloud development best practices, provided reference material on deployment strategies, gave example code in the programming language best suited for the company’s needs, and worked with the organization on cloud-related business efforts.

Now it’s time to see if it’s repeatable.

Have another team in your organization use what the startup team built. Can they get similar results with the defined processes? Remember, start small. Prove what was done can be done again with a different set of people. Use the startup team as your experts.

The second team should move faster than the startup team. Yes there will be upskilling involved, but a significant part of the discovery and research has been done. Plus, you have experts now. The startup team was on their own, but now they can provide expert advice to the rest of your development teams.

Once the second team proves it’s repeatable, move onto a third. Then a fourth. Start moving multiple teams at once. Whatever your business can allow while still being able to support the legacy software through deprecation day.

Before you know it, you have replaced your huge legacy application with a cloud-native solution. You are in the cloud. You are modern. All because you started small.

What Now?

If you haven’t already, now is the time to get your modernization plan in place. With as fast as the technology industry moves today, getting to the cloud as fast as possible is key to staying relevant.

The best time to start something new was yesterday. The second best time is today.

Figure out what your primary motivators are for getting into the cloud. Is it strictly to check off a few boxes and save some extra cash? Try a lift and shift.

Do you have money burning a hole in your pocket and love throwing caution to the wind? Try a cloud build.

Do you want to take full advantage of the cloud, but want to mitigate some of the risk of a rewrite? Try a hot swap.

It’s good to be a disruptor. But not internally. Save your disruptions for your target market, not for your development teams. Start small. Create a development team to do the dirty work and come up with a strategy for the rest of the company.

Best case, you have a clear, tried and true strategy in place to move to the cloud. Worst case, you don’t move forward, but only lost one small team’s worth of time.

It can be difficult changing direction on a giant legacy application. But if you take the start small approach and build up gradually over time, you will find success and become a player in the cloud game.