Lift&Shift VS Refactoring
The Cloud is less and less an option and more and more a necessity for companies that want to innovate business, but with respect to the way in which the migration of the application park to the cloud must take place, the dilemma of choosing between Lift&Shift and Refactoring approaches.
What should be done today? Do we need to bring the applications to the Cloud and then subject them to a gradual process of modification to make the structure coincide with the new distribution and functional logics, as envisaged by Lift & shift? Or, following the logic of Refactoring, is it better to rewrite them from scratch, without changing their interface, functionality and behavior to immediately adapt them to the "as-a-service" mode? Each of the two approaches, as always happens in this kind of comparison, has its pros and cons: it is up to the CIO and CTO of each company to understand which of the two best suits the needs of the organization and the business. Let's see in detail how the methodologies work and let's try to clarify the choice that, case by case, should be made.
Lift & Shift, because the approach is no longer popular
As mentioned, the Lift&Shift strategy consists of moving an application or operation from one environment to another without the need to redesign the code or interrupt workflows. We will then make minor changes to resolve any inefficiencies. At the dawn of Cloud computing, the Lift&Shift approach was the one that was the most popular, making it simpler, less impactful for business productivity and, in most cases, even cheaper. The problem is that, proceeding in this way, over time there is a risk of serious episodes of software incompatibility - especially custom and legacy ones - with the Cloud functions. The increasingly massive diffusion of the Cloud has done nothing but emphasize this criticality, highlighting system inefficiencies that have ended up frustrating investments. However, it should be noted that standard market applications have often been at the center of Lift&Shift operations which have proved to be real successes. As you may have already guessed, the degree of complexity of an application is the key factor to keep in mind when deciding whether a software, to express its maximum potential in the Cloud, should be redesigned from scratch or not.
Refactoring? It is often simply unavoidable
Net of this distinction, today generally the Lift&Shift approach tends to have more disadvantages (read: costs) than those that are likely to face by resorting to Refactoring. Also because it often happens that a mission critical software brought to Cloud in Lift&Shift mode then arrives at a dead end due to too much discrepancy with the rest of the application park or for requirements not supported by the new environment, forcing the company to redesign it ex novo.
Refactoring may also become necessary when, despite the upgrades made, the performance of the application brought to the Cloud via Lift&Shift does not meet the expectations of administrators and users. An application that has been moved to the Cloud can also benefit from Refactoring when the costs related to the consumption of IT resources are higher than expected, or when cyber security vulnerabilities arise: once again because the application fails to integrate with the security systems natively present in managed services, starting with identity and access management tools.
In general, therefore, in the presence of legacy and custom applications, a Lift&Shift project started without careful study of the documentation relating to the software requirements can easily go wrong, while the Refactoring action offers greater guarantees with respect to the levels of reliability and performance not only of the applications in question, but of the entire IT ecosystem of the company.
