Introduction

SAP PI/PO to SAP BTP Integration Suite (SAP CPI) migration is an inevitable process that most of the existing SAP customers will face in coming years as the sunset of SAP Process Orchestration is already announced to happen in 2027. This article is meant for those who will be responsible for planning and executing this endeavor in their organizations. Let’s see what options there on the table are.

Considerations

When you are tasked with overseeing the SAP BTP Integration Suite (SAP CPI) migration process, your ultimate goal is to guarantee a smooth and swift transition without causing any disruptions to the business operations.

• Firstly, a smooth and swift migration is essential because any hiccups or delays in the process can lead to increased costs. These costs can accumulate rapidly, encompassing not only the direct expenses associated with the migration itself but also the indirect costs stemming from business downtime, additional resources required to rectify issues, and potential loss of revenue during the transition period.
• Secondly, when disruptions to daily business activities occur, accurately forecasting the associated costs becomes even more challenging. Unforeseen problems can lead to a cascade of issues, making it difficult to estimate the extent of the financial impact and potentially causing budget overruns.

Let’s see now what you would have to take into consideration:

• Who is going to do that? – you can do it either with your internal team (they may need upskilling) or have some System Integrator (SI) do it for you. Whatever is the answer you will need someone trusted to do the job.
• How to secure quality? – migrations have a million places where things could go wrong: mappings, technological limitations, connectivity, system availability, human factors etc. This makes even more pressure on good development team. You can leave it up to the SI, but will you be able to rely on it, as accountability is yours?
• How long will it last? – this will depend on many factors, but probably quite some time. Lot of things to consider: the migration itself, availability of 3^rd party systems, availability of your functional/business team for testing and verification.
• How much will it cost? – again, many pieces must fall into their place. The best answer is probably: hard to say. If you choose to go with the SI it will probably the biggest part, but this is definitely not the ultimate cost.

This is a kind of project where there is not much to gain (from business continuity standpoint), but a lot to lose (from the same standpoint).

Classical approach

I’m not sure if there is anything classical about this approach, but for the lack of better word I will leave it like that. Classical should be understood as handling the project like any other IT driven project. The task is set, so let’s see how it can be tackled:

• Assemble the delivery team – you’d need the best resources possible. If that should be outsourced, then the price will go along with the quality.
• Secure the systems – not only you’d need environment to execute the migration, but also, you’d need to connect it to 3^rd party systems to make sure it mimics the real world.
• Secure 3^rd party staff – you’d need external staff members to help you to verify the migration.
• Secure functional/business team – you’d need business team to reassure that after the migration your business is running as smooth as before. You’d need the during various stages (some testing data would be useful) and for the final sign off.
• You’d divide your set of interfaces into manageable pieces and will take off.

What challenges you may have to face?

If you have decided to go with Classical Approach you may face some challenges. Let’s review some of those:

• Costs are hard to estimate – the ultimate cost is not only the cost of migration itself. There is also the cost of 3^rd party systems and staff, the cost of your business/functional team (usually much higher that regular IT staff), the cost of dual maintenance, the cost of license.
• The better the development team the more it costs. There are tools for automatic migration, but let’s be honest, they will not cover whole migration. Moreover, you will either have to learn how to use those or purchase them on the market.
• Your 3^rd parties may not have non-productive systems you may use or staff available exactly when you’d need them – quite common situation.
• Your internal functional/business team is not as available as you may need, which may lead to delays and consequently to the project’s total cost increase.

How are others performing?

There is a Gartner report that I want to quote here. It’s “How to Successfully Migrate to a New Integration Platform”, Abhishek Singh, October 1, 2021. There are two clause that are the essence of this article.

“Lift-and-shift migrations, or the use of automated migration tools, fail to capitalize on the rich functionalities and opportunities of a new integration platform.”

“Testing is a substantial part of the migration effort and it consumes somewhere around 60% to 65% of the overall migration effort.”

No doubt, that those very conveniently fit the challenges we have already enumerated. Is there another way to unblock your integration platform from things that can drag you down?

How to tackle SAP CPI migration differently?

What if you could tackle the migration from the different angle, while maintain the considerations from the first part of the article, but also the Gartner’s report outcomes. Let’s introduce two new components and see how those change our perspective:

• Automate verification – let’s assume that there is the tool that could promptly and automatically verify the migration results (legacy vs. new environment) for large amount of trusted test data.
• Isolate the integration platform – let’s assume that there is the tool that could isolate the integration platform/middleware (the only piece that is subject to change) from any other internal or external systems.

What would be the benefits?

1. Shift the focus to verification rather than the development – you will not need to seek for the most expensive resources, as there is easy, fast and reliable way to verify the end state.
2. Cut the dependency from your connected 3^rd party systems – essentially, we can cross the out of the equation (except of connectivity there nothing left to do here). We wouldn’t need their systems nor their staff to run our project.
3. Quality guarantee – you can leave the quality of migration verification entirely in your hands. Post go-live reality won’t surprise you. It’s you who is accountable after all, so this would be highly advisable.
4. Functional/business team involvement is brought to minimum level possible or zero. In some industries business final sign off is a must.
5. Costs are manageable, as there are less pieces on the table.

Doesn’t it look appealing? Isn’t it a brilliant move?

Where is the catch?

There is no catch, but rather there are two questions left to ask:

• What tool could be used?
• Does the cost of the tool exceed the cost of running the migration to SAP BTP Integration Suite (SAP CPI) in Classical way?

The answer to the first one could be: Int4 Shield. The second one I will leave to your consideration, as no one knows your context better than you. In my humble opinion the limit is somewhere around 40-50 API or more.

More information

1. Get the Solution from SAP Store.
2. Similar blogs: Automate over 65% of your SAP Integration Suite migration!

Please share your feedback or thoughts in the comments.

Stay tuned for more content and follow my profile.