The choices that decide which outcome you get are made early, mostly during assessment, mostly before anyone builds anything, and several of them are difficult to revisit afterwards. Below are the ones we see making the difference, drawn from migrations we have run and from our Integration Unplugged series, in which Rojo Head of Consultancy Sander Kool speaks with Adriaan Beukema, integration architect and former chairman of the VNSG, whose team is preparing a landscape of more than 2,000 interfaces for the move.

Across four episodes they cover current challenges and innovations in integration: the migration from SAP PO to Integration Suite, event-driven architecture, governance and CI/CD, AI in DevOps, and observability across a hybrid landscape.

A one-to-one transfer is possible, and usually wrong

Moving PI/PO interfaces into Integration Suite unchanged is technically achievable. It is also usually the wrong choice, because the two platforms handle mapping differently, and because the shape of an interface built for PI/PO carries assumptions that Integration Suite does not require.

That does not make full redesign the answer. The workable position is deliberate: fix what has to be fixed, modernise the patterns where the platform genuinely works differently, and move the remainder faithfully. Which interfaces fall into which category is something the assessment should establish before anyone starts building.

The interfaces nobody has touched carry the most risk

Every large PO landscape has a set of interfaces that have run without incident for years. Nobody has opened them. Nothing has ever justified the effort.

Those carry the oldest assumptions. Security is the clearest case: authentication and encryption choices made when basic authentication over an internal network was a reasonable answer. They still work, which is precisely why nobody has replaced them with mutual TLS or OAuth.

In a lift and shift, those choices move across unexamined and stay in place for another decade. If they are not reviewed during the migration, they are not reviewed at all. The same applies to the infrastructure underneath them: MQ-based publish and subscribe patterns you would now design on an event broker, end-to-end chains that accumulated intermediate steps nobody would specify today.

None of it is mandatory to change. All of it is cheaper to change while the programme is funded and open.

Redesigning everything is the other way to lose control

The opposite error is just as expensive, and it gets less attention.

Adriaan was direct about this: overshoot on innovation inside a migration and you blow the project up. Across hundreds or thousands of integration scenarios, "while we are in there" becomes an unbounded commitment quickly.

Which is why the decision has to be made per category, in advance, with a rationale attached, rather than interface by interface, by whoever happens to be rebuilding it.

Assessment and governance set the ceiling on automation

How much of a migration can be automated is largely determined before any automation runs.

An automated assessment establishes what you actually have: interface counts, dependencies, mapping and orchestration logic, payload availability, and where complexity concentrates. Governance establishes what the target looks like: integration patterns, naming conventions, error handling, and which functionality belongs on which platform.

Rojo's Migration Approach & Studio assessment is one way to get that first picture: eight questions, about two minutes, and it returns an indicative duration for a landscape like yours, the five phases we would run, and where automation carries the work rather than your people.

With both in place, templates and CI/CD pipelines carry a large share of the build, and quality checks run inside the development process rather than sitting in a document someone was meant to read. Without them, automation reproduces whatever you already had, faster.

Adriaan's team took this far enough to build their own migration tooling, because SAP's standard migration tool would have meant compromising on their templates, naming conventions, error handling and Git workflow. They built it so the standard would hold. A standard nobody enforces stops being one.

Two migrations, one architecture

These decisions rarely arrive on their own.
ECC to S/4HANA. PO to Integration Suite. A shift toward event-driven architecture. Three transitions, frequently inside the same programme, each owned by a different group of specialists.

Keeping the core clean forces a question neither group can answer alone: do you migrate all your XI ABAP proxies as-is, or invest in REST-based programming and the RAP framework inside the backend? Once eventing is in scope, JSON is the more common message protocol, which changes the answer and makes this a backend investment decision that directly determines integration design.

Run the two migrations as separate projects and that decision gets made twice, inconsistently, once by people optimising the backend, once by people optimising the integration layer.

Business sign-off runs on evidence, not assurance

Business stakeholders in a migration gain no new functionality. They are approving the same processes on a different platform, which limits their appetite for involvement and lowers their tolerance for risk.

Evidence is what moves them. Regression testing that replays captured payloads through both the old and the new environment and compares them field by field turns "we have tested it" into a list of interfaces validated, payload variants covered, and a pass rate per interface.

By hand, that does not scale to a landscape of this size. Rojo's Migration Studio automates it: extracting existing interface logic, generating Integration Suite artefacts against your templates, and running automated scenarios against real payloads. In a recent large-scale migration to Integration Suite, that reduced manual regression effort by up to 70% and produced interface-level pass/fail reporting that IT and the business could read from the same dashboard.

Where the constraint actually sits

Across all of it, the limiting factor is rarely the platform. It is what gets decided before the build starts: what you assess, what you standardise, what you deliberately leave alone, and who is in the room when the backend and integration choices meet.

Adriaan's advice to teams at the start of this: do not begin too late. Not because 2027 is close, but because the decisions worth making well are the early ones.

Planning your move from SAP PO

Rojo is a certified SAP Migration Factory Partner, certified for PI/PO to SAP Integration Suite migration. See our SAP PO to SAP Integration Suite migration approach, covering assessment, automation and validation for landscapes of any size.

If you rather talk it through, book a call with our migration architects to access your own landscape: what you are running, what your deadline looks like, and where automation would realistically carry the work.