Skip to main content

Transforming in flight

(Image credit: Image Credit: Melpomene / Shutterstock)

Over the past six months, cloud vendors have seen a huge increase in companies enquiring about migrating to the cloud. It’s no surprise of course, given that so many businesses have had to pivot to remote working and embrace rapid and often reactive digital transformation during the pandemic.

The question posed by many technology leaders during this time has been: how do I lead a fast-paced transition to the cloud without carrying forward too much technical debt? This question of ‘Do I transform in flight, or when I land in the cloud?’ unfortunately isn’t quite that simple. Delivering a solution that results in long-term, predictable and positive outcomes takes more careful consideration.

Cloud priorities

Covid-19 has brought many business challenges, new external market forces, rapidly changing customer buying habits, and exposed IT infrastructure inefficiencies. This has led to a ‘forced acceleration’ of digital transformation projects. Companies that had never considered migrating to the cloud before have had to do so in a short space of time to adapt to new ways of working. While many are still relatively new to cloud native technologies and techniques, it’s important to think about your business priorities and build your migration plan to accelerate it.

Seven Rs

There are generally 7 migration paths when you move your applications to the cloud. They are.

Retain: This application will remain where it is with no changes.

Retire: The application will be removed from service.

Relocate: These applications will be moved to another data center but not to the cloud.

Rehost: This is also known as “lift and shift” and these applications will be moved to the cloud but will retain the same architecture they had on premises. This is often the fastest and least disruptive but does not leverage more advanced cloud capabilities.

Replatform: This uses the same primary code base of the applications but changes the underlying architecture to take advantage of cloud scale, elasticity and cap ex economic buying models. More complicated than rehost but offers higher performance and/or lower costs.

Repurchase: These apps are migrated to a comparable SaaS version.

Refactor: Where the entire application is rewritten in an agile cloudnative format often using microservices like containers and serverless technology for faster deployments, easier upgrades and lower costs.

Using these methods there are two fundamental strategies for migrating and transforming applications to the cloud.  You can refactor and replatform your applications as you move them to the cloud or rehost them to the cloud first then refactor and replatform over time. By refactoring and replatforming during the migration you are retiring technical debt as you move to the cloud and are not bringing your old problems with you. This method requires more work, creates more change and requires participation of the entire organization to make the change happen. Although there is more work up front the benefits of the cloud are immediate.  The other method is to rehost everything to the cloud as is and then refactor and replatform the applications after they are in the cloud and over time. This method gets you to the cloud fast but does not enable your applications to take advantage of cloud services. Generally running applications in this non cloud optimized state is more expensive and less performant.

What is right for you?

Technology leaders I work with often ask what is the right methodology to use. The answer depends on what is the business driver for the migration.  As you consider migration strategies the goal is to create a migration plan that uses the right strategy for each application to maximize the business impact at the lowest possible cost and disruption.

Do you have an external deadline that is forcing you to move to the cloud, like a Data Center lease expiration or hardware refresh requirements. If so it may be beneficial to rehost most of your applications quickly to meet those external deadlines and then transform your applications over time once in the cloud. When external forces are creating the need to migrate to the cloud a rehost is usually required to meet these deadlines or requirements. Covid is an excellent example of an external force creating the need to get to the cloud to decrease the reliance on physical infrastructure managed by people. Most businesses are finding it advantageous to rehost as quickly as possible then transform to avoid scaling and maintenance issues found in private data centers.

What is imperative if you go this approach you do not move and do nothing. There is no point of moving to the cloud with the same baggage you had on premises. It most likely will not be cheaper, it will probably be slower, and it will be harder to manage. If you just rehost to the cloud quickly you are only doing half the job. In order to get the full value of the cloud you need to plan your transformation activities after rehosting to the cloud.

If your requirements are more strategic such as lowering costs and creating a faster app dev pipeline to be able to more quickly react to market conditions you would be better off transforming as many applications as possible as you move them adopting new cloud native techniques. If you’re choosing to refactor, you’ll want to change your applications to run better on the infrastructure of your cloud provider. For this to take place, you’ll need to modify your applications to better suit the new cloud environment. Choosing this approach will involve code and platform changes of the applications, in order to take advantage of the cloud-based features and the extra flexibility that you get with them. While refactoring migration can often be more complex than other cloud migration approaches, the end result is that the application runs better, more efficiently and with higher stability in the cloud than it did before the refactor.

If your existing environment is resource-intensive, like with big data processing, or image rendering, this could lead to larger than expected cloud billing if it is not replatformed correctly. To avoid this, redesigning applications for a better resource utilization will be required as you move to the cloud. This may be the most time-consuming of approaches, but it can also offer the highest performance and lowest monthly spend in comparison.

These are not all or nothing approaches, you can refactor some applications now for the greatest impact and rehost others. In reality organizations will be reluctant and unable to effectively transform every part of their environment at the same time, so technology leaders need to identify the most strategic slice they’re going to double down on and transform. Whilst in an ideal world it would be desirable to eliminate all technical debt during wide-scale migration, it is often impossible, or at best extremely targeted as constrained by the usual axioms of budget and time.

Instead, to ensure the optimal feasible balance of pace/cost/transformation in most large-scale migrations, it’s vital to find the right mix of the following approaches across the application portfolio:

Full cloud-native transformation – when an application or application set is strategic for a business, and can support transformation, a deeper investment is merited. This route often moves apps to exclusively use serverless technologies backed up by the fully automated pipelines needed to manage them.

Refactor as much as possible – evaluate the possibility of refactoring as much of an application’s underlying infrastructure as possible. This involves modifying the existing software and architecture design to take full advantage of cloud based features, flexibility and elasticity to increase agility and lower cost.  This is merited where there are applications that may not need transforming, but are core to your business.

Lift and shift – the fastest route to the cloud, and very useful if pace is the top priority, but the applications will not be cloud-aware and will still require traditional management.

The right strategy

Whether you decide to migrate to the cloud with a transform first mentality or plan to move first than transform over time is up to you and your business goals. It’s important for business leaders to work with cloud venders who understand your strategic direction and then structure your migration accordingly. This will then lead to transforming aspects of the environment and factor in the aspects depending on your business goals.

It is paramount that there is strategic direction to cloud migration. Without an effective cloud strategy, you cannot address on-premise challenges and maximize the potential value of the cloud. With a strong strategy in place, the benefits of transitioning to a new paradigm are well worth the investment.

With migration, it’s important to have a bold mission, but don’t sweat the details too much. You just have to get going to make it successful.

Dave Chapman, Head of Strategy & Professional Services, Cloudreach