Beyond the Gridlock: Solving Your PO Migration Killers

I've watched companies move 100+ interfaces in a single month from dev to prod.

I've also watched teams spend six months barely getting off the ground — talented people, real budgets, genuine intentions — just stuck.

The difference almost never comes down to the technology. SAP's tools are solid. The platform works. What I keep seeing, over and over, is the same handful of avoidable mistakes showing up like old friends nobody invited.

So here's what actually stalls PO migrations — and what to do about it.

Failure to launch

When its time to go and you are still feet on the ground

There's a specific kind of overconfidence that comes from running a stable PO environment for years. Your team knows the platform. Things work. There's a comfort there — and then suddenly you're in BTP, and it's a different world.

I've seen Basis teams spend weeks just trying to get Cloud Connector configured correctly. Security teams learning permission structures on the fly while the project idles. Well-meaning people who want to do things right accidentally building little fiefdoms on the new platform because they don't want to make a mistake they can't undo. And meanwhile everyone else waits.

None of this is incompetence. It's just what happens when smart people hit a steep learning curve without a ramp.

The fix is embarrassingly simple and almost always skipped: training before the project starts. Learning.sap.com has free learning journeys. SAP offers structured classes. What takes weeks to absorb through trial and error takes four hours in a well-structured course. I know people learn by doing — but a class first gives you the mental model to make sense of what you're doing. It changes weeks of confusion into days of productive work.

Even if you have an experienced partner doing the build, the customer still needs that context. Because there are decisions made during a migration that have lasting consequences — architectural choices, security setups, platform configurations — and if your people can't evaluate what's being recommended, you're flying blind. Get the training. Do it early.

The planning looked thorough. It wasn't.

BATSAP

Batman wins the battle before the fight begins. In contrast, most migration projects do not do the prep before they start slinging code. The migration report and T-shirt sizing exercise are almost universally skipped or rushed. There are not metrics established to even gauge how well things are going. Most customers assume they know how many interfaces they have. They almost never do. And they assume the complex interfaces will be the hard ones to migrate. Also not reliably true. Sometimes the interface that looks simple on paper requires an extensive workaround because a feature the old adapter handled natively now needs a custom Groovy script. It doesn't look complex. It just is.

Seasoned migrators know to look for specific patterns and problem areas before the project kicks off. SAP's built-in assessment tools give you a useful starting point. FIGAF's migration tool goes further — it identifies issues while you're still in planning, before they turn into schedule slips.

At Happy Integrations, we automatically generate interface diagrams, discussion points, and a full project plan in Cloud ALM as part of our upfront analysis. I'll own that it's a pitch for our product and services, — but the reason we built it that way is because knowing what you're walking into before you start is the single biggest lever of whether the project lands on time. Establishing the metrics for post project analysis over multiple projects also allows us to tell how accurate we are and revise our models for future improvement.

Our neat concept is visualizing what the migration looks like ahead of time. \

Clicking migrate is not the same as being done

Just because the pieces have moved doesn't mean the migration is done

I want to be fair here: the one-click migration tools are genuinely useful. Both SAP's native tooling and FIGAF offer it, and for getting objects into the new environment quickly, it works. Use it.

Just don't mistake the starting line for the finish line.

Migrated objects can almost always be simplified. Modernized. Cleaned up. Trying to make Cloud Integration behave exactly like PO is usually the wrong goal — it's a different platform with different strengths, and fighting that costs you more than it saves. Rename legacy objects (seriously, who even uses namespaces at this point). Standardize your flows. Add proper error handling, alerting, and retry logic. The migration is your chance to build something you're proud to support, not just something that technically works. And its not just cosmetic, and hour spent on the project now can avoid  days or weeks in support headaches.

Nobody agreed on how to build things. Now you have chaos.

Picture this: you've got a great team, everyone's motivated, development kicks off — and a month later you have ten different ways to do the same thing. One developer chains Groovy scripts instead of using standard functions. Another uses XSLT in places where it genuinely makes no sense. Some flows are searchable in the MPL log. Others aren't. Every alert message looks completely different depending on who wrote the interface.

I've been brought into migrations specifically to redo work because this exact thing happened. It's expensive. It's demoralizing. And it was entirely preventable.

Governance isn't a bureaucratic checkbox. It's the thing that keeps your integration landscape supportable by someone other than the person who originally built it. Don't try to figure this out on the fly. Set your development standards before a single line of code gets written. Establish quality gates. Define what a "done" interface looks like. Tools like FIGAF DevOps help — you can diff iFlows and scripts between versions to see exactly what changed — but the discipline has to be baked into the process, not bolted on after the fact.

Testing got underestimated. Again.

Here's a pattern I've seen enough times to call it reliable: teams overestimate what the one-click migration handles, and underestimate how much testing it takes to actually be confident in what they've built.

The platform differences between PO and Cloud Integration are real. Subtle, sometimes — but real. Adapters behave slightly differently. UDFs don't always translate cleanly. A mapping that worked perfectly for years produces slightly different output in the new environment. And you won't know until you test it.

On top of that, SAP manages Cloud Integration and pushes updates. Usually that's a good thing. Occasionally it means a library you've been using gets deprecated and you're scrambling. Groovy script versions are being updated right now — which means you need a regression testing strategy for everything you've already migrated, not just new development.

I use FIGAF to pull test messages from PO — it's a significant time saver compared to digging through the system manually. For core interfaces, I build mocks. For iDoc handlers, proxy handlers, and other CI-specific patterns, I build dedicated testing utilities. The build is only part of the effort. The infrastructure and mindset that lets your team test confidently and move fast is just as important.

Leadership sees this as IT plumbing. That's 💩.

To the business, a PO migration can feel like: "just give us what we already have, but newer." Not exactly a rallying cry.

Projects that don't have genuine leadership support — where management's attitude is just get it done — consistently end with everyone unhappy. Testers are completely put off as they have other work to do. It may not be a priority for legacy resources. The technical work gets done, but it gets done under pressure, without the right resources and focus, and the result is a system that nobody's proud of and everybody resents maintaining. Its also completely counter productive as the most expensive and frustrating way to do a migration is having to do it multiple times because it doesn’t meet a business desire.

The good news is that momentum is real. Get some high-visibility interfaces live and working well early in the project, and you change the narrative. Throwing in some quality of life improvements may add a little scope, but can garner enthusiasm. Suddenly it's not IT plumbing — it's a win. Build on those wins. The selling is worth the effort.

You moved everything. You didn't improve anything.

Good for more than PO migrations

This is the one that quietly costs the most.

On one project, I identified a large group of interfaces that were essentially pass-throughs — converted them to APIM and saved significant ongoing effort. On another, I found over 50 batch scheduled file movers scattered across the landscape and consolidated them into a single, maintainable solution. Switching from XI-proxy to REST or OData takes a little time upfront — not as much as people think — and pays back every time you need to adjust the interface down the road.

The migration is a forcing function. You have to touch everything anyway. That's rare. Use it.

The teams that come out of a migration in a stronger position than they went in are the ones that treated it as an opportunity, not just a deadline. The ones that just tried to get to the other side as fast as possible — they get there, and then realize the landscape they landed in looks a lot like the one they left, just running on newer infrastructure.

Conclusion- PO Migration Challenges

None of this is meant to make migration sound harder than it is. The tooling is solid. The platform is capable. The path is well-worn at this point. There are a lot of capable consultancies and tools that can get customers where they need to be.

But the difference between a migration that goes well and one that doesn't is almost always in these seven places. Get these right, and the rest tends to follow.