Skip to main content

Nine Mindset practices to ensure a successful PI/PO migration. Most of them happen before you build anything.

Jonathan Bragg Jonathan Bragg
5 min read

Mainstream maintenance for SAP PI/PO ends 31 December 2027. Mindset delivers a migration that lands from one that gets rebuilt.

01. Count before you commit

How it usually goes: The estimate comes off a flat object count pulled from the PI directory, priced at one rate per interface. A single mapping with fourteen branches costs the same as a file drop.

How Mindset does it: Every interface is tiered by complexity before a number goes on paper. Low, medium, high, very high, each carrying its own effort weight, testing included.

More than 1,900 integration interfaces assessed or migrated to date.

Powered by M-Suite: AI-assisted requirements analysis.

02. Auto-convert, then triage

How it usually goes: Everything that converts gets migrated. The estate arrives on the new platform carrying interfaces for systems decommissioned years ago, trading partners nobody trades with, and one-off cutover flows from a project that ended in 2019.

How Mindset does it: Conversion is the inventory step, not the build step. We convert to see what exists, then find out what actually runs, then build only that.

One Mindset client had 251 legacy iFlows auto-converted. 65 were live. We built 65.

Powered by M-Suite: AI-assisted requirements analysis.

03. Expect to modernize, and price it

How it usually goes: Quoted as a straight lift and shift, as though every technology converts one to one. It does not. The gaps surface in build, and the change order arrives in month three.

How Mindset does it: Some things cannot move as they are. RFC sender adapters have no equivalent in Integration Suite. Neither do REST adapters. The migration tool rewrites both. We find what has to be rebuilt during assessment, price it as modernization up front, and name the upstream and downstream backend changes it forces.

Identified at assessment. Not discovered in build.

Powered by M-Suite: AI-assisted requirements analysis.

04. Pattern library first

How it usually goes: Developers take interfaces off the backlog one at a time and solve each on its own. Six people produce six styles of the same integration.

How Mindset does it: Every integration type is categorized up front into a pattern library. ERP to third party, customer direct, data sync, file transfer. Then the build runs in parallel under architect review.

A Mindset client, an electrical products distributor, hit 3x delivery acceleration against sequential migration.

Powered by M-Suite: end-to-end migration orchestration.

05. One retry pattern, applied everywhere

How it usually goes: Error handling is written per interface, or left out and discovered in production. A network timeout at 2am becomes a person on a call.

How Mindset does it: One parameterized retry iFlow with configurable limits, delays and escalation, applied uniformly across the estate.

Example: one Mindset client had 49 interfaces on a single retry pattern. Zero retry failures since go-live.

06. Basis on the team, not on a ticket queue

How it usually goes: Basis is a queue you raise a request against. The integration team waits on sub-accounts, certificates and destinations from someone who has never configured BTP.

How Mindset does it: A Basis expert with both BTP and Integration Suite depth and real S/4HANA experience sits on the team from day one. They own the landing zone and the backend changes the migration forces.

The first thing our delivery lead would add if he ran his largest PI/PO migration again.

07. Land the platform before the interfaces

How it usually goes: Build starts in whatever sub-account exists. Transport, certificates and access get sorted out later, which means month four is spent rebuilding month two.

How Mindset does it: The landing zone comes first. Dev, test and prod separation, Cloud Connector, OAuth, role-based access, and governed transport through CTMS before interface one.

Standard on every Integration Suite engagement we run. Dev, test and prod separated and transport governed before build starts. Provisioned as code in minutes, not the 60 to 80 hours it takes by hand.

Powered by M-Suite: automated environment setup.

08. Cut over by business function

How it usually goes: One weekend, everything at once. If something breaks you cannot tell which of two hundred changes did it.

How Mindset does it: Phased cutover aligned to business functions, with parallel-run validation on each phase and hypercare behind it.

65 business-critical interfaces live with zero residual defects at cutover.

Powered by M-Suite: automated testing framework.

09. Hand over the runbooks

How it usually goes: Knowledge leaves when the consultants do. The client owns a platform nobody on staff can operate, and the next change order writes itself.

How Mindset does it: Documentation, runbooks and knowledge transfer are deliverables, not goodwill. Your team runs the platform when we leave, with governance and development standards already set.

Same client, same engagement: zero change orders.

Powered by M-Suite: automated documentation.

Start with the assessment.

You will find interfaces nobody has run in three years. Better to find them now than to pay to move them.

These seven run on M-Suite, our accelerator built for one job: moving customers off PI/PO. Tooling and a delivery blueprint that together cut migration programs by up to 40%. More than 5,000 organizations are still on PI/PO. Most of them have not started.