For nearly two decades, Cytiva ran on a homegrown configurator that everyone knew how to work around. It did the job. It also hid the real cost. When product changes slowed to accommodate the system instead of the market, the team faced the quiet truth: the configurator had become the constraint.

I’ve seen this movie a hundred times. The system still returns a quote, but it takes three calls to engineering and the price needs a manual adjustment no one can fully explain. The clever scripts that once saved time now block change. You feel it in your release cycles, in pricing exceptions, in the way new hires avoid the tool and go straight to Excel.

So Cytiva did the hard thing most companies postpone. They didn’t patch it. They rebuilt the CPQ foundation. Why? Because keeping a custom system alive is not the same as keeping the business moving.

CPQ doesn’t fail loudly. It fails quietly - through workarounds.

The Hidden Cost of Custom

We like to blame the UI, the performance, or the next integration on the roadmap. Those are symptoms. The root cause is almost always the same: logic is buried in code and people, not expressed where it can be tested, explained, and changed without fear.

Custom configurators tend to ossify because their logic is entangled with presentation and process. A subtle product rule turns into a JavaScript snippet. A pricing policy becomes an undocumented exception table. Ownership blurs. Every change feels risky. The hero admin who knows the edges is now your most fragile dependency.

I’ve sat in too many steering meetings where the debate is framed as “migrate or maintain.” That’s the wrong question. The real question is: do you have a product truth that the business can evolve, or a set of shortcuts the team is afraid to touch?

Every rule you add is a tax on future change.

According to Gartner discussions with manufacturers, technical debt is no longer just an IT concern. It’s a commercial drag. When the product strategy wants modularity, but the system enforces monoliths, you pay with lost velocity, not just maintenance hours.

CPQ is not about automation - it’s about correctness. If your foundation can’t guarantee that what’s sold can be built, priced, and delivered, faster clicks only scale mistakes.

Why This Moment Is Different

Rebuilding a CPQ foundation is not an act of faith; it’s a response to what’s already shifting.

First, product portfolios have gone modular. The old comfort of big, static catalogs has given way to option-rich platforms and regional variants. Rules need structure and intent, not patches.

Second, pricing is now a learning game. You won’t get it perfect on day one. You need a foundation that creates transparency and feedback loops. Perfect pricing is a myth - learning systems win.

Third, AI is entering the sales stack, but it doesn’t replace logic - it depends on it. Without constraints, AI gives fluent guesses. With explicit, testable rules, it becomes a reasoning assistant that explains choices and drafts documentation. The future of CPQ is hybrid intelligence: human judgment, explicit logic, and AI working together.

Finally, governance has moved from “project overhead” to the way you scale change. You can’t run quarterly product updates through hero admins and hope the field complies. Explainability is trust. If the system cannot explain itself, it will never be trusted.

If Excel is still the fastest path to a correct quote, your CPQ isn’t finished.

Practical Rules for a Clean CPQ Foundation

When teams like Cytiva draw a line and rebuild, the winners don’t start with tools. They start with guardrails. Here are rules I use on live programs.

  • Start with a map, not a migration. Document the product truths you need the system to protect - compatibility, performance ranges, regulatory constraints, pricing policies. Express them as simple, composable rules you can test. Example: “If flow rate exceeds X, valve type must be Y.” Not a code comment, a rule you can read aloud.
  • Separate product truth from presentation. Logic, data, UI, and workflow must be decoupled. A change in a selection screen should not require touching pricing rules. A change in price guidance should not alter the configuration flow. Anti-pattern: the Franken-configurator, where everything lives in one brittle script.
  • Make explanations first-class. Every constraint and price adjustment should be able to show its reasoning. If a discount caps at 12%, sales should see the policy and the inputs. If a component is invalid, show the rule and the alternatives. This is how you replace the hero admin with the system.
  • Model with the smallest useful pieces. Use modules, attributes, and constraints that can be reused. If a rule needs a paragraph to explain, split it. Rule spaghetti is not a sign of complexity - it’s a sign of poor structure.
  • Govern for change velocity. Measure lead time for logic changes, not just quote time. Build a sandbox, tests, and a release cadence that the business can trust. Anti-pattern: lift-and-shift migration, where old debt is reproduced in a new UI and declared done.

These sound simple because they are. The hard part is holding the line when old habits try to sneak back in: Excel price overrides, silent exceptions, quick repairs coded by one person on a Friday night.

So how do you start without turning this into a multi-year freeze? A rebuild should accelerate learning, not stop it.

Pick a product slice and go live early. Choose a high-volume subset where errors are costly and learning is fast. Launch with full correctness and explainability, even if some edge options remain manual. Use the live slice to prove the guardrails and tune governance.

Create a test harness before you write rules. Collect 50-100 real configurations and prices that represent today’s business. Turn them into executable tests. Every change runs the suite. This makes the conversation objective and safe. When someone asks “what breaks if we change this?”, you have an answer.

Run CPQ and reality in parallel for a month. Dual-run a segment. Compare quotes produced in the new foundation with those produced by existing methods. Close gaps deliberately. This exposes hidden policies, undocumented rules, and the places where you need to choose simplification over nostalgia.

Make ownership explicit. Name owners for product logic, price policies, and process. Not a committee - single points with a queue and SLA. Adoption is the only metric that matters. If the field still routes around the system after two sprints, ask why and fix that first.

I’ve watched teams try to keep their custom systems alive with heroics while competitors standardize and scale. The difference shows up as compounding advantage. Clean logic reduces change cost, which makes faster updates safe, which drives adoption, which gives better data, which improves pricing, which funds more capability. The loop gets stronger.

The opposite is quiet failure. Each month another exception is added to the pile. Another specialist becomes the only person who can explain a rule. Another region gets a private price sheet. Nothing crashes. You just slow down until change feels impossible.

Governance isn’t overhead. It’s how you scale change without breaking sales.

What Cytiva did is what many industrial and life sciences companies will need to do: move from bespoke scripts to a backbone. Not because vendors say so, but because product strategy demands it. Modular portfolios, evolving regulations, and expanding channels are not compatible with fragile logic and hero dependencies.

It’s like structural beams in a building. You don’t admire them during the tour, but they decide whether everything else stands. A CPQ foundation built on explicit, tested rules is invisible on good days and priceless on bad ones.

There’s a point where maintaining the old system looks cheaper but costs you more. If you feel your configurator setting the speed limit on strategy, you’re there. The rebuild isn’t about technology pride. It’s about restoring the ability to change on purpose.

The fastest quoting process is the one sales trusts.