Migrating to the cloud: 6 strategies for future success

Let’s say you’re convinced (and rightly so!) that the future of your organization is in the cloud. How will you get there? Many roads lead to Rome, some more complex and promising than others. In this blog, I will share six strategies for getting into the cloud successfully. Which one fits your organization best?

Choosing a migration strategy strongly depends on the goals you wish to achieve. Some approaches offer you many strategic opportunities, but they are often a bit more complex to implement. Some options are relatively straightforward but come with higher costs in the long run. Therefore, be aware of the why of your migration and choose the strategy that best suits your needs.

Strategy 1: Lift & Shift

Also called rehosting, the idea is simple: you move your systems to the cloud platform with as little change as possible. You basically move your whole data center to the cloud.

Rehosting may be an attractive choice: you’re done relatively quickly, and little risk is involved. However, this strategy has a significant disadvantage: operational costs will be relatively high, especially in the long run. Furthermore, it will take some time to set up your new environment and connect your existing CI/CD solutions.

Do you need to move out of your data center sooner rather than later? This strategy might be a good fit. But beware: the clock is ticking. Once the migration is done, you need to start changing your applications and architecture for a better cloud fit. Monitor your costs meticulously, so you know which applications are good candidates for the next round of refactoring.

Another option is to do targeted lifts and shifts. There’s a good chance that a handful of older systems has to move to the cloud as well. You can move them at the end of the migration, then phase them out or replace them at a later stage.

In short: this can be a useful strategy, but use it wisely and sparingly. Lifting and shifting is a way to quickly get into the cloud, but it comes at the cost of having to do more work afterward.

Strategy 2: Replatforming

A.k.a. lift-tinker-and-shift. You’re still not changing your systems’ functionalities, but the underlying platform gets an upgrade.

Do you have a chunky database server with an expensive license running somewhere? Then this is a great option. A database-as-a-service is a considerable improvement in several ways: no more managing systems and paying for idle time.

Another example: a colossal application server running lots of deployments on expensive hardware. Setting up and maintaining clusters of those is very time consuming and complex. Moving these applications to Docker containers is certainly an attractive option in that perspective.

Beware the disadvantages, though, which mostly lie in the less visible parts. The details of the cloud’s underlying platform differ subtly from your on-prem’s. Keep the fallacies of distributed computing in mind and practice resiliency.

Not only does this strategy provide you with the chance to shift your IT spending to a radically different model, but it can also greatly improve your organization’s agility. So: lots of cloud gold, without touching your architecture. But there’s more to gain when you move towards cloud-native.

Strategy 3: Refactoring / rearchitecting

Refactoring (also called: rearchitecting) is the most far-reaching strategy in terms of architectural and applicative change, but it’s bursting with potential. By most effectively using what the cloud offers, things that were impossible on-prem are within reach when taking the rearchitecting route. Think unprecedented scalability for minimal costs and using services that would conventionally mean huge upfront material and human capital investments. Not to mention time-to-value improvements.

The impact of this strategy is mostly dependent on the current state of your system landscape. How tightly coupled are your applications? How modular is your architecture? If you’re already reasonably service-oriented, you’re halfway there. A step towards microservices — even better: serverless — is not a giant leap from there. It‘ll put you right at the cutting edge.

Fortunately, again, this isn’t an all-or-nothing strategy. It’s an excellent fit for migrating applications that exhibit cloud-native characteristics. But it is equally interesting to view rearchitecting from a business value perspective.

Suppose you could do magic and instantly accelerate your idea-to-production time. Deliver multiple times a day. With fewer bugs. Without having to compromise on security and stability. Which applications would yield the best results then? That part of your portfolio probably benefits the most from the refactoring / rearchitecting strategy.

Strategy 4: Keep

Rest assured, migrations are not all about doing buzzword bingo heavy work. Not all systems have to be migrated. Some are doing just fine in the data center. You might migrate them later on, or maybe you can switch them off entirely in the future.

During a cloud migration, you will acquire tremendous amounts of technical know-how. But a cloud migration is not a strictly technical affair. Slowly but surely, your organization will start shifting towards a new way of thinking and working (together). Sometimes, systems turn out to be not such a good fit anymore. Sure, they can last for a little while longer, but they need to go sooner or later. Bringing them to the cloud might not be worth the hassle.

Maybe you’ve just gone through a big systems upgrade project. Or have other reasons just to leave some parts be. It might be a valid option.

Strategy 5: Phase out

It’s not always clear from the get-go, or maybe you just didn’t expect it. But during a migration, you always bump into stuff that can be retired. 

For example, when we helped OHRA plan and execute their migration from their data center to the AWS cloud, they eventually switched off about 20% of their applications. That saved them a lot of migration work.

Strategy 6: Replace (with SaaS)

This one is aimed at systems that cost a lot but yield little. Replacing them with SaaS solutions is a viable strategy here. A cluster full of mail servers and file servers filled with spreadsheets might be a candidate for replacement with Office 365 or Google Workspace. Salesforce can replace a CRM system, and an on-prem content management system has plenty of SaaS alternatives.

Developing software is costly enough as it is. Save time, energy, and money to build something that sets you apart from the competition.

Which cloud migration strategy is right for your organization?

There is no such thing as a one-size-fits-all cloud migration strategy. Every organization has a different set of goals and ambitions. Pick a strategy that best fits yours. But keep this in mind: you will reap the most cloud benefits if you try to be as cloud-native as possible. The more you stick to the old data center centric model, the more you will see this reflected in your operational costs.

With the right combination of knowledge, experience, and crew, you can make your cloud migration a success story. We’d be happy to help!

Want to know more? Download our cloud migration white paper

My colleague Bert Ertman and I have written a white paper about cloud migrations. In it, we answer the following questions:

• What promises does the cloud hold? What are its pitfalls?
• Which migrationstrategies can you use? (You already know)
• Which people do you need and when?
• How do you plan a cloud migration?
• When can you start with the first migrations?
• How do you gain migration velocity?
• When and how can you complete a migration successfully?
• What’s next?

[related_post id=”23949″ name=”Whitepaper Cloud migratie EN” cta=”Related post”]