The Real Cost of an SAP BTP Migration And How to Model It First

Ask most integration teams for the total cost of an SAP BTP migration and you get one number: a project fee. That figure rarely survives contact with the real landscape, because it treats every interface as identical. Migration effort itself turns on three variables: how many interfaces are moving, how complex each one is, and how much of the work runs without a person touching it. Model those three before signing anything, and the effort estimate you commit to sits close to what you pay.

There is also a clock on this decision. SAP ends mainstream maintenance for PI/PO on 31 December 2027, with extended maintenance available only to the end of 2030, at a premium of roughly two percentage points over standard maintenance pricing, and with reduced scope. That is not a reason to rush a cost model. It is a reason to get one right the first time, since there won't be a second pass at this budget line before the deadline arrives.

This is a business-case question before it is a technical one. Whoever signs off the budget does not need to know how an interface gets rebuilt. They need to know what drives SAP BTP migration cost up or down, and where there is still room to change the outcome before the contract is final.

What "total cost of migration" actually covers

Total cost of migration spans discovery, interface redesign(where redesign is genuinely needed), testing, and the ongoing run cost once the estate is live on SAP Integration Suite.

Two projects with identical interface counts can land on very different budgets, because the count alone says nothing about effort. A landscape of 400 straightforward interfaces can cost less to migrate than one with 150 that carry heavy custom logic. Any cost model built on "interfaces times a rate card" will be wrong. Complexity moves the number. Volume does not.

Why this gets modelled before you commit, not after

Cost modelling belongs at the start: an optional business case and RoI step, ahead of detailed discovery, so the decision to proceed rests on real landscape data rather than a guess.

Discovery and assessment produces a migration approach document covering the legacy estate, interface complexity, redesign needs, a migration and test plan, and a cost estimate. That document is what a go or no-go decision gets made against, not a figure quoted on a scoping call. Revising an estimate on paper costs an afternoon. Renegotiating scope once a migration is under way costs a quarter, plus the trust of whoever approved the original number.

The cost driver most teams underestimate: interface complexity

Not all interfaces cost the same to move, and pricing them as if they do is the single biggest source of budget surprises in an SAP Integration Suite migration.

For a legacy platform moving to SAP Integration Suite, interfaces fall into three bands:

• Simple, fully automated. Single-click migration. No redesign or additional development needed.
• Medium, semi-automated. Partly automated, covering proxies, EDI, and custom adapter modules. Some redesign or development is factored in.
• Complex, requiring re-engineering. Manual migration effort, typically where BPM logic, custom mappings, or heavily customised adapter modules are involved.

A cost estimate that skips this classification is not an estimate. It is a placeholder with a currency symbol in front of it. Get the classification done early, and the model reflects what the landscape actually contains instead of an assumed average. For the full breakdown of how this tiering works and why an interface that looks routine can still land in the hardest bucket, see SAP PI/PO End of Support 2027: How Much of Your Migration Can Actually Be Automated?

Automation lowers the labour line, but the range is wide

Automation cuts the manual effort behind a migration, and how much it cuts depends heavily on where you are migrating from, so a single blended percentage across an entire estate will mislead you.

At landscape level, SAP PI/PO to SAP BTP or SAP Integration Suite runs at 70 to 80% automation. webMethods to the same target runs lower, at 30 to 40%. MuleSoft sits between the two, at 50 to 60%. These are three distinct performance profiles, not one process wearing different labels, and a project plan built on the wrong one will miss its own deadline before it starts.

On a per-interface basis, automation runs as high as 90%, depending on which complexity tier an interface falls into. That range is exactly why the tiering above carries more weight than any headline percentage a vendor quotes on a call.

What that range looks like in practice. Ashok Leyland, one of the world's largest commercial vehicle manufacturers, moved 230-plus active SAP PI interfaces to SAP Integration Suite at 60 to 80% automation across discovery, conversion, and validation, close to the PI/PO benchmark, without disrupting supplier and dealer network flows still running in production. For Florida Crystals Corporation's migration: 260-plus trading partners and 490-plus interfaces moved from webMethods to SAP Integration Suite over 15 months, an estate that now handles more than 90,000 messages a month. Same framework in both cases. Different starting platforms, different complexity mixes, and very different numbers as a result.

Unit-based costing gives you a lever, not just a total

Once the migration approach document captures the full landscape, you can see which interfaces are actually in use, and unit-based costing turns dropping the unused ones into a direct lever on the total, rather than a rounding error you absorb.

This is where the business case gets genuinely useful to decision makers. Landscapes accumulate interfaces that stopped mattering years ago. The 490-plus interfaces were filtered through exactly this step before the 15-month build began, which is part of why the resulting platform is sized to what the business actually uses rather than to whatever had piled up in the source system over a decade. Surfacing that during discovery, before the cost is fixed, brings the number down without cutting anything still needed.

The run-cost line most models leave blank

Migration effort ends at go-live. The bill does not. SAP Integration Suite is licensed on named subscription editions, each metered by messages included per month, and SAP's own pricing page lists monthly starting prices in the low thousands of dollars per tenant for the entry editions, scaling up from there. A message is one electronic communication; anything over 250 KB is billed as an additional message per 250 KB, and going over the included allowance means purchasing more.

That detail matters to a cost model for one reason: message volume is a direct output of the interface count and complexity mix you have already classified during discovery. A large, high-frequency estate needs a materially different subscription tier than one running a few dozen low-frequency B2B flows. Plasman's migration, which moved SAP CPI to Integration Suite in 12 weeks at 90 to 95% automation with zero downtime, sized its target tier against actual production volume rather than an assumed baseline, which is a large part of why the run cost didn't need revisiting after go-live. Sizing the target edition against projected message volume — not against the edition that looked adequate on a sales call — is what keeps the run-cost line from drifting upward in year one. Get this wrong in either direction and you either pay for headroom nobody uses or hit overage charges within the first few billing cycles.

Licensing is only the metered half of run cost. The other half is labour, and it is usually the larger number. Standard SAP CPI monitoring offers minimal payload detail and no restart option out of the box, which is a large part of why between 40% and 60% of integration engineering time on a typical estate goes to debugging pipelines and manually reconstructing failures rather than building anything new. That is not a migration cost, technically, but it is a direct consequence of what the migration leaves in place, and a cost model that only prices the subscription tier and skips the operating team's time is missing the bigger of the two numbers. Full detail on where that time actually goes: Why 40–60% of Integration Engineering Time Is Lost to Firefighting

Cutover and parallel-run costs

Migrations rarely cut over in one motion, and the transition window has its own cost that a migration-effort estimate does not capture. Phased migrations, the kind most large estates run, keep the legacy platform live for the interfaces not yet moved, because a manufacturing or retail estate cannot simply switch off integrations mid-migration without risking the business processes running on top of them.

Running two platforms side by side, even for a limited set of interfaces during validation, means licensing or infrastructure cost on both systems for the overlap period, plus the testing and monitoring effort to confirm the new flow matches the old one before the legacy path is retired. For a large estate migrated in phases rather than in one cutover, that overlap can span months rather than days. A cost model that assumes a clean, instant switch for every interface will underestimate the transition, and it is worth sizing this window explicitly rather than folding it into a generic contingency line.

What this means for the business case

None of this replaces running the actual numbers for your own landscape. What it sets is the right inputs, in two categories rather than one. Migration effort: interface counts by complexity band, not a flat total; automation potential assessed per platform, not as one estate-wide average; and a unit-based costing model that rewards removing unused interfaces before budget is committed, not after. Everything after go-live: a target licensing tier sized against projected message volume rather than assumed usage, the operating team's time factored in alongside the subscription line, and a parallel-run window costed explicitly rather than absorbed into contingency.

The logic is not specific to one migration path. It applies wherever a legacy integration platform, whether that is SAP PI/PO, webMethods, MuleSoft, BizTalk, or another middleware layer, is being modernised onto a new target. The inputs stay the same regardless of source platform: how many interfaces, how complex they are, how much of the move can be automated, what the target platform costs to run and staff at your projected volume, and how long the two systems need to overlap.

---

Frequently asked questions about automating migration

1. How much does an SAP PI/PO to SAP Integration Suite migration cost?

There is no reliable flat cost per interface. The total depends on the number of interfaces, their complexity, how much migration work can be automated, the target SAP Integration Suite subscription, and the period during which legacy and target platforms need to run in parallel. A credible estimate starts by classifying the existing integration landscape rather than multiplying interface count by a standard rate.

2. What are the main cost drivers in an SAP BTP integration migration?

The largest cost drivers are interface volume, interface complexity, automation potential, SAP Integration Suite run costs, and the length of the parallel-run period. Complexity usually matters more than raw interface count because custom mappings, BPM logic, adapter modules, and redesign requirements increase engineering and testing effort.

3. How should SAP PI/PO migration costs be estimated before the project starts?

Start with discovery and assessment of the existing landscape. Classify interfaces by complexity, identify unused interfaces, determine which scenarios can be migrated automatically, estimate redesign and testing effort, project message volumes on SAP Integration Suite, and account for any period in which both platforms will operate. This creates an interface-level cost model that can support the business case and go or no-go decision.

4. How much of an SAP PI/PO migration can be automated?

The level of automation depends on the source platform and the complexity of each interface. In the migration approach described here, SAP PI/PO migrations can reach 70 to 80% automation at landscape level, while individual interfaces can range from 20 to 90%. Complex interfaces with custom logic or unsupported patterns generally require more manual engineering.

5. Why does interface complexity affect SAP Integration Suite migration cost?

A straightforward interface that maps cleanly to the target platform requires substantially less engineering than one containing custom mappings, BPM logic, proxies, EDI requirements, or customized adapter modules. Classifying interfaces as simple, medium, and complex before estimating the project prevents a small number of difficult interfaces from distorting the final budget.

---

Run the numbers before you commit

A total cost of migration figure is only as good as the inputs behind it. If your current estimate is a single number from a scoping call rather than an interface-by-interface breakdown, it is worth pressure-testing before it becomes a signed budget line, and well before the 2027 deadline starts squeezing your options.

Tarento's RoI Calculator is built for exactly this step: putting real landscape data, not a flat assumption, in front of the go or no-go decision. If you are weighing an SAP BTP migration, running that calculation against your own interface counts and complexity mix is a reasonable next step before any commitment is made.

For the full toolset behind these numbers, discovery, complexity tiering, the Migration Automator, testing, and monitoring, along with the engagement path and customer results referenced above, see Automated Integration and Migration Services | iVolve.