The migration itself: sequencing a move off CPQ

The decision is made. Someone has signed the case, the licences are on an order form, and the question has changed from whether to how. That second question fails differently to the first, and this is about the second one.

If the decision is not actually settled, start with Eight questions to answer before you move off Salesforce CPQ and come back. Nothing below re-argues it.

One correction before anything else, because it changes how a programme is justified. Salesforce publishes both Salesforce CPQ and Revenue Lifecycle Management as current products, and its own pages state no end date for CPQ. A good deal of third-party writing asserts otherwise. If the urgency in your business case rests on a retirement date, confirm that status directly with Salesforce or your account team rather than with a blog post, because a programme justified by a date that turns out not to exist loses its sponsor the moment somebody checks.

#What moves, what gets rebuilt, what stays where it is

Sort everything into three piles before a single story is written. Teams that skip this carry the whole old system into scope by default.

Moves. Active contracts and subscriptions that can still be amended, open opportunities carrying a live quote, and the account and product references those records genuinely need. This pile is smaller than anyone expects.

Gets rebuilt. The catalogue, price books, discount schedules, price rules, product rules, approval matrices, guided selling and quote templates. None of these migrate in any useful sense. They are re-expressed in a different model, which is a different activity with a different skill set and a much longer estimate.

Stays where it is. Everything closed. Won and lost quotes, superseded versions, historical approval trails, the eleven revisions of a 2019 renewal that nobody will ever open again.

The line between pile one and pile three is where most of the argument happens, and it is worth having properly.

#Historical quotes are a retention problem, not a migration item

The instinct to migrate quote history is reasonable. Nobody wants to be the person who says the old data has gone. The implementation of that instinct is what does the damage.

Ask what question is being asked of the old records, because each version has a cheaper home than the new object model. Looking up what a customer was quoted three years ago is answered by read-only access to the old system. Trend reporting on bookings is answered by an extract into the warehouse, where it belongs anyway because the numbers already span more than one system. Legal and audit retention is answered by an archive with a documented policy. Only the ability to amend something still live is genuinely a migration requirement, and that is a small population you can count.

What makes historical quotes expensive is not row volume. It is the dependency graph behind the rows. A 2019 quote line points at a product, a price book entry, a discount schedule and a bundle structure that will not exist in the rebuilt catalogue. Migrating the quote so that it still renders correctly means migrating the catalogue that gave it meaning, which means keeping a shadow version of the old commercial model alive inside the new one, purely so that dead records display. That is how a migration doubles: through the dependencies, not the data.

#The catalogue rebuild is the project

Everything else in this article is scheduling. The catalogue is the work.

It is also the one artefact where a faithful port is both technically possible and strategically wrong, which is exactly the combination that gets it approved. A catalogue that has been in production for a decade is a sediment of individually rational decisions. A product created because one customer wanted different wording on an invoice. An option that exists so a bundle could be sold in one region. Three separate records for the same thing at different price points, because a discount schedule could not express what the deal needed. None of those were mistakes at the time. All of them are now carried by people who did not make them.

Port it faithfully and every one of those exceptions arrives on day one in the new system, along with the constraint that caused it, minus the person who remembers why.

Rebuild it instead from the commercial model down. Start from what the business sells today, described in the words the business uses, then ask of each line: is this a product, a variant, an option, or a pricing outcome? A meaningful share of legacy product records turn out to be pricing outcomes that were forced into product records because the old configuration could not express them any other way. Those do not need to be recreated at all, and recognising them is where a rebuild starts to pay for itself.

The structural choices made here are the ones you will live with, and several of them are expensive to reverse once quotes exist against them. That is the same class of decision covered in the data model decisions you cannot cheaply undo, and the catalogue is where they concentrate.

#Price rules: re-derive the intent, do not translate the logic

The rule list is the most dangerous artefact in the migration, because it is the one that looks portable. Every rule has a readable condition and a readable action. What is not readable is why it was written, what it interacts with, and whether it is still supposed to fire.

A like-for-like port carries all of that forward, including the interaction effects. Rules that only produce the right answer because another rule fires first. Rules that were disabled in effect years ago by a condition that can no longer be true. Rules that exist to correct the output of a different rule that should simply have been changed. Translated faithfully into a new engine, those relationships break in ways that are difficult to attribute, because you are now debugging logic in a system you have never seen it work in.

The alternative is to work backwards from behaviour. Take a representative set of real quotes with known outcomes, historical ones, across segments and deal shapes. For each, record the price that came out and the price the business would defend today. Then write rules in the new model that produce that, and test against the same quotes. You are re-deriving intent from evidence rather than translating an implementation, and the artefact you finish with is a documented pricing policy, which the business has probably never had in one place.

#The parallel run: one full quoting cycle, minimum

A fixed fortnight is a countdown, not a parallel run. The unit is a complete quoting cycle, meaning at least one of everything the business actually does: new business, an amendment, a renewal, a co-term if you have them, and one deal that travels the full approval chain instead of being waved through.

What you compare, in order of how often it catches something:

The number. Quote the same deal in both systems and reconcile line by line, not on the total. A discrepancy of a few cents is worth chasing, because it usually indicates a rounding, proration or tier boundary rule behaving differently, and that difference will reappear later on an invoice with a customer attached.

The document. The output the customer actually receives. Terms, ordering, grouping, what appears on page one, how a discount is described. Legal frequently has opinions about wording that nobody had recorded as configuration.

The downstream record. What the order, contract, asset and billing hand-off look like once the quote is accepted. Quoting migrations are judged on the quote and fail on what the quote produces, which is why the quote to cash chain past the quote belongs in the comparison rather than in a later phase.

Have sellers do the quoting, not the project team. A consultant quoting in the new system finds the differences a consultant thinks to look for, which are not the ones that generate incidents.

#Cutover happens on a date the business chooses

The project does not own this date. A quoting system is either unavailable to sell on during cutover or, worse, briefly available in two versions, and both of those have a commercial cost that varies enormously by week.

The wrong shapes are easy to name. The last week of a quarter, when every seller is closing. The first week of a new fiscal year, when finance is closing the old one and sellers are unfamiliar with the new system at exactly the moment they are least tolerant of it. The week a large, visible deal is due to be signed.

The right shape is whatever the trough of your own quoting rhythm is. Ask sales operations to plot quotes created per week across the last two years and pick a low point. That chart takes about an hour and settles an argument that otherwise runs for weeks on opinion.

Then plan the freeze properly, because cutover is not one moment. There is a date the old system stops accepting new quotes, a later date it stops accepting edits to existing ones, and a date it becomes permanently read-only. Those are three decisions. Teams routinely plan one and improvise the other two.

#In-flight quotes and contracts

This is the detail found late more often than any other, and it is not technically difficult. It is simply nobody's job until it is urgent.

At the moment the old system freezes, a population of records exists that is neither closed nor fresh. Each state needs a decision taken in advance and written down where finance can see it.

A quote sent under the old system and signed after cutover. Does it get recreated in the new system to produce the order, or does the old system complete that one transaction? Both are defensible. Only one can be true, and revenue recognition depends on which.

A quote sitting mid-approval. Approval state rarely carries across in any meaningful way. The cleanest rule is usually that anything not approved by the freeze is requoted, stated early enough that approvers can clear their queues.

A part-processed amendment against a live contract. This is the worst case, because contract state is mid-change and the record is coherent in neither system. Finish them or reverse them before the freeze. Do not carry one across.

An unsent draft. The seller recreates it. Say so weeks ahead, because the seller sitting on a large draft should not learn this on the day.

#The migration checklist

This is the working list. Each workstream has a definition of done someone can actually assess, and a failure that follows from skipping it.

#The order we run it in

Scope split first, because it sizes everything else. Catalogue rebuild next and long, running alongside the pricing intent work, since the two constantly inform each other and neither finishes without the other. Integrations and reporting continuity run in their own lane throughout, because they depend on different people and stall for different reasons. Parallel running starts only when the catalogue is stable, never against a moving one, or you cannot tell whether a discrepancy is a defect or a change. Freeze, in-flight decisions and cutover are the last fortnight, and they are the only part of the sequence with a fixed date.

The shape of the destination matters as much as the sequence, and the choices that set it are worth making deliberately rather than inheriting. Those are covered in Revenue Cloud: the decisions that set the shape of everything after.

The programmes that go badly are rarely the ones that hit a technical problem. They are the ones that treated a rebuild as a port, and then found out during parallel running, when there was no schedule left to absorb it.