From PI/PO to Integration Suite: The Big Bang I Would Have Argued Against

I have spent years telling clients not to do big bang migrations. Wave by wave, one business unit at a time, rollback rehearsed before anyone goes live. That is the advice I gave in the last article I wrote here, and I still think it is right most of the time.

Then I went through one that did the exact opposite. One of our engineers moved over 300 interfaces off SAP Process Orchestration on a single date. It worked. So I had to be honest with myself about why.

The client is a chemicals manufacturer, and I will keep it at that. I have been picking his brain for weeks, which is how I know the parts that never make it into a customer reference.

The scale, in round numbers: over 300 interfaces migrated, more than 400 live afterwards, over a million messages a week between systems, hundreds of thousands of external API calls a month. All of it cut over on one date, synchronised with a new S/4HANA core going live at the same time. Every plant. No parallel run standing behind it.

Here is what made that survivable, and what I had backwards.

Waves or big bang is not a risk question

It is a testing question wearing a scheduling costume.

Waves reduce risk by keeping the blast radius small and letting the playbook get sharper each time. That part is real, and it is why I keep recommending them.

But waves are not free. You pay in months of running old and new middleware side by side, two landscapes to keep correct at once, duplicated monitoring, and a programme that outlives the attention span of the people sponsoring it. That bill arrives quietly, so it rarely gets counted.

A single date removes all of it. It also removes your fallback. That is fine if you can prove every interface is correct before you cut over, and it is negligence if you cannot.

So the question was never how to sequence the rollout. It was whether they could generate proof at the scale of their interface count.

Proof at that scale means you stop testing by hand

They automated regression testing and ran every migrated interface against real production data before go-live. Not the critical ones. Not a representative sample. All of them.

Picture what the manual version looks like at 300 interfaces. A spreadsheet, a rota, and people comparing payloads by eye. It does not scale linearly, it scales worse, because the coordination cost grows faster than the work does. And it degrades exactly when you need it most. The last fortnight before a cutover is when tired people start signing off on things they did not fully check.

You do not de-risk a big bang by adding people. You de-risk it by removing manual testing.

The practical effect shows up in the go-live meeting. "We believe the mappings are correct" becomes "here is the evidence, on production data, for all of them". That is the difference between a decision and a gamble, and it is the only reason one date was defensible.

If you are going to rebuild the layer, rebuild the pattern

Most PI/PO migrations are lift and shift. The interfaces move to newer tooling and quietly keep the batch mindset they were born with. You spend a programme's budget and end up with the same architecture in a different data centre.

Two choices here avoided that.

External connectivity became a governed product. Instead of bespoke point to point links per partner, external APIs went behind an API management layer, secured and governed in one place, now carrying hundreds of thousands of calls a month. The value is not the gateway. It is that the next partner integration becomes configuration instead of a project.

Reuse was a decision, not a reflex. Prepackaged content and existing mappings were reused where that genuinely applied, and interfaces were rebuilt where it did not. Worth noting the count went up rather than down: over 300 migrated, more than 400 live. A migration is rarely a like for like move, and pretending otherwise is how scope surprises you in month nine.

The number I would put in front of a board

Five numbers came out of this programme. Interfaces migrated, interfaces live, messages a week, API calls a month, months to deliver.

None of them is the one that matters.

Building a new interface now takes about half the time it used to.

The migration numbers describe work that is finished. That one describes everything that comes after it, and it is the only figure that tells you whether you modernised or just relocated.

Migration budgets get approved on avoided risk: end of support, compliance, deprecation. Those arguments release money and tell you nothing about whether the platform will get used. Eighteen months later nobody remembers the cutover weekend. They remember whether integration is still the team everyone waits for.

What happens on the Monday after

Two things in this landscape are unglamorous and carry more weight than anything on the architecture diagram.

Errors alert the person who owns the interface directly, so it gets looked at without a triage step. And the business has a self service dashboard, so they can check the state of a flow without opening a ticket.

That second one changed the operating model more than the platform did. When business users can answer their own question, integration stops being a queue.

Nobody notices integration until it stops. So the real measure is not the go-live date. It is how long it takes to find out what broke, a year later, when the people who built it have moved on.

What I would tell anyone facing 2027

Decide your testing strategy before your cutover strategy. The second is a function of the first. If you cannot generate proof at the scale of your interface count, you do not get to choose a single date, and no amount of project management will change that.

Do the landscape assessment before the platform decision. A review that follows a licence purchase is a justification exercise. One that comes first is architecture.

Count the cost of the safe option honestly. Months of double running, two landscapes, duplicated monitoring and sponsor fatigue are a real bill, just one nobody puts in the business case.

Rebuild the pattern, not only the layer. Otherwise you are paying cloud prices for a batch architecture.

Judge the outcome on the next interface, not the last one you migrated. How fast that one ships is the only evidence anything actually changed.

It also settled an argument we had been having internally. Our own migration approach now scopes the testing strategy first rather than last: assessment before platform choice, automation wherever it genuinely holds, targeted reengineering only where it does not.

I would still argue for waves in most rooms I walk into. What I would stop saying is that big bang is reckless. It is reckless without automated testing. With it, it is expensive to prepare and cheap to finish, which is the opposite of the trade most programmes make.