SAP Commerce Cloud is good. Genuinely! Catalog management, order management, complex B2B pricing, multi-site and multi-market configurations, it handles enterprise-scale commerce in ways that most alternatives can't. Nobody who runs SAP is looking for a reason to leave.
What they're looking for is a way to run incentive & loyalty more effectively. Not that SAP Hybris has a broken promotion engine, but that it has a promotion engine built into a platform with an enterprise deployment cycle. Want to test a new reward structure? Ticket. Want to change who qualifies for a discount this week? Ticket. Want to run a two-week experiment with different offer mechanics across two segments and see which one converts better? Well, you guessed it, ticket!
This is the architecture problem, and it's not solved by optimizing Drools rules.
Composable commerce is the idea that your stack should be a set of best-of-breed services, each handling one domain, connected via API. Best tool for catalog, best tool for search & best tool for promotions. You choose and you compose.
For most of the SAP Commerce Cloud stack, this already works. It integrates cleanly with headless frontends, supports MACH architecture, and has a mature API layer. But the promotion engine is still embedded in the platform which means every promotion change inherits the platform's release process.
Promotion strategy needs to move at marketing speed. Pull promotion logic out into its own service and the problem goes away. Marketing configures campaigns directly, in a tool built for that job, without touching SAP. Promotion experiments run on a short cycle. A/B tests happen at the offer level, not just the email subject line.
There are also some more concrete limitations worth knowing about, beyond the pace issue.
Performance degrades as promotion volume grows. SAP's own community docs flag slowdowns starting around 2000 to 3000 active rules, with more serious issues above 5000.
Flash sales require coordinating multiple systems at exactly the same moment.
Unique code generation at scale is clunky, and enforcing single-use or time-limited codes requires custom development. Version upgrades have a reliable track record of breaking promotion rules in ways that need manual cleanup afterward.
Standard percentage discounts and fixed BOGO rules work in Drools. Dynamic conditions don't. Product bundle promotions are the clearest example. "Any laptop plus any compatible sleeve, 20% off" sounds simple. In Drools, supporting flexible combinations requires manually configuring every possible pairing. In practice, teams build a custom bundle service outside Drools entirely and bypass the rule engine for these cases.
Teams work around all of this. The question is whether they should have to.
SAP is a monolithic system that powers plenty of enterprises and governments. By nature, SAP platform has to be slow to evolve as any risk of changes can break the system. What I am getting at is that a software that can run everyone’s business is going to be insufficient in one way or another.
Add to that notoriously poor user experience, high risk of business stagnation, and million-dollar contracts and SAP solutions stop being perceived as the go-to market solution to future-proof your organization. In the context of promotions, SAP solutions may not be enough for a drastically evolving digital landscape that requires flexibility. New customer touchpoints, deep personalization and smart targeting are difficult business goals to achieve, especially with a legacy promotion system holding you back.
Voucherify connects to SAP Commerce Cloud via REST API. The integration point is checkout: when a customer applies a code or the cart evaluates for automatic discounts, SAP calls Voucherify's validation endpoint in real time, gets the result back, applies the discount, and continues with order processing.
Most teams start with promo codes because the integration surface is small and the results are easy to measure. Once that's running, they expand: automatic discounts, loyalty rewards, referral programs, whatever's next on the roadmap.
For teams already running a headless storefront on top of SAP, it's even simpler. The promotion engine connects at the API layer and never touches SAP's presentation stack at all.
The operational shift is the point of all of this. When promotion logic moves into a dedicated engine, offers go live in hours, not sprints. Experiments run on a short cycle: try a different reward for one segment this week, check the results, adjust or extend. If a campaign is underperforming, you turn it off immediately. Budget caps, fraud rules, per-customer redemption limits, all of that runs automatically in the background on every transaction, so speed doesn't mean losing control.
That combination, marketing moves fast, guardrails run automatically, is what makes promotion experimentation something teams actually do rather than something they plan to do someday when the roadmap clears.
Continuity is an import factor in any organization’s success. Most businesses consider any disruption a potential threat to customer experience and revenue. As proved by MACH Alliance’s research, the biggest roadblock to update the legacy system to a more flexible modular built stems from resistance to change and lack of understanding of potential benefits.
Keep in mind that replacing a SAP Promotion Engine with an external solution would be an ongoing process that would need to engage some chunk of your development resources.
However, by making a switch, you multiply your organization's potential for success in terms of quicker time-to-market, better customer-facing technologies, and overall, more room for strategy changes and offer optimization.
.svg){kind=icon}
