SAP CPQ 2608: Early Breaking Changes and What Admins Should Prepare For

The important point is simple: these are early breaking changes and announcements, not a complete final release analysis. So I would not treat this as “everything that will be in 2608.” I would treat it as “the part you should not ignore.”

And in SAP CPQ, ignoring small technical changes is how small technical changes become Monday morning chaos. Hoorah, but carefully.

The main SAP CPQ 2608 admin risks to review first

The early announcements around SAP CPQ 2608 touch several areas that administrators usually own directly or indirectly: AI-related settings, Quote 2.0 data structure, quote replication, deployment between tenants, approval customizations, and API response handling.

That means this release is not only a technical topic. It is an operational readiness topic. If your organization depends on SAP CPQ for complex quoting, the question is not only “What changed?” The better question is “Which of our processes, scripts, integrations, and admin routines assume the old behavior?”

This is especially important for teams already working through Quote 2.0 improvements or post-go-live stabilization. If your internal admins are still handling support tickets around quote status, pricing behavior, approvals, or document generation, the Solvetect article on SAP CPQ troubleshooting for internal admins is a useful companion piece because release readiness and troubleshooting discipline usually go together.

The release is more about readiness than new features

From an admin perspective, the early 2608 items look like cleanup and alignment work. SAP is moving older concepts out of the way, tightening supported integration paths, and reducing dependence on older technical patterns.

That is healthy product evolution. But it can be uncomfortable if your tenant has years of custom behavior, inherited scripts, or integrations nobody has looked at since the original implementation.

The practical risk is not that SAP CPQ suddenly becomes unfamiliar. The risk is that old assumptions remain hidden inside customizations, API consumers, deployment setup, or Quote 2.0 migration plans.

Start with a system impact review

Before looking at individual items, I would create a small impact matrix. Nothing fancy. Just enough structure to avoid “we think we are fine” becoming the official strategy.

At minimum, list these areas:

• AI recommendation usage
• Quote 2.0 customer and business partner handling
• Quote replication to SAP S/4HANA
• Deploy / Send Changes setup
• Approval UI customizations
• Quote List API consumers
• Admin testing and regression ownership

This kind of review fits naturally into a broader SAP CPQ implementation governance process, especially for companies where CPQ is connected to downstream SAP systems and sales operations cannot tolerate avoidable quoting disruption.

AI, Quote 2.0, and integration changes need business context

One of the most visible early 2608 announcements is the obsoletion of the SAP CPQ and SAP CX AI integration. The important nuance is that this does not mean “AI disappears from SAP CPQ.” It means the older SAP CX AI integration path should no longer be treated as a future-proof foundation.

SAP’s own learning materials describe the SAP CPQ and SAP CX AI integration as a way to support AI-powered recommendations, including cross-sell products and discount recommendations, by sending data from SAP CPQ to SAP CX AI and receiving recommendations back into SAP CPQ. In the 2608 context, teams using that path should review the official SAP Help announcement on SAP CPQ and SAP CX AI integration obsoletion and confirm whether any business process depends on it.

This is not only a technical setting. If sales teams have become used to recommendation behavior, the change can affect adoption, guidance, and process expectations.

Check whether CX AI is actually used

Many companies enable capabilities during implementation, test them, and then forget whether they became part of the real business process. So I would not stop at “the setting exists” or “the setting does not exist.”

I would check whether users actually rely on AI recommendations during quote creation. Do sales teams use cross-sell suggestions? Are discount recommendations part of pricing conversations? Are managers expecting those recommendations to appear in certain quote scenarios?

If the answer is yes, document the dependency clearly. If the answer is no, this may simply be a cleanup item.

The goal is not panic. The goal is knowing which category you are in.

Quote 2.0 business partner handling deserves a serious look

Another important early announcement is the sunset of the older Customers concept in Quote 2.0. SAP’s direction here is consistent with the broader Quote 2.0 model: business partners are the default functionality for managing customers and involved parties in quotes.

This matters because customer handling is not a cosmetic part of CPQ. It affects who is buying, who is receiving goods or services, who is billed, who pays, and how that information flows through the quote and downstream SAP processes.

If your team is still moving from Quote 1.0 patterns to Quote 2.0, this is a good time to revisit your model. The Solvetect guide on the SAP CPQ quote lifecycle is useful here because partner data, approval flow, quote status, and document output all meet inside the quote process.

What to review in Quote 2.0

I would review custom fields, scripts, quote templates, integrations, reports, and user training materials that still talk or behave as if the older customer concept is the center of the quote.

Then I would check whether business partners and partner functions are correctly understood by admins and users. In SAP CPQ, partner functions explain how a business partner participates in a transaction, such as sold-to, ship-to, bill-to, or payer. SAP Learning provides useful background on managing business partners in SAP CPQ, which is especially relevant for Quote 2.0 readiness.

If this is not aligned before the release, you may not see one big error. You may see many small issues: wrong parties on documents, confusing user behavior, integration mapping gaps, or support tickets that are hard to diagnose because the terminology is inconsistent.

Deployment, APIs, and approval customizations are where hidden problems live

The less visible changes are often the most dangerous. In 2608, I would pay close attention to three areas: Deploy / Send Changes authentication, approval UI customizations, and Quote List API consumers.

SAP introduced token-based authentication for Deploy / Send Changes earlier, and the older authentication mechanism is scheduled for removal in 2608. Since Deploy / Send Changes is used to move tested configuration from one SAP CPQ environment to another, this can affect your release process directly. SAP Learning describes Deploy / Send Changes in SAP CPQ as functionality for sending changes from environments such as sandbox or test to production, including objects such as formula rules, attribute triggers, global scripts, products, users, and templates.

If your team uses structured tenant promotion, this is not a small admin setting. It is part of your change management backbone.

Deployment readiness should be tested before the release window

The practical recommendation is simple: test your deployment path before the 2608 upgrade window.

Can your source tenant still connect to the target tenant? Can packages still be created and sent? Are the correct people able to manage deployment packages? Are failures understandable, or do they require detective work?

This is also a good moment to review whether your team has a clean process for moving configuration safely. If your deployment approach is informal, release changes can expose weaknesses quickly. The Solvetect page on SAP CPQ customization and optimization is relevant here because optimization is not only about speed or UX. It is also about keeping the system maintainable after each release.

Approval UI customizations need a code search

SAP has also announced removal of the self.useNewApprovalBranch property. This is especially relevant for environments with customized approval UI behavior.

The good news is that this is a focused check. Search your UI customizations for references to self.useNewApprovalBranch. If you find it, identify why it was used and whether the related logic is still needed.

The bad news is that many approval customizations are business-critical. If a custom approval branch behaves differently after a release, sales teams may experience it as blocked quotes, missing buttons, confusing routing, or approval delays.

That is why I would not treat this as a developer-only note. It belongs in the admin readiness checklist.

API consumers need more than a quick glance

Another early 2608 item is the planned removal of the WorkflowTransition property from the Quote List API response. If you have tools, middleware, dashboards, scripts, or custom applications consuming quote list data, check whether they expect that property.

This is one of those changes that may not affect everyday SAP CPQ users directly, but can affect everything built around SAP CPQ.

For example, a reporting layer may use quote workflow information to group quotes by state. A middleware process may use it to decide whether a quote should be picked up for the next action. A custom dashboard may use it to show pending transitions. If any of that logic depends on a response property that disappears, the issue may show up outside SAP CPQ first.

For teams deciding what to own internally and what to escalate, the article on internal vs external SAP CPQ support is a useful operational reference because API and integration ownership should not be vague.

A practical admin checklist before the release

For SAP CPQ 2608, I would prepare a short but disciplined checklist. The objective is not to create paperwork. The objective is to find dependencies before they find you.

Review whether SAP CX AI integration is active and whether any recommendation scenario is still business-relevant. Check whether Quote 2.0 customer handling has been properly moved toward business partners and partner functions. Confirm whether your quote replication process to SAP S/4HANA is aligned with SAP’s recommended path, especially if SAP Billing and Revenue Innovation Management is part of the landscape.

Then review Deploy / Send Changes authentication. Make sure token-based authentication is in place and tested. Search UI customizations for self.useNewApprovalBranch. Identify every consumer of the Quote List API and check whether it relies on WorkflowTransition.

Finally, run regression testing with real scenarios, not only happy-path admin tests. This is where a focused SAP CPQ health check can help because it turns vague release anxiety into a concrete list of risks, owners, and next steps.

Test the boring scenarios too

Release testing often focuses on the obvious user journey: create quote, configure product, price quote, submit, approve, generate document. That is necessary, but it is not enough.

I would also test reconfiguration, repricing, approval edge cases, partner changes, document generation after data changes, deployment package behavior, and any integration process that touches quote data.

In other words, test the areas where users usually say, “This worked last month.”

That sentence has a smell. It smells like a hidden dependency.

Three takeaways for SAP CPQ admins

First, SAP CPQ 2608 should be treated as an early readiness release, not just a future release note to bookmark and forget.

Second, the highest-risk areas are not necessarily the loudest ones. AI obsoletion is visible, but deployment authentication, API response changes, and approval customizations may create more practical disruption if ignored.

Third, Quote 2.0 alignment is still the big direction of travel. Business partners, supported integration flows, and cleaner admin patterns all point toward a more structured SAP CPQ landscape.

Final thought

I would not wait for the full release package before doing the first review. The early announcements already give administrators enough to start: check AI dependencies, review Quote 2.0 partner handling, validate deployment authentication, inspect approval customizations, and test API consumers.

That is not dramatic work. It is good admin work.

And good admin work is what makes release day beautifully boring.

If your SAP CPQ environment has heavy custom logic, complex approvals, Quote 2.0 migration work, or SAP S/4HANA integration dependencies, this is a good moment to run a focused review with a team that understands both the system and the business process behind it. Solvetect’s SAP CPQ consulting and support work is built exactly around that kind of practical release readiness: find the risk, explain it clearly, and fix what needs fixing before users feel it.