Most CPQ migration estimates start the same way. Count the products. Count the bundles. Count the price rules. Multiply by something, add a buffer, quote a number.
It’s the wrong unit.
Two orgs with 400 products each can be a six week job and an eight month job. Volume isn’t what separates them. What separates them is how much of the pricing logic lives in code that nobody at the company can explain anymore.
There’s almost always a calculator script written by a consultant who left in 2020. It does something clever with a discount schedule. Four customers depend on it, nobody knows which four, and it has never been documented. That script is worth more of your estimate than three hundred products are.
Sort by fate, not by type
Counting objects tells you how much there is. It doesn’t tell you what any of it will cost to move. Before committing to a plan, sort every item by what will actually happen to it:
Carries across on its own. Read, translated, loaded. Nobody touches it. Most of your catalog usually lands here, which is why counting products makes estimates look optimistic.
Needs a person to look at it. It came across, but somebody who understands the intent should confirm it landed the way you meant. Cheap individually, expensive in bulk.
Someone has to rebuild it. The intent has to be reconstructed by a person who understands why it existed. This is where migrations actually get expensive, and it’s usually a small fraction of the item count.
Outside the migration. Doesn’t come across at all. This bucket has to be named out loud rather than quietly dropped, because somebody is depending on it and would rather find out now.
Put hours on each item, not a total. The total hides the exact thing you need to see. A project that’s 90% automatic and 10% rebuild can still be mostly rebuild by hours, and the total will never tell you that.
Say the rebuild pile out loud early
The rebuild bucket is a scoping conversation while you’re still planning. It’s a much worse conversation as a status update in month three.
Every bad migration I’ve seen had the same shape. The estimate was built on volume, the hard items surfaced late, and by then the timeline was public and the budget was approved. Nobody made a bad decision. They made an early decision with the wrong information.
Then verify the prices
Here’s the step that gets skipped: recalculate the migrated quotes against the original pricing, line by line, before anyone relies on the numbers.
Not a sample. Not the ten quotes somebody picked. Run the real ones and compare the output to what the old system produced for the same inputs.
Pricing logic is where translation errors hide, because a rule that moved across cleanly can still evaluate differently once the rules around it changed order. The math looks fine. The total is off by 3%. Nobody notices until a customer does.
If prices moved, you want to find it in a test. Not in a renewal conversation.
The pattern doesn’t change
Nine years in CPQ, going back to the Steelbrick days, and this hasn’t changed once: migrations don’t fall over on the products. They fall over on the logic nobody wrote down.
The good news is that this is knowable up front. The information is sitting in the org right now. It just has to be read and sorted before somebody quotes a timeline, rather than discovered halfway through delivering one.
Sadorra’s migration engine does this reading automatically: it reports every item as Automatic, Review, Expert or Outside the migration with hours attached, and recalculates migrated quotes line by line against original pricing. How migration works.