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.
You've mentioned these "Message mappings with 20 User Defined functions" before. I'm assuming your point here is that they are hard to understand and maintain (which is true). Then it would follow that your claim is that the AI-generated replacement mapping - based on a large number of historical messages - is easier to understand and maintain. That seems a fairly bold claim. If that is indeed your claim, you could add a lot of weight to it by publishing some independently verifiable non-toy examples. I'd love to study them.
hi Morten Wittrock
First of all - thank you for the comment!
>I'm assuming your point here is that they are hard to understand and maintain (which is true).
yes, here you need to think about not your message mappings but the ones in general, written by consultants who don't understand contexts to well, do lookups per each line, etc. - so the standard ones - this is something we can fix I believe
>That seems a fairly bold claim. If that is indeed your claim, you could add a lot of weight to it by publishing some independently verifiable non-toy examples.
the claim - don't do lift and shift is 100% true - it will be pretty hard to justify those - we need some - enhanced lift and shift - hence the idea - we can call it Blue lift and shift or whatever but it must mean we do something more than just bring garbage to the new "house"
As for the implementation of the AI enhanced migration - this is still a vision of course as we don't have any real examples of that yet but since the majority of SAP IS migration wave has not yet started and the pace of generative AI move right now I'm trying to bring some vision to the community (with the Disclaimer) so we can start innovating to enable those with more added value.
If we inverse that a bit and ask how to fail a big SAP IS migration wave - I'd say it's fair to say: do it manually with lift and shift only (so apply brownfield approach to S/4HANA).
You wrote: "As for the implementation of the AI enhanced migration - this is still a vision of course as we don't have any real examples of that yet"
You probably need to make that a lot more clear - in the above and elsewhere.
Have a nice weekend,
Hi Morten Wittrock
Thank you, this is why I have a disclaimer section in the blog 🙂
Is Blue lift and Shift a product from SAP or int4. Sorry bit out of touch with recent proceedings in SAP world, slowly crawling back to gain some knowledge and start implementing 😉
hi Nitin Deshpande,
It's Int4 concept 🙂