The article aims to explore the cloud migration of SAP, using the Lift and Shift approach. The scope and impact of this migration method extend beyond its apparent simplicity, encompassing both IT and business domains. ‘Lift and Shift’ is a topic woven between Cloud Adoption Strategy, Digital Transformation, and Innovation.
What moves, what changes, what not
Migration to the Cloud is an opportunity for on-prem teams, especially business teams, to know that business design and processes are not changing however environment is changing. Environment is made up of physical servers, operating system, network, storage, firewall, central IT components and tools etc. SAP’s database and application are tightly integrated with the environment.
Database moves, application is mostly recreated at target and same goes with the environment (target components differ as per chosen cloud provider – that’s a different topic).
Picture given below depicts what changes and what not.
Lift and Shift Migration in SAP
In SAP environments, one typical cloud migration strategy adopted is ‘Lift and Shift’ (called Rehosting). Generally, a large focus remains around bringing database and applications into target. Database-native and SAP-native methods are evaluated for Database and Application. This matches the lift and shift/rehosting definition & scope. However, in the migration process, environment gets changed as it must be recreated at target. It does not change business processes directly, but indirect impacts are common.
Environment Consideration
Tightly integrated environment at source, where SAP database/applications are running, is unique. Business processes running within SAP landscape, could be part of business ecosystem beyond organization boundaries (using PI or Cloud Connector or any other middleware tool). SAP is designed to keep and process data within SAP however application extension might have taken data and logic outside SAP area (i.e., cron jobs, batch processing tools, business data in mounted file systems etc.). Other peripheral tools/applications coupled with SAP, are integral part of environment. Servers, various storage types and Network setup also constitute the environment.
The complete environmental stack plays a role in application design and consumption. Many times, it evolved over years. Same complete stack with its elements needs to move with SAP. It gets transformed in the design and mapping process of target environment. This transformation is not necessarily part of lift and shift/rehosting but comes under replatforming.
In other words, the attention to environment should be part of replatforming, where As-Is is first discovered and then adopted as per To-Be (based on Cloud Provider components). This cycle is the time when a natural transformation is happening, and some cloud advantages come by default.
Environment on cloud side is different in term of design and building blocks, both. The design goes through architect lens. Most cloud providers have reference architecture which are based on best practices and robust design principles i.e., different landing zones for common platform and applications. These design patterns are mostly future-ready and the mapping from As-Is to To-Be brings digital transformation and Cloud based innovation at the front yard. This is the first sweet spot of Cloud Adoption and Innovation. This is where business and IT teams can take interest in design and building blocks at target. This all happens under the ‘Lift and Shift’ umbrella quietly. This is where ‘Lift and Shift’ word is insufficient to justify its scope and impact.
Example
Lets see an example of environment below and understand why it gets changed and how it impacts application.
Consider on-prem S/4 on HANA database with SUSE has to be move to Azure/AWS. Following are few example components which may go through transformation:
Conclusion
Referring to ‘Lift and Shift’, SAP migration should be approached with environment rebuild. Instead of merely considering it as rehosting, look at it as replatforming. This would ensure the migration process appropriately addresses the volume, opportunity, and stakeholders’ involvement.
Early awareness can trigger wholesome planning. The seemingly small migration can be linked to larger Cloud Adoption Strategy which can define various W (Why, When, Where and How much among others). These W questions and discovery of their answers would bring IT and Business team working together. Apart from cost consideration as one of the answers, the real motivators would be found in the realms of digital transformation and innovation. The initiative would get a boost in momentum.
Feedback and additional thoughts are welcome. Please follow my profile for similar content.
The postings on this site are my own and don't necessarily represent my employer's positions, strategies or opinions.
What moves, what changes, what not
Migration to the Cloud is an opportunity for on-prem teams, especially business teams, to know that business design and processes are not changing however environment is changing. Environment is made up of physical servers, operating system, network, storage, firewall, central IT components and tools etc. SAP’s database and application are tightly integrated with the environment.
Database moves, application is mostly recreated at target and same goes with the environment (target components differ as per chosen cloud provider – that’s a different topic).
Picture given below depicts what changes and what not.
what changes what not
Lift and Shift Migration in SAP
In SAP environments, one typical cloud migration strategy adopted is ‘Lift and Shift’ (called Rehosting). Generally, a large focus remains around bringing database and applications into target. Database-native and SAP-native methods are evaluated for Database and Application. This matches the lift and shift/rehosting definition & scope. However, in the migration process, environment gets changed as it must be recreated at target. It does not change business processes directly, but indirect impacts are common.
Environment Consideration
Tightly integrated environment at source, where SAP database/applications are running, is unique. Business processes running within SAP landscape, could be part of business ecosystem beyond organization boundaries (using PI or Cloud Connector or any other middleware tool). SAP is designed to keep and process data within SAP however application extension might have taken data and logic outside SAP area (i.e., cron jobs, batch processing tools, business data in mounted file systems etc.). Other peripheral tools/applications coupled with SAP, are integral part of environment. Servers, various storage types and Network setup also constitute the environment.
The complete environmental stack plays a role in application design and consumption. Many times, it evolved over years. Same complete stack with its elements needs to move with SAP. It gets transformed in the design and mapping process of target environment. This transformation is not necessarily part of lift and shift/rehosting but comes under replatforming.
In other words, the attention to environment should be part of replatforming, where As-Is is first discovered and then adopted as per To-Be (based on Cloud Provider components). This cycle is the time when a natural transformation is happening, and some cloud advantages come by default.
Environment on cloud side is different in term of design and building blocks, both. The design goes through architect lens. Most cloud providers have reference architecture which are based on best practices and robust design principles i.e., different landing zones for common platform and applications. These design patterns are mostly future-ready and the mapping from As-Is to To-Be brings digital transformation and Cloud based innovation at the front yard. This is the first sweet spot of Cloud Adoption and Innovation. This is where business and IT teams can take interest in design and building blocks at target. This all happens under the ‘Lift and Shift’ umbrella quietly. This is where ‘Lift and Shift’ word is insufficient to justify its scope and impact.
Example
Lets see an example of environment below and understand why it gets changed and how it impacts application.
Consider on-prem S/4 on HANA database with SUSE has to be move to Azure/AWS. Following are few example components which may go through transformation:
| Component | Description | Technical Impact | Business Impact |
| Database/Application Version | Source Database/Application may not be compatible with target Cloud | Upgrade would be needed impacting scope and timelines of the project | Upgrade may change how business processes/UI behave |
| High Availability | Cloud HA implementation depends on many Cloud provider specific technical components | The design would generally be changed so the maintenance/options/SLA | Application Availability may be impacted - should be positive ideally. Maintenance methods would change positively too |
| Disaster Recovery | Cloud providers have many innovative options/offerings available for DR | This should be explored in time to align with business/technical requirement | Application Availability may be impacted - should be positive ideally. Maintenance methods would change positively too |
| Network Ports | How ports are opened at on-prem and how they are opened at target would be different. Method would differ based on Cloud Provider | The change may impact many jobs, interface not to run | Related business processes may not work at all until ports are rightly opened |
| Internet facing scenarios | On-prem may have Webdispatcher/HW-Load Balancer and target may have software Load Balancer and its placement would mostly be in landing zone | Placement change, LB type and number of hops change would need right testing | Scenarios using WD/LB, should be thoroughly tested for impact and resolution |
| Storage Types | On-prem would be an stable environment tuned over years however target cloud storage may need to be tuned to get to right-sized storage | Various options at target are available and right-sized solution should be chosen from beginning | Appropriate solution and config is necessary to avoid wider performance bottlenecks. |
| Logging and Monitoring | Traditional methods of log analysis and monitoring can have alternate & innovative solutions from cloud-provider | The extractors should work seamlessly | The extractor should work seamlessly |
| Security | Irrespective of on-prem status, target may ideally enable ssl, encryption and other security hardening at db, application, os and network layer | This needs thorough analysis, planning and testing | New or changed security measures may impact functionality which was working before |
| Move to SaaS products/tools | DNS server can be replaced with DNS-services. Active Directory can be replaced with AD-services. | The setup/config may or may not have impact on name resolution, SSO etc | It would have indirect impact on application/availability |
Conclusion
Referring to ‘Lift and Shift’, SAP migration should be approached with environment rebuild. Instead of merely considering it as rehosting, look at it as replatforming. This would ensure the migration process appropriately addresses the volume, opportunity, and stakeholders’ involvement.
Early awareness can trigger wholesome planning. The seemingly small migration can be linked to larger Cloud Adoption Strategy which can define various W (Why, When, Where and How much among others). These W questions and discovery of their answers would bring IT and Business team working together. Apart from cost consideration as one of the answers, the real motivators would be found in the realms of digital transformation and innovation. The initiative would get a boost in momentum.
Feedback and additional thoughts are welcome. Please follow my profile for similar content.
The postings on this site are my own and don't necessarily represent my employer's positions, strategies or opinions.
- SAP Managed Tags:
