# Who to hire for SteelBrick on Salesforce SteelBrick is Salesforce CPQ, and the hire depends on which of four situations you are in: stay, tidy, migrate in stages or start fresh in Revenue Cloud. **Published:** 2025-11-18 **Canonical:** https://synconai.com/hire-steelbrick-salesforce-partner **Author:** SynconAI Architecture Team ## In short Decide which situation you are in before you hire: keep your Salesforce CPQ org, tidy it, migrate in stages, or start new business in Revenue Cloud. Then hire someone fluent in the SBQQ quote model who can describe your quote line from memory. Salesforce stopped selling CPQ to new customers in March 2025, but existing orgs keep running. ## Sources - **The ultimate guide to Salesforce product rebrands** (retrieved 2026-10-10) https://gearset.com/blog/salesforce-product-rebrands/ > Steelbrick, acquired in 2016, was renamed Salesforce CPQ, though the metadata still references its origins with SBQQ prefixes. Salesforce CPQ is now in an end-of-sale (EOS) phase as Salesforce offers new customers Revenue Cloud Advanced and Revenue Cloud Billing. - **CPQ Migration | Salesforce** (retrieved 2026-10-13) https://www.salesforce.com/sales/cpq/migrations/ > The goal is a stronger revenue model, not a screen-by-screen rebuild. - **CPQ Migration | Salesforce** (retrieved 2026-10-13) https://www.salesforce.com/sales/cpq/migrations/ > Route new business to RCA while existing CPQ contracts run to renewal, reducing Day 1 risk without delaying modernization. - **CPQ Migration | Salesforce** (retrieved 2026-10-13) https://www.salesforce.com/sales/cpq/migrations/ > Move existing CPQ configuration and data into RCA with minimal redesign when speed, continuity, and business parity matter most. ## What to take away - SteelBrick is Salesforce CPQ. Its metadata still carries the SBQQ prefix, so the partner must be fluent in that quote model before anything else. - Salesforce stopped selling CPQ to new customers in March 2025. Existing orgs continue, and Salesforce describes staged migration paths to Revenue Cloud. - Four situations drive four different hires: stay as you are, tidy and stabilise, migrate in stages, or start new business in Revenue Cloud. - A first engagement is a quote-line and pricing-logic inventory, not a build, with a written recommendation on which situation you are in. ## The guide Hiring for SteelBrick looks easy until you notice that the product changed names, stopped being sold to new customers and acquired a successor, all while your sales team kept quoting. A buyer who writes "SteelBrick partner" into a brief is usually in one of four situations, and each one calls for a different person. This page works through the four, sets out the skills that apply, and gives you questions to expose a weak candidate. It does not rank firms, and it leaves the project price to [SteelBrick implementation cost](/steelbrick-salesforce-implementation-cost). ## What you are actually hiring for Salesforce's rebrand record gives the history in one sentence, which is worth reading for what it implies about the metadata: SteelBrick, acquired in 2016, was renamed Salesforce CPQ, "though the metadata still references its origins with SBQQ prefixes." Every quote, quote line, price rule and product rule in your org sits in that SBQQ namespace. A partner who has not worked in it will fumble the first week. The main skills are specific: - The SBQQ object model: quotes, quote lines, quote line groups, subscriptions and the way an amendment or renewal copies and mutates data. - Price rules, product rules, option constraints and the order in which the pricing calculator applies them. - The calculator plugin, a JavaScript hook that many mature orgs use to apply custom logic, and which is a risk when nobody remembers why it exists. - Quote templates and document generation, which are often the visible product of the whole system. - Approvals, including advanced approvals if installed, and discount governance. - Billing and order handoff where applicable, plus integrations to ERP and finance. Salesforce lists a Platform Administrator credential on Trailhead, and generalist developer credentials exist, but we could not confirm a current CPQ-specific credential name while preparing this page. Do not accept a badge in place of evidence. Ask each candidate to walk through a pricing rule they wrote and explain what happens when two rules disagree. ## The four situations **Situation one: stay as you are.** The org works, the team is competent, and the only issue is that nobody wants to touch it. You do not need a migration partner. You need a steward, perhaps a small retained capacity, who can fix bugs, change a price list and train a new administrator. The hire is someone senior in CPQ who is happy not to rebuild anything. **Situation two: tidy and stabilise.** The org is old. Rules overlap, templates are duplicated, and the calculator plugin does things nobody can describe. The hire is an auditor-builder: someone who can read your configuration, retire what is dead, document what remains and leave you with a smaller, safer system. This is also the right preparation for any later move, because you cannot migrate something you cannot describe. **Situation three: migrate in stages.** Salesforce stopped selling CPQ to new customers in March 2025, and its migration page describes several paths. One is a lift: "Move existing CPQ configuration and data into RCA with minimal redesign when speed, continuity, and business parity matter most." Another is a bridge, which Salesforce describes this way: "Route new business to RCA while existing CPQ contracts run to renewal, reducing Day 1 risk without delaying modernization." The page abbreviates the upper Revenue Cloud edition as RCA, and it adds a sensible warning: "The goal is a stronger revenue model, not a screen-by-screen rebuild." The hire here needs to have designed a target model, not only to have exported data. Salesforce also names rollout patterns such as pilot-first and cohort-based, which suit an organisation with several selling motions. **Situation four: start new business in Revenue Cloud.** You launch a product line or business unit on the new platform, and leave existing CPQ contracts to run to renewal. The partner needs the upper Revenue Cloud edition's catalogue and pricing design skills, and enough CPQ knowledge to build a clean bridge between the two. It is a design hire more than a migration hire. | Situation | The hire | First deliverable | What to refuse | | --- | --- | --- | --- | | Stay as you are | A senior CPQ steward on a small retainer | A named owner for every rule and template | Any rebuild proposed without a defect to fix | | Tidy and stabilise | An auditor-builder who documents as they go | Inventory of live and dead configuration | Deleting SBQQ metadata unrecorded | | Migrate in stages | A designer of the target model, plus a migration lead | Chosen path and a pilot scope | A lift of configuration nobody has read | | New business in Revenue Cloud | A catalogue and pricing designer who knows CPQ | A bridge between old and new quotes | Forcing existing contracts onto the new platform early | Write your situation at the top of the brief. A firm that cannot tell which one you are in, or sells you situation three when you are in situation one, is selling its own capacity. ## Quotes in flight and the cutover Whatever path you choose, the hardest day in a CPQ project is not go-live, it is the week either side of it. Sellers are mid-negotiation. Customers hold quotes with expiry dates. Contracts have amendments pending and renewals approaching. A partner who has done this before will ask about these before they ask about the new data model. Ask how they would handle a quote created on the old system that the customer accepts after cutover. The acceptable answers are specific: finish it where it started, or copy it with a reconciled total and a clear audit trail. Be wary of any answer that relies on sellers recreating quotes by hand, because the discount they remember will not be the discount that was approved. Ask how they would reconcile. A sound plan compares quote totals, line counts and subscription values between the two systems for a sample period, and agrees tolerances in advance. Ask who signs off, and whether finance is in the room. Ask what happens to renewals. Salesforce describes the bridge pattern as new business on the new platform while contracts run to renewal, and the practical question is what happens when a renewal arrives. Does it renew on the old system, or is it converted at renewal? The answer affects pricing, because a renewal often inherits contracted prices that the new catalogue must reproduce exactly. Partners who can describe this have probably lived it. Finally, ask about training and the first month. Sellers rarely complain about architecture. They complain when the quote document looks different or an approval takes longer. A plan with support in the first weeks, a named person for sellers to call and a quick route to fix a template will protect revenue better than any technical elegance. ## A first engagement worth buying Whatever situation you are in, begin with an inventory, not a build. It runs a few weeks and produces four things. 1. A list of live quote lines by product family, showing which are in use and which are dead. 2. A catalogue of price rules, product rules, approval rules and plugin logic, each with a plain-English description and an owner. 3. A map of integrations: what reads quotes, what writes orders, and what depends on SBQQ field names. 4. A written recommendation naming your situation and the next step, including the option to do nothing. Pay for it separately and keep the right to stop. If the inventory is poor, you will know before you commit to a migration. If it is good, you have the beginnings of a migration design, and a target-state conversation grounded in facts. Read [should I migrate from SteelBrick](/should-i-migrate-from-steelbrick) before you go further, because the decision to move is a business decision with its own considerations, and [integrating SteelBrick with Salesforce](/integrating-steelbrick-with-salesforce) covers the connectors that often turn out to be the real constraint. ## Red flags specific to this product **A switch-off plan with a date.** CPQ orgs do not need to be turned off because Salesforce stopped selling to new customers. Be wary of any proposal that treats a sales phase as a deadline for you. **A plan to delete SBQQ metadata.** The prefix looks old, but it is how your quotes work. Deleting it removes your live quoting system. **A lift with no inventory.** If a proposal moves your configuration across before anyone has read it, you will carry every historical mistake into the new platform. **Confusing products.** Industries CPQ is a different product from a different acquisition. If a candidate blurs them, they are not working from your org. **A catalogue redesign by default.** Salesforce's migration page distinguishes minimal redesign from selective transformation and full rationalisation. Redesign has a cost and a risk. A partner should be able to explain why your situation calls for it. **No plan for quotes in flight.** Open quotes and amendments straddle any cutover. Ask what happens to a quote created on Friday and amended on Monday. ## Ten questions for the first call 1. Which of the four situations do you think we are in, and what would change your mind? 2. Explain how a quote line is priced in our org, and where a custom calculator plugin would intervene. 3. How do you document price rules so a new administrator can read them? 4. What have you retired from a CPQ org, and how did you prove it was dead? 5. How do amendments and renewals copy data, and what goes wrong? 6. What would you do about open quotes during a cutover? 7. How do your designs treat contracted prices and subscriptions? 8. Which parts of our integrations depend on SBQQ field names? 9. If we pilot a new Revenue Cloud product line, what is the bridge to the old one? 10. What would you recommend we leave alone? A person with real experience answers number four with a specific story and a proof method, such as a report of last-used dates. A weak candidate answers in generalities. ## Checking references and evidence Ask for a reference from a finance or sales operations lead who ran quotes after the project. Ask how long quote creation took before and after, and whether discounting rules were easier to explain. Ask what the team would do differently. Ask for a sanitised pricing-rule document. Good CPQ work leaves documentation of precedence, because that is where disputes happen. A firm that cannot show one may not have written one. Ask a named consultant to review one of your rules live. A person who has worked in the object model can usually find an issue in minutes. ## Commercial models and the statement of work A fixed fee suits the inventory and recommendation. A phased fixed fee with gates suits a staged migration, where each stage has its own acceptance criteria. Time and materials with a cap suits the cleanup in situation two, because the scale of dead configuration is unknown. A retainer suits situation one. The statement of work should name the org, the product lines and the quote templates in scope. It should state that the existing quoting system stays live unless you have signed a cutover plan, and that no metadata is deleted without a written inventory entry and your approval. It should require documentation of every rule changed, a rollback plan, a data migration test with reconciliation of quote totals, and a handover. Add a clause that keeps SBQQ-dependent integrations in scope for testing. Licence matters are on [the SteelBrick licence page](/steelbrick-salesforce-licence-cost) and the history is on [what happened to SteelBrick](/what-happened-to-steelbrick). Salesforce's own migration guidance is at [CPQ migration](https://www.salesforce.com/sales/cpq/migrations/). ## When you can skip a partner If you have an administrator who knows your pricing rules and the change is a price list update, a template tweak or a new approval step, do it in-house. If the org is stable and you plan no new product lines, a partner is a luxury. Bring one in when nobody understands the pricing logic, when a migration is on the table, or when you are launching a product line on Revenue Cloud and need a design you can defend. ## Questions ### Is SteelBrick the same as Salesforce CPQ? Yes. SteelBrick was acquired in 2016 and renamed Salesforce CPQ, and its metadata still uses the SBQQ prefix. Hire for the SBQQ quote model, price rules and calculator plugin, and be careful not to confuse it with Industries CPQ, which is a different product. ### Do we have to move off CPQ now? No. Salesforce stopped selling CPQ to new customers in March 2025, but existing orgs continue to run. Its migration page describes staged paths, including running new business on Revenue Cloud while existing contracts run to renewal. Move for business reasons and on your own timetable. ### Which skills should a CPQ partner have? Fluency in the SBQQ objects, price and product rules, the calculator plugin, quote templates and approvals, plus experience with amendments and renewals. We could not confirm a current CPQ-specific credential name, so ask for a live walk through a pricing rule instead of relying on a badge. ### What should a first CPQ engagement deliver? An inventory of live quote lines, a described list of rules and plugin logic, a map of integrations that depend on SBQQ fields, and a written recommendation naming your situation. It should be paid separately so that you can stop if the quality is poor. ### Can we skip a partner for CPQ work? Yes for routine changes by someone who knows the rules: price list updates, template edits or an extra approval step. Hire help when nobody understands the pricing logic, when a migration to Revenue Cloud is planned, or when a new product line needs a defensible design. --- SynconAI is a Salesforce Select Partner and an OpenAI Select Partner, delivering architect-led Salesforce and AI programmes across the United States and Australia. Related service: Revenue Cloud (https://synconai.com/salesforce-revenue-cloud-advanced).