Your S/4HANA Migration Is a Once-in-a-Decade Chance to Fix Your Pricing Architecture

Every condition type, every custom pricing routine, every workaround your team built over the past 10–15 years in SAP ECC — it’s all about to be migrated into a system you’ll run for the next decade.

That’s the quiet reality of S/4HANA pricing migration. Your project team is focused on data migration, custom code remediation, and cutover planning. Pricing is on somebody’s workstream list, but it’s likely being treated as a data migration exercise: export the condition records, map them to the new table structure, import them into S/4HANA, and move on.

That approach will work. It will also lock every layer of accumulated pricing complexity into your next-generation platform — the one you’ll operate until the mid-2030s.

The S/4HANA migration is the single best opportunity most organizations will have to fundamentally rethink their pricing architecture. It won’t come again.

What You’re Actually Carrying Forward

Most SAP ECC environments have been running for a long time. Over those years, the pricing configuration has grown organically. New condition types were added for specific customer deals that became permanent. Pricing procedures were extended with workarounds that nobody remembers the original reason for. Condition tables were duplicated because it was faster than modifying the existing one. Z-code pricing routines were written to handle edge cases that may no longer exist.

The result is a condition technique that works — but that very few people in the organization fully understand.

This isn’t speculation. SAPinsider research found that 83% of finance professionals view cleansed and harmonized master data as important or very important for their S/4HANA goals. The people closest to the data are telling you the current state isn’t sustainable.

SAP has made the stakes explicit. In 2025, SAP formalized a four-level Clean Core maturity model, ranging from Level D (unmanaged customization) to Level A (true clean core where all innovation runs outside the ERP). The direction is clear: the more custom code an organization carries into S/4HANA, the more painful and expensive the migration becomes. Panaya’s analysis of migration programs reinforces the point — custom code challenges account for more than 30% of total S/4HANA project scope, and in virtually every ECC landscape, the pricing function is among the most heavily customized areas.

When you lift-and-shift that pricing configuration into S/4HANA, you get a new database (PRCD_ELEMENTS replaces the legacy KONV table), but the same tangled logic on top of it. You’re importing legacy complexity into a system that was architected to avoid it.

Why This Is a Pricing Transformation, Not a Data Migration

S/4HANA’s pricing architecture includes meaningful technical improvements — enhanced table structures, better HANA query performance, Condition Contract Management replacing SD rebates, and a Fiori-first interface for daily pricing operations. But the bigger opportunity isn’t technical. It’s strategic.

The migration forces you to touch every pricing configuration anyway. You’re already going to review condition types, test pricing procedures, and validate condition records in the new environment. The incremental effort to rationalize and simplify during that process is a fraction of what it would cost as a standalone project.

Here’s what rationalization looks like in practice:

Start with condition type hygiene. Analyze which condition types are actually used in live transactions versus which ones exist in the configuration but haven’t been referenced in 12 months. It’s common to find that 20–40% of configured condition types in a mature ECC system are dormant — created for a specific deal or scenario that has long since expired. Those can be retired during migration rather than carried forward.

Then examine your pricing procedures. How many steps are there? How many are workarounds for limitations that S/4HANA’s native capabilities now handle? How many custom pricing routines (ABAP routines in the customer namespace) are compensating for logic that could be handled with standard condition technique configuration? Every custom routine you eliminate is a maintenance burden you remove for the next ten years.

There’s a human dimension here too: the logic embedded in pricing Z-code is often undocumented and understood by only a handful of senior developers. When those individuals leave or retire, the organization loses the ability to confidently modify — or migrate — its own pricing logic.

Finally, look at the condition records themselves. How many are expired or redundant? How many reflect pricing strategies that have since changed? Migrating clean, current condition records into a simplified pricing procedure is a fundamentally different outcome than migrating everything and hoping the new platform performs better despite the same underlying complexity.

The Case for a Dedicated Pricing Layer

Here’s where the conversation gets interesting for organizations with sophisticated pricing needs. The S/4HANA migration is also the natural moment to evaluate whether pricing logic should live entirely inside the ERP — or whether a dedicated pricing platform should own the intelligence while the ERP handles execution.

This isn’t a new idea, but the S/4HANA migration makes the architecture cleaner than it’s ever been. And it’s worth stating directly: if pricing is so complex that it feels daunting to extract from the ERP, that same complexity makes it equally risky to migrate as-is under compressed timelines and clean core requirements. A dedicated platform doesn’t eliminate the complexity — it manages it in the right place.

Platforms like Pricefx (an SAP Endorsed App, premium certified for S/4HANA), Zilliant (with a real-time pricing engine that integrates via high-performance APIs), and PROS (an SAP Certified partner since 2008, with roughly 60–70% of their customer base running SAP) are all designed to sit alongside S/4HANA — not replace it.

The model works like this: the pricing platform owns the pricing intelligence — optimization models, AI-driven guidance, dynamic segmentation, deal scoring. SAP S/4HANA owns the execution — condition records, price determination in the sales order, posting to finance. The pricing platform writes simplified, optimized condition records back to S/4HANA, which means your ERP’s pricing configuration stays clean and maintainable.

This architecture directly addresses the condition record bloat problem. Instead of hundreds of condition types handling every pricing scenario inside the ERP, you push the complexity upstream to a system designed for it. The ERP receives the output — a clean price — and executes it. Your S/4HANA condition technique becomes thinner, faster, and easier to support.

The Window Is Narrower Than You Think

Only about 39% of SAP’s 35,000 ECC customers had migrated to S/4HANA by late 2024, according to Gartner. Mainstream support for ECC EHP 6–8 ends in 2027, with extended maintenance available through 2030 at an additional 2% cost. SAP has offered a transition option through 2033 for select complex customers — but that’s not a blanket extension, and it comes with conditions.

The consulting market is already feeling the pressure. Implementation partner rates are rising as demand for S/4HANA talent outpaces supply. Migration projects are taking an average of 30% longer than originally planned.

If your go-live is 2027 and you haven’t scoped pricing rationalization yet, the window to do it properly is measured in quarters, not years. The organizations that treat pricing as a lift-and-shift are adding the fastest workstream to the shortest timeline. The organizations that treat it as a transformation are making a strategic investment during a window that won’t reopen.

Four Questions to Ask Your Migration Team This Week

Before the next steering committee meeting, ask these questions. The answers will tell you whether your pricing migration is on track — or whether you’re about to carry forward a decade of technical debt.

1. How many condition types in our current ECC system have been referenced in a live transaction in the past 12 months — and how many haven’t?
2. How many custom pricing routines (Z-code / customer namespace ABAP) exist in our pricing procedures, and how many of those are documented well enough that someone other than the original developer could modify them?
3. What is our plan for pricing configuration in S/4HANA: lift-and-shift, rationalize during migration, or evaluate an external pricing intelligence layer? Have we explicitly made that decision, or is it defaulting to lift-and-shift by inertia?
4. If we could reduce our condition types by 30% and eliminate our custom pricing routines, what would that save us in annual maintenance, testing cycles, and future upgrade effort over the next ten years?

If the answers to those questions aren’t immediately clear, that’s the signal. The migration is already on the timeline. The question is whether you use it.

The Takeaway

Your S/4HANA migration is already going to touch every pricing configuration in your system. The question is whether you use that moment to simplify — retiring dormant condition types, eliminating custom routines, cleaning condition records, and potentially offloading pricing intelligence to a dedicated platform — or whether you carry forward a decade of accumulated complexity into a system you’ll operate for the next ten years.

The migration is happening regardless. The transformation is optional. But the organizations that choose it will come out the other side with a pricing architecture that’s faster, cleaner, and ready for the AI-driven pricing capabilities that every major platform is shipping right now.

The best time to fix your pricing architecture was five years ago. The second best time is during your S/4HANA migration.