As you probably know the support of 7.1x, 7,3x and 7.4 ends in 2020 in just 14 months. Read more about what options you have for upgrades here for versions and pricing changes.

Based on the latest IFG survey there is quite a number of customers not only using 7.5. It seems like 28% is on 7.5 while 45% is on lower releases. It means that a lot of customers need to start the migration or upgrade.

You normally have two options. Upgrade or Migration. I’ll cover them in this blog.

Upgrade

If you do an upgrade you will upgrade the development system to 7.5. Then check how it performs and if everything is okay upgrade all other systems.

If you have a dual-stack system you will need to do a stack split and then delete the ABAP system afterward. It requires you are using ICO only.

The biggest challenge is that you will have a big bang go live on all interfaces. You, therefore, need to trust everything running as it did earlier. This requires that you have tested all interfaces or at least all critical interfaces. There are 3 public testing tools for SAP PI/PO. All of them are using the option to fetch data from a real system and then replay it on your test system.

1. SAP PIT it is a free tool from SAP on 7.5 sp 14. It is free to use but requires you have installed SP 14(16 recommended) and to fetch data from older systems 7.31+ then they need to be patched after Feb 2019.
2. Figaf IRT is installed on a separate system. It is great for just enable testing on all interfaces and has a lot of options for testing like with modules, EDI/X12 comparison and more.
3. INT4 IFTT. A testing tool based on your ABAP system. It enables deeper comparison to validate AIF and processing on backend systems.

I’m probably biased.

Migration

The migration option as some benefits and is really useful when you are not info a big bang go-live. The idea is that you install a new set of systems with the newest version of SAP PI/PO. (There may be license dependencies, you will need to figure out). You can then move the interfaces to the new system one by one and see how they perform.

You have the option to fall back to your old system if something comes up. And you can move a few interfaces at the time. So really useful if you are moving from Seeburger to B2B Add-on or have some different designs or patterns that you want to use.

The challenge is that you need to have two system landscapes during the project. You will need to configure everything in the new landscape and it can be rather time-consuming. As you probably read from the post then this about automates the migration process. So we have a solution that can help.

Testing is still an important topic for this, but there are a lot more steps that need to be done.

The normal landscape would look something like the image below. Two strings of SAP PI/PO systems. One for the old landscape and then one for the new on.

The manual steps for migration are.

1. Copy Repository objects from D1 to D2
2. Copy Directory objects from D1 to D2. The Migration tool from SAP can be used for this. Also be sure you get hostname, paths, user name, and password.
3. Update interface objects on D2 to make sure it still works.
4. Transport the objects to Q2, and perform your tests there. Once you import you need to configure channels in the same way as Q1.
5. Test that it still works on QA.
6. Transport to P2 and configure channels similary as P1.
7. Switch interface to use P2 and disable the interface on P1.

How Figaf can automate the Migration?

We started creating a testing tool for SAP PI. To be able to automation we needed to understand all PI Repository and Directory objects. So the project expanded until we could do automate Change management of SAP PI/PO, and then it was possible to make a migration tool.

Managing releases

As with any project, it is about managing the integration in chunks so they can go live in different phases. We have now added a Release object to the Figaf Tool. This will enable you to manage multiple integrations at one time.

From the release, you can see the status of all interface. You can also perform mass operations on multiply interfaces at the time. This makes it a lot faster.

Once you add an interface you can select to use the test data you already have created. Or you can create new test cases for the interfaces. The build-in tool enables you to get started fast.

Transports

The mass operation could be to create transport. Yes, we have built our own transport system. That allows you to transport PI Repository via the file import/export option and Directory transport via the API. I have seen that not all SAP PI/PO customers are using CTS+, so the transport system will help them.

The transport is used to move both Repository and Directory data from the old system to the new. It will find all the relevant objects that need to be moved for the scenario to work. You will thereby not have to copy artifacts that are never used.

A new thing we have added to the transport is to show all object. There is also the option to have approval build into an architect need to Approve transports before they can be delivered to the target system.

You can see what a simulation on what the value should be when it is imported and what the change will be. It makes it much easier to approve a change if you know what will be changed.

You also have to option to see the configuration of channels across the landscape. You will get a view like the following. Here you can specify what paths, URLs, username, and passwords will be in the landscape. That way you don’t have manual steps for performing the imports.

Transport the new landscape

Once you have migrated and have run the tests with the Figaf tool, then you will be able to validate that the interface and modules work the same way in the old system as in the new.

The tool will also allow you to copy non-transportable parameters for all channels on the corresponding channel. If you are on an older support pack of your systems then it would be possible to fetch password also and copy them to the new configuration. Then it will be a lot easier to perform the migration because you don’t need to find and copy the values.

Next is you want to use the transport in the new landscape. In the initial release, it will be to use the Figaf tool for transport, but we may also add CTS+ if requested by clients.

Once the transport is imported then it is configured as specified in the configuration guide.

See it all in action

I have created a video to show how the full process works and how the tool can work.

What more

There are some gaps with the product we do not support “Classical” PI objects like Receiver and Interface Determination. Also if you are changing adapters it is not supported yet. There are also user improvements that could be made to improve the process of migration.

In the long process, we probably can use the same process to migrate from SAP PI to SAP CPI. There are some components we need to build first.

Learn more

I’m hosting a webinar on Thursday, October 24 to share and show more of what the tool can do. You can see the replay here.

Other than that you can signup for Figaf IRT and get access to the beta release.