Cloud 7R

Alessandro Mirani

Defining a cloud strategy is the first step in building a modern infrastructure; we have seen in other articles what elements to consider when formulating a strategy. In this article we will look at the actual types of strategies that are adopted during a cloud migration, commonly called the 7r’s.

The 7r’s of the cloud

Below, we will look in detail at the 7r. The strategies that follow, go in order of complexity of application:

Retain, Retain: In some cases, the wisest decision may be to leave things as they are. Some applications or parts of your infrastructure could, or should, continue to function as before while remaining cost-effective and effort-efficient to maintain.

retire, retire: you can decide to decommission and retire (retire in English) apps or infrastructure that you do not think have a future or are simply useless in light of your new cloud infrastructure. Defining a migration strategy can be an ideal time to decide which obsolescent items to leave behind. In the case of files and applications, having backups of data and versions may be necessary and, therefore, become an additional cost. Take the opportunity to make a change to your infrastructure, but carefully consider the costs and risks involved.

Repurchase, buy back: this option is best in case there is a better version of a product, usually software, that you use. In that case, instead of transferring licenses and instrumentation to the cloud, you simply purchase new cloud-native (cloud-integrated) services that work by requiring minimal configuration effort.

Relocate, reposition: is simply described as lifting and shifting infrastructure. Move the infrastructure you own without applying significant changes. For example, a group of machines you own on VMware can simply be relocated to AWS without applying any changes to the infrastructure. In this way you accelerate your repositioning to cloud while not changing anything about your infrastructure. You won’t have any particular strategic advantages but you can devote time and effort to other things by taking this course.

Rehost, repurpose: This strategy involves updating an app or infrastructure by adapting it to the cloud. The changes made are merely functional in keeping the same app with the same functionality. Compared to repurposing then, which involves little or no effort from a management perspective, in rehosting, infrastructure is adapted to function in a cloud environment with the intention of benefiting from the new underlying infrastructure.

Replatform, refactor: lift, refactor and relocate (lift, tinker and shift). It pays to adopt this strategy in case you have a database or app that you do not want to change in its fundamental structure but simply want it to be maintained in a cloud environment. This way you will see all the costs of managing the physical structure and infrastructure go away. You will, however, have to apply some changes to your applications or infrastructure to make sure that they integrate better with the components that have now been moved to the cloud. The cost of this comes mainly from the testing and monitoring phases that follow the migration and that are particularly critical to this strategy.

Refactor, restructure: This solution involves taking the opportunity of migration to transform part of your infrastructure entirely. For example, you may have decided that your database initially structured to serve one purpose now needs to be deployed in a different way. The various IaaS and PaaS services offered by cloud platforms allow you to achieve the new purpose more simply but this may require an overhaul of your data structure. This strategy is the most complex and costly in terms of management, but it is also the one that takes full advantage of the potential of new cloud technology, giving you the opportunity to upgrade and adapt your infrastructure with to the latest available technologies.


You may have already guessed that a complete migration adopts a combination of these strategies. Remember that although these strategies clearly differ in complexity, none of them has a strategic or cost advantage over the others. It is up to you to decide on which structures it is worthwhile to apply one or more of the following methodologies, being clear about the opportunities and risks associated with each.

Leave a Comment