Cloud Migration: The myth of “lift’n’shift”

The term “Technical Debt” is normally used in Software Engineering to describe easy code instead of developing a better, more sustainable solution (see https://en.wikipedia.org/wiki/Technical_debt).

The following article is by Engelbert Epple a Lead Architect in large Cloud-Migration projects. I took this term recently to describe what enterprises currently do when moving their IT to the Cloud. Attached you will see a picture depicting this reality very easily. Of course, most enterprises recognize that operating their IT in their own data centers is no longer the most efficient way to provide IT-Solutions for their business. Hyperscalers (= AWS, Microsoft Azure, Google GCP) tell them that they will save a lot of money when just moving their complete IT to their Cloud. They offer very large discounts making this so-called “Lift-and-shift” very cost-efficient. Many CFOs see massive savings in TCO for the sometimes very old IT systems in place – in fact, “on-premises”. Also, large Software-Vendors like SAP, Oracle, or SalesForce offer their solution as SaaS (Software as a Service). The assumption: just like many Microsoft Office users, you simply use their Software to get rid of most operational tasks – e.g. patching, upgrades, and more. Of course, using Software like S/4HANA in an enterprise will fundamentally change in the next years; SAP introduced in 2021 the “RISE-with-SAP” Program, where S/4HANA, the successor of the current version SAP-ECC. It will only be available as S/4HANA Cloud, no longer on-premise, similarly to what Microsoft did with the introduction of M365 formerly Offices365.

The myth of “lift’n’shift”

Of course, Hyperscalers, as well as large Software-Vendors, would like to get workload onto their Clouds. Hyperscalers need to sell Compute and Storage Capacity while SW-Vendors want to sell more than just SW-Licenses. So, why should they be interested in “cleaning up” your IT before moving to the Cloud? They tell you a nice story about ”Let’s move your IT As-Is to the Cloud; you can clean it up later!” – but does this make sense?

Let’s calculate a simple business case:

An Enterprise has 1000 “Units” of IT. A unit is a placeholder for IT costs needed to spend that the enterprise is able to work. Let’s assume 1 unit costs 100 EUR per month. In fact, this enterprise has 100.000EUR costs per month and1.2M EUR per year. Now, a Hyperscaler offers the enterprise a massive discount – let’s guess 50%. Therefore, this enterprise will save 600.000 EUR per year when all IT has been moved to Cloud “As-Is”. However, nobody calculates the risks at this point in time to move a 20+ Year-old IT “simply” to the Cloud. Hyperscalers even finance this Cloud-Migration, so it seems all very easy. They calculate the Workload of 1000 Units for the next 3, 5, or even 10 years, each year 600k EUR.

Now let’s calculate the “old style”: Before moving to the Cloud, we reduce the “Technical Debt” massively. We clean up old pieces of Software, decommission stuff no longer needed, and check what new “Cloud native” solutions are available. We do a 3-month assessment to get a clear As-Is Situation and we allow us to develop a proper roadmap to the Cloud. We prepare a smooth migration, whereby we modernize whatever we can. In other words, we reduce the total IT Units from 1000 to 500! Of Course, the Hyperscaler will not give us a 50% discount because of fewer Workload-Units, but let’s say we will get 25% anyway. Now let’s calculate again: we decrease our costs to 600k EURper year before anything is moved to Cloud. Then we move and, after Cloud-Migration, we will pay 600k EUR - 25% = 450k EUR, less than using the “lift’n’shift” approach.

From an IT Point of view, the reduction of Technical Debt is a must-have. If you wait too long to repair your Infrastructure, the costs will be tremendous. But if you do it in time, your enterprise will stay competitive.

And do not believe that migration from any IT-Systems including the software installed to the Cloud is the same as just unplugging a Server here and turning it on in another data center. It is always a so-called Re-Deployment, which is a risk! It is like a heart transplant: the most important IT-Systems including their data are to be “transplanted”. If this operation fails, the enterprise is dead. As an Enterprise Architect, I would never take over this risk without proper mitigation.

My name is Engelbert Epple, I am Enterprise Architect Director at Capgemini Cloud Infrastructure Services in Germany. I am often Lead Architect in large Cloud-Migrations, especially SAP2Cloud.

Feel free to send me an e-mail (engelbert.epple _a_ capgemini.com) or contact me via XING for further questions.