Basically, there are many reasons why a company wants to move on to the cloud. In addition to cost savings in the total cost of ownership (TCO) aspects such as elasticity and flexibility, but also pressure to innovate or security aspects play a crucial role. This article outlines the different migration routes to the cloud and differentiates them.

There are many ways to the Cloud

At Storm Reply, we try to pick up our customers very early in terms of their Cloud Journey. According to our claim “Making the Cloud work for you”, we are there to advise them right from the start. Classically, we offer an general assessment, which reveals the cloud potential in the respective company to the customer, but also to us. Our experts for Projects, software development and operations jointly examine the existing infrastructure with the customer and analyze the existing software landscape, in order to jointly define and implement initial projects for migration or new development. This approach is based on the AWS Cloud Adoption Framework, extending it with the experience we gathered by carrying out more than 500 Cloud projects.

The following figure is showing the so called “6Rs of Cloud Migration”. In the next sections these 6Rs are introduced and described shortly.

6Rs of Cloud Migration, Source:

Rehosting (Lift & Shift)

Virtual machines (VMs) and hardware-based servers (bare metal servers) are provided with suitable tools, such as AWS Import / Export service. Than they are exported from existing infrastructure (e.g., the customer’s data center) and rolled out to virtual machines (EC2 instances) in the Amazon cloud. An adaptation at the server sizing etc. does not take place at first. However, storage migration (such as NFS Mounts to Amazon Elastic File System) is likely, and may require minimal configuration customization to the application. Rehosting is sometimes the first meaningful step, even if the later inclusion of native cloud services is planned. On the one hand, because the difficult part – the migration of the application and data as well as the traffic – is already done, and on the other because the Lift & Shift has already gained further experience in the use of the cloud.

Replatforming (Lift & Reshape)

Replatforming, also known as “lift-tinker-and-shift” by Stephen Orban (former AWS Head of Enterprise Strategy), extends “Lift & Shift” to include some kind of infrastructure optimization (such as numbers of virtual CPUs in a VM or update to a newer operating system version). If necessary, minor adjustments to the software are necessary or a new installation in the target platform must be carried out. In this step, databases are also migrated to the Amazon Relational Database Service, if appropriate. It supports the AWS Database Migration Service, with which almost all known databases (Oracle, Microsoft SQL Server, MySQL, MariaDB, PostgreSQL) can be migrated to AWS without any significant downtime. In this context, sometimes a change of the database engine is possible in order to save license costs in the future.

Furthermore, replatforming is also understood as the move of an existing application to another platform. At Amazon, the AWS Elastic Beanstalk is the perfect choice for a “quick win”. Elastic Beanstalk handles provisioning, load balancing, and auto-scaling, as well as deployment, until status monitoring of the application, so developers do not have to worry about the underlying servers.


Shifting to the cloud does not always have to be the most sensible goal. A viable means is also the replacement of an existing application with a new product. Nowadays, this may be the change from an on-premise to a SaaS solution, or the replacement of the vendor, e.g. from Salesforce CRM to Microsoft Dynamics. If the existing standard software of a service provider does not (any more) fulfill all their needs, it may make sense to think about an individual software solution. Please get in contact with me if you are looking for building something new in and with the Cloud!

Refactoring (Decouple & Rewrite) / Rearchitecting (Replace)

This is certainly the largest effort to schedule, depending on how far the restructuring of the application should go. Under refactoring, the partial replacement of existing components (replacing certain use cases of the application with cloud services) is meant. While the complete new development of an application with cloud native services provided by the platforms is known as rearchitecting or replace. This strategy is usually flanked by the complete replacement of the original middleware and possibly a change of operating system or platform. This would then classically be the new development of a monolith to a micro-service architecture or to a serverless implementation based on AWS Lambda or the use of other meaningful cloud services.


Some data centers operate applications that are no longer used. If this turns out to be the case when performing the Cloud Readiness Check, it is an adequate means to turn it off.


Applications in this path are not pursued (often only in the first step), either because the migration simply does not make sense for the business (cost / benefit analysis), a specific computer architecture is required for operation or because regulations speak against migration ,

Retain could also be called “re-visit” or “resubmit”. Applications in this path should be rechecked regularly. The cloud is evolving so fast that sometimes a suitable service is available soon.


The migration paths outlined above provide orientation for a migration strategy. Above all, the boundaries between “Lift & Shift” and “Lift & Reshape” are not really clear. Often it can be stated, however, that initially a 1: 1 move of the existing infrastructure represents the most sensible entry. On this basis (and the already migrated data / applications) can then successively exploit the full cloud potential and save a lot of money in the area of TCO.

Feel free to contact Storm Reply through, we will help you on your Cloud Journey.