Migrating to the cloud is a complex process, that must be customized to address the technical, functional and operational needs of the organization. A successful migration strategy should address short-term aims, like decreasing hosting costs, as well as longer-term goals like better alignment between IT and business objectives. Here are the three main cloud migration strategies businesses use to meet those goals.
Lift and Shift migrations move compute from on-premise to the cloud. Source & Target can be on-premise, private or public cloud.
A lift-and-shift migration is exactly what it sounds like: lifting an application or landscape out of its current hosting environment and shifting it to another environment — for example, from on-premise hosting to a public cloud. Lift-and-shift migrations transport an exact copy of the top three layers: application, database and OS layer. Gartner refers to this as rehosting, because it involves moving your stack to a new host without making extensive changes. This enables a rapid, cost-effective migration, minimal disruption and quick ROI.
A lift and shift from on-premise to cloud hosting also increases agility, simplifying future transformation. This makes it a good first step for businesses with a conservative culture, or indecision about long-term cloud strategy. However, as Gartner points out, the lack of modification to your system also prevents you from harnessing certain cloud migration benefits in the short term:
“The primary advantage of IaaS — that teams can migrate systems quickly, without modifying their architecture — can be its primary disadvantage as benefits from the cloud characteristics of the infrastructure, such as scalability, will be missed”.
Companies need to weigh the quick payoff and low disruption of a lift and shift against the greater benefits of a more transformative cloud migration strategy.
Replatforming is really a variation of lift and shift, involving some further adjustments to improve your landscape in some way. In fact AWS General Manager Stephen Orban refers to replatforming as “lift-tinker-and-shift.” Replatforming empowers businesses to accomplishing important goals beyond rehosting without greatly expanding the scope of the project:
“Here you might make a few cloud (or other) optimizations in order to achieve some tangible benefit, but you aren’t otherwise changing the core architecture of the application. You may be looking to reduce the amount of time you spend managing database instances by migrating to a database-as-a-service platform… or a fully managed platform.”
For SAP users, replatforming can be a useful step for accomplishing particular goals like increasing system performance or adopting a managed services. For example, it can enable SAP ECC users in conservative organizations to audition a vendor and alleviate skepticism about digital transformation, while laying the groundwork for a future HANA migration.
Strategy #2: Technical Migration
Technical (SAP HANA) Migration: Source and Target can be on-premise, private or public cloud.
Technical migration maintains existing applications, but upgrades the OS and DB to meet certain transformational goals. As a cloud migration strategy, this is often done in part to harness cloud native features such as scalability or automation, but it also has other benefits. For example, migrating from on-premise SAP ECC to Suite on HANA in the public cloud gives organizations the benefit from HANA’s real-time visibility and dramatically increased performance, in addition to the benefits of the public cloud.
A technical migration can also prepare organizations for a future application migration. In the case of SAP, ECC users often migrate to Suite on HANA as a first step on the road to S/4HANA. This enables the organization to minimize disruption and gain experience in the cloud, which they can use to plan the next stage of their transformation.
Strategy #3: Application Migration
Application (S/4HANA) Migration: Source & Target can be on-premise, private or public cloud
In an application migration, the application layer is transformed, along with the OS and DB. There are three basic strategies for application migration: new system implementation, system conversion and landscape transformation.
New System Implementation
New system implementation essentially means starting over. Although data is generally preserved and transferred in this process, the applications are either rebuilt from scratch by developers, or replaced with new, off-the-shelf applications.
Needless to say, this can be a complicated process. The organization needs to ensure that all functionality is replicated by the new system, along with business process flow. Old data must be audited, discarded where appropriate and reformatted to work with the new system. On top of that, there’s the requirement to retrain the team in a new suite of applications, which might function quite differently from the previous application stack.
However, in some scenarios this cloud migration strategy is the most cost effective choice. For example, if an organization is upgrading from a highly customized legacy landscape with poor documentation, auditing the code and designing an upgrade and migration path might be more costly and time-consuming than rebuilding the landscape.
New system implementation is also the correct strategy for organizations who wish to switch to a new application stack, rather than staying with their existing vendor. As Gartner points out, the benefits of a new set of cloud-native tools often outweigh the costs of adapting to a new system — particularly for development:
“Although rebuilding requires losing the familiarity of existing code and frameworks, the advantage of rebuilding an application is access to innovative features in the provider’s platform. They improve developer productivity, such as tools that allow application templates and data models to be customized, metadata-driven engines, and communities that supply pre-built components.”
Also known as brownfield migration, a system conversion transforms your application layer, along with the DB and OS layers. The process may involve extensive changes to the way your landscape is run and managed as well as the landscape itself. Your new, upgraded system will likely have greater automation, and require different competencies than your on-premise legacy system. That may warrant a change to a managed services model, and a new approach to management emphasizing proactive planning. Properly handled, that means more consistent performance, lower cost and less downtime in the future. It can also free up your internal IT team to focus on strategic goals, rather than putting out fires.
Getting there is a complex process, however, which requires a reliable technical team. The system conversion should be planned carefully, with downtime scheduled to minimize disruption. Look for a partner who can accomplish the process with a single downtime — the shorter, the better.
Brownfield migration is the most common path for an SAP cloud migration from ECC to S/4HANA. It may be done as a second project following a technical migration to Suite on HANA, or as a single, multi-stage process.
Landscape Transformation is an SAP product and process, but it’s also a more general cloud migration strategy. A landscape transformation combines a system conversion with a significant change to the way your landscape is structured. Landscape transformation scenarios include:
Combining multiple ERP landscapes into a single system to meet the needs of a business consolidation
Splitting off segments of your data along with certain functional components for a divestiture
Upgrading and migrating multiple regional Suite on HANA landscapes into a single, global S/4HANA landscape
Landscape transformation enables you to meet business goals, technical and functional upgrade requirements with a single upgrade process. This can significantly accelerate transformation, reduce overall downtime and control costs when compared to multiple projects.
Making Your Cloud Migration Strategy a Success
Choosing a migration strategy is easy. Designing and implementing it is the challenge. Many upgrade and migration projects run into delays, cost overruns and other problems that can reduce ROI, or even disrupt your IT strategy. Protera’s FlexBridge Migration Services Platform provides SAP customers with a proven, cost-effective path to the cloud, accelerating migration by 70% — and eliminating the risks of cloud migration.
As President and Chief Technology Officer for Protera, Patrick Osterhaus is responsible for driving the company’s technology vision for innovative enterprise computing systems delivered to our valued customers. Prior to founding Protera, Patrick worked as a Senior Technical Consultant at SAP America. As a strategic SAP thought leader, Patrick has co-authoredexecutive white papers, industry articles on various SAP topics including Cloud Computing, and is a sought-after presenter in the SAP ecosystem.
We are an SAP-certified, Microsoft Azure and Amazon Web Services (AWS) software and managed service provider offering the Protera Arion® SAP+ cloud platform, SAP+ cloud migrations, and SAP+ cloud managed services.