Intro

Further to my previous article “Charting New Waters: Innovative Tactic to SAP BTP Integration Suite Migration” in this very article I would like to outline the practical steps and considerations necessary for migrating from lany egacy middleware platform to SAP Business Technology Platform Integration Suite (SAP BTP IS). Previously I was considering usage of service virtualization and automated validation while doing so.  This time I would like to look at the subject from a project planning and execution standpoint. What does the overall project plan look like, what kind of skills we may need and how roughly would it take. 

Early Assumptions

Let’s assume that you are tasked to plan SAP BTP Integration Suite (SAP CPI) migration process from your existing Legacy middleware platform (Legacy platform could mean SAP PI/PO or any non-SAP platforms like WebMethods, Boomi, MuleSoft etc.). Your whole IT landscape is tightly integrated to numerous Business Party systems and smooth, uninterrupted flow of business processes is fundamental to your ability to run your core business. To further challenge the task, let’s consider that your Legacy middleware has been in use for quite some time and is rather lacking in documentation. 

High Level Plan

Here’s an example of how the high-level planning might appear:

Now let’s review step-by-step each activities:

Interface Inventory

Let’s start with the inventory of all interfaces currently being in use and that are subject to migration. This should allow us further to assess resources and time needed for the project.

Classify Interfaces

Next, as a second step, let’s categorize all the interfaces based on their complexity. To achieve this, we’ll use the following definitions to divide the scope into three distinct categories:

The Migration Assessment Tool available on SAP Integration Suite could be used in cases when the Legacy is SAP PO/PI.

Collect Historical Data for Testing

Here’s the first, somewhat less obvious key point: To prepare our project for a swift and comprehensive automated verification process, we require a substantial amount of reliable data. To fulfill this need, we can employ robotic programs to extract data from our production environment, such as the Int4 Suite Robotic Crawler. It’s crucial to ensure that sensitive data is appropriately masked. The main objective is to utilize the data already at our disposal, which accurately replicate our everyday operations. The more intricate the scenarios we encounter, the greater the quantity of data we will require.

Recurring activities in Sprints (I will assume that Sprints take 3 months). For each Sprint a subset of interfaces is selected according to business and technical criteria. 

Build Test Cases

For each Sprint we start with the build of Test Cases. Since we have already collected the test data this should be a relatively easy task as the Int4 Suite Robotic Crawler will create those cases automatically. This means that time necessary to create those is negligible. The bottom line is that Test Cases are available before the development starts. It would be healthy to assume that those are available 1 week in advance. 

Develop and Validate

Development and validation are done simultaneously. Since the validation is run automatically each developer gets the results instantly. He or she is not dependent on any 3rd party systems, nor a functional consultant to run the tests. Each time a developer creates a mapping a set of testing is already conducted on the Development environment. In some complex scenarios (especially in native, non-SAP middleware functionalities) some help from Legacy Integration consultant may be needed.  

This is repeated until all is green. If the development environment doesn’t have enough configuration or master data it’s advisable to move the mapping to the Quality Assurance environment. In the QAS environment more extensive (from coverage standpoint) validation is conducted. 

It’s worth mentioning that mapping creation (especially for Low and Medium interfaces) can be supported by AI. More on that topic here: https://blogs.sap.com/2023/02/23/never-again-create-a-mapping-manually/

Who do we need to perform the job and how to assess how long would that take. This is directly dependent on the interface classification we did earlier. 

Each sprint plan:

Estimated workload per role in days (averaged):

Running the development along with validation makes the time needed for SIT at the end of the Sprint far easier. After all, we have a solid portion of test cases already in place. 

Cutover Activities and Deployment

After successfully running SIT (done automatically and on a significant volume of data) the need for UAT effectively extinguishes. In some industries or organizations it may be necessary so I would assume it should not take longer than a couple of days. The beauty of this approach is that no Business involvement is needed anymore, as from the standpoint of business nothing changes.  All we need to do at this point is to make sure that connectivity to the new middleware platform works properly. We are good to go. 

Conclusion

Service virtualization and automated validation can significantly reduce the time and workload of your migration to SAP Business Technology Platform Integration Suite. Moreover it keeps the platform owner in the driving seat regardless of who is up to the migration (in-house or outsourced).  Let me know what you think about the proposed approach and if you have any findings of your own. 

Please share your feedback and comments in section below!!