SAP CPQ 2602: Breaking Changes You Should Not Ignore
New features get the spotlight in every SAP CPQ release, but breaking changes are where upgrade success is really decided. SAP CPQ 2602 is no exception. While the release brings welcome functional improvements, it also introduces a small number of important technical changes that deserve careful attention.
This post focuses on the key breaking changes in SAP CPQ 2602 that can impact integrations, scripting, and UI customizations; keep this in mind immediately after upgrading as you have 2 weeks to fix any issues.
1. REST Custom Table API Authentication Change
Starting with SAP CPQ 2602, SAP introduces a change to Custom Table API authentication. You must now use the /oauth2/token method.
Any external integration that reads from or writes to Custom Tables via REST needs to be reviewed.
What changes
SAP has updated how authentication is handled for Custom Table APIs. While the APIs themselves remain available, existing authentication approaches may not work after the upgrade. Make sure this is tested.
Why this matters
If left unaddressed:
- Integrations may fail silently
- Data synchronization issues can appear post-upgrade
This change primarily affects technical users and integration scenarios, but the business impact can be significant.
2. Deprecation of the IronPython eval() Statement
SAP CPQ 2602 officially deprecate the IronPython eval() statement to improve platform security and stability.
What changes
- Existing scripts that already contain eval() will continue to run
- However, you will not be able to modify those scripts unless the eval() usage is removed [help.sap.com]
SAP has been signaling this direction for several releases, and 2602 makes it explicit.
Why this matters
The eval() function is powerful but also risky:
- It allows dynamic execution of code
- It increases security exposure
- It makes scripts harder to debug and maintain
From SAP’s perspective, removing eval() is a necessary step toward safer and more predictable scripting; which help protects all SAP CPQ customers.
From a customer perspective, it means:
- Legacy scripts using eval() should be identified early
- Refactoring should happen before February 14, 2026.
3. Responsive Templates Must Be Updated
As with previous releases, customized responsive templates must be updated to the latest SAP version when upgrading to SAP CPQ 2602. This provides you with all the latest updates.
What changes
SAP continues to evolve standard responsive templates. Any customer that customized responsive UI templates must rebase those customizations onto the updated standard templates.
Why this matters
Failing to update templates can result in:
- Missing functionality / Incompatibility with new CPQ features
- UI rendering issues
This is not new but it remains one of the most common upgrade pitfalls in CPQ projects.
What This Means for Your 2602 Upgrade
SAP CPQ 2602 does not introduce a large volume of breaking changes, but the ones it does introduce can be high‑impact if overlooked.
At a minimum, every upgrade plan should include:
- A review of Custom Table API integrations
- An inventory of IronPython scripts using eval()
- A structured approach to responsive template update
Ignoring these items can turn an otherwise smooth upgrade into a production issue and you don't want to go there!
Final Thoughts
SAP CPQ 2602 continues a clear trend:
Stronger security, cleaner APIs, and less tolerance for risky or legacy customization patterns.
These breaking changes are not arbitrary, they reflect SAP’s push toward more stable, governable, and enterprise‑ready CPQ landscapes.
Teams that address them early will benefit not only from a smoother 2602 upgrade, but from simpler future upgrades as well.
Make it happen, you have until February 14, 2026!