You are exploring and investigating re-platforming and moving to the cloud. This is a positive step to help you de-risk infrastructure, reach more scalability, enhance performance, improve security risk profile, gain execution efficiencies, improve disaster recovery capabilities, and save cost with cloud elasticity converting Capex to Opex.
A well-thought-out business-centric strategy is key to successful cloud migration. Regardless of which approach is selected, the journey is similar, starting with a healthy assessment and understanding to kick-start the migration. The steps in the diagram below increase the odds of success.
Migration Strategies
There are six different strategies, approaches, and a few choices an organization would need to make before migrating from on-premise to the cloud. The top three include migration and are situationally dependent on the business strategy and goals.
Refactor / Rebuild / Go Cloud Native / PaaS
RePlatform / Revise / Lift and Shape / PaaS
Rehost / Lift and Shift / IaaS
RePurchase / Replace / Acquire / Drop and Shop / SaaS
Retain - No Cloud
Retire - No Cloud
Below is a high-level summary of the three cloud migration paths before the depth comparison.
Refactor / Rebuild / Go Cloud Native / PaaS
Simply discarding legacy applications or components and developing them from scratch using native cloud services and features for both code and architecture. Naturally, cloud services offer speed advantages to rebuilding a PaaS-based system with full Cloud computing benefits and cost savings, and the elasticity of a pay-as-you-go model.
This approach is not suitable for every organization or every product. It requires extensive planning, re-evaluating feature priorities, time, investment, and an expert cloud skillset acquisition (e.g., Oracle to Aurora or PostgreSQL). It is the most expensive and time-consuming option but provides full benefits from the cloud.
Assuming the organizational know-how and practices are in place, this solution will provide the most scalability and resilience and allows for quick future releases and time to market. Being cloud-native also gives a multi-cloud option (not being locked to one vendor).
RePlatform / Revise / Lift and Shape / PaaS
The RePlatform approach is about carving out and reevaluating some components in the platform and deciding to partially and incrementally migrate (e.g., Database to RDS) to gain Cloud benefits. It can also be a very valuable strategy when trying to save costs from vendor-locked-in products (e.g., Oracle WebLogic to an open-source solution such as JBoss, Apache Tomcat). The system would need to be modularized sufficiently in order to be able to carve out components.
A Revise approach can be executed in two steps as a precursor to other approaches. The first step involves some existing code modifications to enable legacy support. It’s ultimately about doing some code optimizations and addressing technical debt to take full advantage of the cloud elasticity and improve potential scalability and performance. This can be followed by a rehosting or refactoring approach to deploy to the cloud. This approach works well, giving an organization additional time to prepare for maximum optimizations, especially when choosing the rehost approach.
Rehost / Lift and Shift / IaaS
Fastest and staple path to the cloud for large migrations (~40% of all migrations by Forrester). It entails copying and deploying applications and data in a cloud infrastructure directly. It entails configurations and rarely involves code changes. It is an affordable solution for cost savings with CAPEX to OPEX conversion and some cloud benefits.
The full cost savings of elasticity in the cloud may not be realized, and scalability can be a concern for stateful applications. The Lift and Shift migration event will not generate the desired total cost of ownership reduction and return on investment without additional optimizations and continuous improvements. A business is expected to acquire up to 30-40% savings on costs within 12-18 months after migrations and optimizations while gaining cloud experience. However, it is also noted that more spending is expected in the initial six months after the migration.
One common concern is that the scalability of the cloud deployment would need to be thoroughly tested for performance and scalability. Architecture may be designed in a way that does not take advantage of the target infrastructure and therefore, the scalability and performance can be degraded or consume extensive resources defeating the purpose.
A hybrid approach is to combine both the revise and rehost together. It entails partially addressing some technical debt and wrapping some of the legacy application functionality through a set of modern APIs. This optimization makes it suitable for the new ecosystem of modern cloud service and allows for building services around it in the future. While this is a hybrid cloud solution, it can provide benefits.
RePurchase / Replace / Acquire / Drop and Shop / SaaS
This is suitable for tech-enabled businesses or proprietary line-of-business tools that do not core to the business. It entails replacing the application with an off-the-shelf (e.g., CRM).
It provides a focus on the core business, cost savings, richer features, and automation. However, it may initially limit productivity due to change or ability to customize or configure, which would require a change to the business process.
In other circumstances where the legacy is core to the business, it can be an option to acquire a replacement modern platform as an add-on with a targeted future replacement.
Retain - No Cloud
This is the option with a deliberate decision not to migrate to the cloud due to limited business benefits, a negative return, or a very limited return on investment.
Examples can include a proprietary line of business application where the cloud benefits may not be sufficient or other alternatives exist to manage the application and data with a reduced cost.
Other situations may include a high sunk-in cost, high costs of re-training personnel, and dependency on a legacy operating system that is not supported in the cloud, which would dictate a status quo.
Retire - No Cloud
At times, the answer is to retire and get to end-of-life. Some legacy applications may not be providing enough value, return on investment and provide features that are no longer useful in a fast-changing ecosystem while continuing to incur costs.
A decision can be taken to evaluate the overall existing value and replace that with a combination of off-the-shelf or developing a new modern application that can provide the desired value. An example of this would be a CRM tool that was built in the 1990s when there were no alternatives, and a business created its own. Evaluating the benefits, the use cases, and the data needs are essential for helping with this decision.
What about Automated Code Conversion?
Converting or translating the code might help in some situations (e.g., a single component that requires specific talent). It’s mostly targeted at translating procedural (e.g., COBOL) languages to object-oriented Java or C#. Generally, it’s less about the language itself and is rarely used as a blanket strategy to transform a large migration. Old code and algorithms are often very low-level, verbose, with proprietary idioms, and cannot leverage modern libraries.
Code translation likely reduces existing proven product quality and can introduce new issues requiring massive refactoring. A piece of code that has 1M lines of code written 20 years ago can be replaced with a modern counterpart of only 5-10% in a modern language. The readability of the output is difficult for consumption by developers. In our experience, code translation is limited to very specific situations, like producing compilable code rather than readable code.
Definitions
Infrastructure as a Service (IaaS) / aka hypervisor as a service: The cloud provider handles all hardware and provides that as a service for rent. The client creates, configures, and resizes as needed.
Platform as a Service (PaaS): The vendor provides a platform for creating and delivering software. The client developers simply work on the core product without concern about operating system updates, patches, and load balancing. It is the basis for Serverless deployment where the server management and capacity are not in scope for the client and are fully managed by the vendor.
Software as a Service (SaaS): The software is hosted and provided as a service (e.g., Salesforce, Office 365, GSuite, Dropbox). The clients simply use the services as is.
About the Author
Hazem has been in the software and M&A industry for more than 26 years. As a managing partner at RingStone, he works with private equity firms globally in an advisory capacity. Before RingStone, Hazem built and managed a global consultancy, coached high-profile executives, and conducted technical due diligence in hundreds of deals and transformation strategies. He spent 18 years at Microsoft in software development, incubations, M&A, and cross-company transformation initiatives. Before Microsoft, Hazem built several businesses with successful exits, namely in e-commerce, software, hospitality, and manufacturing. A multidisciplinary background in computer engineering, biological sciences, and business with a career spanning a global stage in the US, UK, and broadly across Europe, Russia, and Africa. He is a sought-after public speaker and mentor in software, M&A, innovation, and transformations. Contact Hazem at hazem@ringstonetech.com.