SAP BTP Integration Suite migration: don’t do lift&shift!
Don’t do Lift and Shift for SAP BTP Integration Suite migrations!
In terms of integration platform migrations “Lift and shift”, also known as “rehosting,” is a process of migrating an exact copy of an integration platform from one integration platform to another. SAP has initiated one of the biggest moves in the integration platform migrations but sunsetting SAP Process Orchestration in 2027 but migration to SAP Integration Suite are not only happening from one direction – many SAP customers are also looking to leverage more SAP’s cloud integration platform and they want to move from other integration platforms like WebMethods, Boomi, Mulesoft, Seeburger as well.
While the purpose/decision of the move process will not be discussed in this article, the method of the move will. I will try to prove that lift and shift method, while is might be fine in some exceptions, for most of SAP customers is the worst choice and should be avoided if possible.
Why should lift and shift method be avoided?
Taking SAP Process Orchestration into SAP Integration Suite migrations do you really want move:
a) Message mappings with 20 User Defined functions – developed back in 2010 with zero information what do they do and everyone is afraid to touch this?
b) ccBPM or even BPMs – designed only because someone didn’t know how to implement a specific functionality without them?
c) RFC, SOAP, JDBC lookups inside user defined functions?
d) monolith integrations into the world of SAP Integration Suite components (SAP API Management, SAP Cloud Integration, SAP Advanced Event Mesh, etc.)?
I hope it’s just a rhetorical question – as you don’t want to do that.
What should I do then – my company does not have money for new reimplementation?
Did I say you need to reimplement something manually? Try using the Blue Lift & Shift approach! What does it mean? Blue Lift & Shift by Int4 approach (similar to SAP S/4HANA BlueField approach by SNP) means you do not continue with a simple Lift & Shift but try to use automated solutions like ChatGPT with Generative TDD to redesign the flows in order to simplify and clean them for business as usual (BAU) and make use of the new distributed architecture. Let’s compare both approaches.
a) Lift and Shift:
- migrate existing message mappings into the SAP Integration Suite – remember those with over 10-20 user defined functions? Do you want to move this mess into a new landscape?
- migrate java mappings, ABAP mappings by reimplementing them in groovy (ChatGPT will work like magic here but there are two things: ChatGPT will not validate the migration – this you can fix with Int4 Shield but it can still the same poorly written code – is that what you want?
b) Blue Lift & Shift:
- reimplement message mappings, java mappings, ABAP mappings and XSLT mappings in groovy from scratch & automatically – Automated mapping programs – Generative TDD with ChatGPT this way you will have fresh mappings in groovy (your SAP Integration Developers will love it and your BAU team will be ready to add new features on the next day after the migration if required) and they will be automatically validated as shown in the blog
- use prepackaged content when possible to eliminate custom integration flows (again with generative Test Driven Development approach)
- use the new frameworks to redesign the flows to use the rich capabilities of the SAP Integration Suite like MACH – MACH Architecture with SAP BTP and Advanced Event Mesh
What is the difference in business value of SAP Integration Suite between Lift & Shift and Blue Lift & Shift?
The main business value of using SAP Integration Suite stays in the same in both approaches: cloud infrastructure does not need to managed by your internal team and for new integration you can implement them much faster using the new features of SAP Integration Suite. Blue Lift & Shift however gives you tons of additional business value:
a) your old integration flows are easy to change (as they were rewritten automatically from scratch using the Generative TDD approach) so the BAU team is not afraid to touch them
b) the poorly written mappings (speed, etc.) are replaced = faster integration speed
c) monolith integration are broken down (like in MACH architecture) – your existing integrations are again faster, more reliable and easier to decouple
d) you can use prepackage content from SAP Integration Suite even for old integration flows (less money for fixing them in the future as the predelivered content owner will fix it
Blue Lift & Shift might give you faster integration, more reliable architecture and will cost less money to maintain compared to the standard standard Lift & Shift.
As mentioned at the beginning for some customers with relatively simple infrastructure it might still be better to go with standard Lift & Shift. Each landscape should be evaluated separately – no single method is best for everything!
Some of the functions of the Blue Lift & Shift are still in early stage of development (Generative TDD) so may not work in each type of migrations with the same level of maturity.