Passer directement au contenu principal

We'd prefer it if you saw us at our best.

Pega.com is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
sap to blueprint

SAP to Blueprint: Turning decades of custom ABAP into AI-ready workflows

Paul Schenck, Connectez-vous pour vous abonner au blog

There's a good chance your SAP migration is already behind schedule.

Not because your team isn't capable. Not because the integrator isn't experienced. It's because somewhere in your ECC environment sits a decade or three of custom ABAP code that nobody fully documented. And now it's standing between you and your 2027 deadline.

If that sounds familiar, you're in good company.

A deadline that isn't up for negotiation

SAP has drawn a hard line. Mainstream maintenance on ECC ends in 2027. Extended support ends in 2030. After that, you're running an unsupported system, and unsupported means unpatched, uninsured, and one incident away from a very bad conversation with your board.

The deadlines are fixed. How you get there is not. And that distinction matters more than most SAP teams realize, because the instinct right now, understandably, is to treat this as a straight technical lift: move the data, move the code, move the customizations, get to S/4HANA, done.

That instinct is exactly what's blowing up timelines and budgets across the industry.

What made SAP work for you is now what's slowing you down

SAP is, and remains, an excellent system of record. It standardizes the transactional core: orders, invoices, receivables, the backbone of how a business runs. That's not in question.

But no business runs on the happy path alone. Every organization that's used SAP for more than a few years has written custom ABAP to handle what SAP's standard flows never anticipated: cross-organizational approvals, exception-driven routing, dispute resolution, short pays, multi-system promise-to-pay workflows, customer-specific contract deviations. Look closely at something as ordinary as order-to-cash and you'll find it's not one clean process. It's a standard SAP flow wrapped in years of business-specific logic that was built because the business couldn't wait two years for the next SAP release cycle to solve a problem it had today.

Research from ASUG and smartShift backs this up plainly: 67% of SAP customers rely heavily on custom code, and nearly half use it across a quarter to half of their entire system. That's not technical debt in the abstract sense. For a huge share of SAP's installed base, a meaningful portion of the system is the business.

And that's precisely what makes migration so hard. When it's time to move to S/4HANA, you're left with two options, and neither one is good. Carry all of it forward, and your migration scope balloons along with your cost and risk. Try to rebuild it from scratch and you freeze the business for months while you redesign what already works, on a deadline that doesn't care how long redesign takes.

This is also, not coincidentally, the number one reason SAP migrations blow past their budgets. Discovery uncovers far more custom logic than anyone scoped for, and from there, everything slips.

Don't rebuild it in SAP. Move it out.

The default answer you'll hear is to rebuild that custom logic in SAP BTP. It sounds like modernization. It isn't. Move your workflow logic from ABAP into BTP and you haven't externalized anything, you've relocated it from one SAP-controlled environment to another. You're still governed by SAP's release calendar. You're still single-vendor dependent. You're still paying SAP to customize around SAP's own limitations.

There's a better path, and it starts with a simple separation of concerns. SAP should keep doing what it does best: serving as the stable, compliant, upgradeable system of record. The workflows, exceptions, decisions, and human coordination wrapped around that core don't need to live inside SAP at all. They belong in an intelligent orchestration layer that sits alongside it, one that evolves on its own schedule instead of SAP's.

That's the idea behind Pega's SAP to Blueprint™: Use AI to find, extract, and reimagine the custom logic buried in your SAP environment, then run it as a governed, auditable workflow on the Pega Platform, independent of SAP's release cycle.

How it actually works

The process runs in four stages, and none of them require months of workshops.

Scan. AI agents connect to your legacy ECC (or S/4) environment and map what's actually in there: custom ABAP, Z-tables, transaction usage, embedded logic. This is a safe, read-only scan of your Dev/QA environment. No transactional data, no PII, just the code.

Extract. From that scan, Pega pulls out the business rules, personas, and exception paths that are buried inside the custom code. This is the logic the business actually depends on, separated from everything that's just noise.

Reimagine. That extracted business intent maps automatically into Pega GenAI Blueprint™, which synthesizes it against workflow best practices to generate a working case lifecycle: stages, steps, decisions, exception handling – all of it – in hours instead of weeks.

Run. The resulting application deploys directly to Pega Infinity, integrated with your SAP back-end through SAP-aligned patterns like SAP Integration Suite, so it's live and executing immediately, with SAP still acting as the system of record underneath it.

Put together, that's a working pipeline that takes you from legacy ABAP to a governed, running application in days, not the weeks or months a manual discovery-and-rebuild cycle would take. And every workflow that comes out the other side is fully auditable by design, with SLAs, escalation logic, and a clear record of who did what and why. Try building that natively in SAP alone. You'd be back to writing custom ABAP to solve the problem custom ABAP created.

It works wherever you are in the journey

This isn't a solution for one specific moment in a migration. It applies at every stage.

If you're still on ECC and haven't started your S/4 move, this is the best possible time to run the analysis. Extract and externalize the heavy custom logic before migration even begins, and you go into your S/4 project lighter – with a fraction of the scope and risk you'd otherwise be carrying.

If you're mid-migration and slipping, and a lot of organizations targeting a January 2027 go-live are currently tracking to mid-year or later, this is where the impact is immediate. Pull the most complex, custom-heavy workflows out of migration scope, externalize them into Pega, and get your timeline back under control without reopening the whole project.

And if you've already completed your move to S/4, possibly through a brownfield migration that carried the technical debt along with it, the same approach lets you systematically de-customize your new environment after the fact. You don't have to wait for the next biannual S/4 release to start operating with more agility.

This is already how leading SAP shops operate

Deutsche Telekom runs Pega side-by-side with SAP, keeping SAP as the single source of truth while externalizing workflow, business logic, and cross-system orchestration into Pega. That separation is what lets them standardize and continuously improve their operations without ever touching the SAP core.

Unilever follows the same pattern at scale, coordinating processes like order-to-cash and master data management across SAP and connected systems, with SAP handling the transactions and Pega acting as the system of work around it.

The pattern holds regardless of industry or company size: Keep SAP stable and move the logic that needs to change into a layer built to change quickly.

The question worth asking before your next SteerCo

If you've read this far, you already know where your organization's custom ABAP lives, or at least you have a good guess. The real question is what that custom logic is costing you right now, not just in migration risk, but in every workflow improvement you can't make because it's locked inside a system on a two-year release cycle.

You don't have to guess at the scope. A scan of your Dev/QA environment will tell you, in less time than a single discovery workshop, exactly what's in there, what's a strong fit to move into Pega, and what should simply stay put in SAP. That's not a theoretical roadmap exercise. It's a concrete first step you can act on this quarter, well ahead of 2027.

Let's start with a scan.

Ready to see what's hiding in your SAP environment? Learn more about SAP to Blueprint™ and request an AI analysis of your legacy SAP customizations.

Tags

Défi: Modernisation de l'entreprise
Thème: Agilité métier
Thème: Excellence opérationnelle
Thème: Legacy Modernization
Thème: Transformation numérique

À propos de l'auteur

Paul Schenck is a SAP Market Intelligence & Strategy Lead at Pegasystems, where he leads go-to-market strategy for Pega's SAP to Blueprint offering. Before Pega, he spent five years as a Senior Principal Analyst at Gartner, where he co-authored the Magic Quadrant for Cloud ERP and co-invented the term "Composable ERP," followed by a role as VP of Competitive and Market Intelligence at Infor. He has approximately 20 years of ERP industry experience, including hands-on SAP implementation work across ECC, S/4HANA, RISE, and BTP.

Vous souhaitez créer un Blueprint ?
Choisissez le moteur adapté à vos besoins.
Pour la conception de workflows et applications

Repensez vos processus et transformez n'importe quel workflow en application prête à être développée en toute confiance.

Pega Blueprint™
Pour la conception de stratégies marketing et d'expérience client

Visualisez et activez les parcours client et les stratégies d'engagement sur tous vos points de contact.

Pega Customer Engagement Blueprint™