Salesforce CPQ Migration Checklist: 8 Phases

Moving off Salesforce CPQ happens in phases, not with a single switch. Salesforce stopped selling new CPQ licenses in 2025, but it has not announced an end-of-life date. That leaves you time to plan your Salesforce migration process carefully.

There are eight phases. You start with an assessment of what you actually use in CPQ, then choose a destination: Revenue Cloud (formerly Agentforce Revenue Management) or a third-party CPQ.

Next comes mapping objects, fields, and pricing to the new model, followed by a data migration that moves records with their relationships intact.

Phase 5 seeds a realistic sandbox so you can run a full test cutover, and Phase 6 is the release itself, deployed with a rollback plan you’ve already tested.

Validation comes seventh, where you check outputs and reconcile the old system against the new one.

The last phase decommissions CPQ and puts governance around the new model.

None of these phases favors a vendor. They’re about execution, and the approach is the same if you land on Revenue Cloud or on a third-party CPQ. In a regulated cutover, those stages decide if the transition is safe and if data integrity holds for the whole project. For a broader view of the available options and how to sequence them, check out the Salesforce migration guide.

The 8-phase checklist

A CPQ migration succeeds stage by stage, from assessing your current setup to governing the new platform after launch. The checklist below sums up the eight key phases: what each one should achieve, the work involved, and what you risk by skipping a step.

Is Salesforce CPQ actually going away?

There’s no deadline you can circle. Salesforce moved CPQ to end of sale in 2025, so new customers can no longer buy CPQ licenses. It hasn’t announced an end-of-life date, though, and existing orgs remain supported.

Support isn’t disappearing either. Salesforce supports releases during its standard maintenance window, and its published policy says a product remains supported until it’s more than two releases behind the current generally available version (Salesforce Help article 000380904). In practice, you’re not standing on the edge of a cliff, so there’s no reason to panic-migrate.

That distinction matters, because the pressure to hurry comes from vendors, not from the calendar. Rush a Salesforce migration and messy configuration gets carried over, testing gets skipped, data quality suffers, and the cutover can leave your sales team unable to produce quotes.

Treat it as a planned migration project and scope it on its merits. Move carefully, finish cleanly, and keep the room Salesforce has given you. The goal isn’t simply moving data from one system to another. It’s a smooth transition that protects business operations, customer data, pricing logic, and the integrity of your Salesforce environment.

Why you can't simply lift and shift CPQ

No button copies CPQ into a new platform. A CPQ migration is really two jobs running at once: rebuilding the quoting logic and moving the data.

Re-implementation covers everything that defines how quoting works. That means product and price rules, discount schedules, approval thresholds, bundle structures, Quote Calculator Plugin (QCP) scripts, and templates. None of it transfers as records. It has to be rebuilt inside the target platform’s model, where pricing, rules, and bundles are almost always structured differently from CPQ.

Even Salesforce’s migration documentation, which identifies four paths (Lift and Shift, Selective Transformation, Full Rationalization, and New Business Unit), describes “Lift and Shift” as rebuilding quoting logic on the new architecture. It isn’t a literal copy of your CPQ configuration.

Data migration is the other half of the work. Products, price books, active quotes, subscriptions, assets, and approvals all move as records, and their relationships have to stay intact. That’s why data mapping, data transformation, data loading, and data validation are essential parts of the Salesforce data migration process.

Copy the old configuration wholesale, mess and all, and every zombie rule and dead SKU comes along into the platform you just paid to set up. Make this clear to stakeholders now: you’re rebuilding the logic and migrating the data, not photocopying an org.

The 8-phase Salesforce CPQ migration checklist

Phase 1: Assess what you actually use

You can’t migrate what you haven’t inventoried. Build a full catalog of everything CPQ touches: products, price books, price rules, product rules, discount schedules, approvals, QCP scripts, quote templates, and every integration that reads or writes CPQ data. The same data assessment should document your data sources, Salesforce objects, custom objects, custom fields, and existing integrations, plus where the authoritative version of each record lives. If the Salesforce org exchanges information with legacy systems, another Salesforce CRM environment, Service Cloud, ERP software, or multiple systems, put those dependencies in the inventory too.

Then separate what’s actively used from what simply exists. Long-standing CPQ orgs tend to collect zombie rules that no longer fire, discount schedules nobody remembers, dead SKUs that haven’t sold in years, and duplicate records that drag down data accuracy. Flag all of them.

For each object, decide whether to migrate it, rebuild it, or leave it behind. Identify its source of truth as well, so two teams don’t migrate separate versions of the same thing. This is also the right point for data cleansing and data deduplication. Clearing out obsolete or duplicate data before migration improves data accuracy and cuts down the unnecessary existing data you’d otherwise carry into the new system.

The assessment doubles as your scoping tool. The length of the “must rebuild” list, not the raw record count, tells you how long the project will take and how much re-implementation Phase 3 involves. Record count still matters, though. Large data volumes affect migration tooling, sequencing, test duration, and the time needed for data loading and validation. A strong assessment is one of the foundations of a successful Salesforce data migration, because it settles what needs to move before anyone starts transferring data.

Phase 2: Decide your destination

Now decide where you want to land, and decide on merit. Salesforce positions Revenue Cloud as the successor to CPQ, which makes it the natural target for many orgs. A third-party CPQ is just as valid. This checklist applies either way and isn’t meant to steer you toward one option.

Score the candidates on three measures: quote-to-cash complexity, total cost of ownership, and timeline. Be candid about missing features on both sides. Revenue Cloud handles some concepts differently from CPQ, and a third-party tool might offer a capability Revenue Cloud lacks, or miss one you depend on. Record every gap. In the next phase, each one becomes either a mapping issue or a re-implementation task. Your destination affects what you build, not the phases you follow.

Phase 3: Map objects, fields, and pricing to the new model

This is where the migration gets concrete. Build a field-and-object map from the old model to the new one, working through each object and then each field. For every CPQ object you selected in Phase 1, find its counterpart on the target platform and document how each field carries over.

The data mapping should account for standard Salesforce objects, custom objects, custom fields, record relationships, expected data formats, and any transformation needed before the target can accept the data. Where source and target structures differ, write down the required data transformation instead of relying on ad hoc changes during migration execution.

Two issues tend to cause trouble. Bundle hierarchies come first: when the target system restricts nesting depth, flatten the bundles before migration rather than trying to fix them afterward. Pricing and approvals are the other. Check each approval threshold and discount rule so the margin logic survives the move. If a discount rule fails to carry over and nobody notices, a deal can get approved that should have been blocked.

Pricing calculations need the same careful mapping as the records. Accurate data transfer isn’t enough on its own if the business logic around that data changes unexpectedly. For a detailed version of this work, see how to map CPQ objects and fields to the new model.

Phase 4: Migrate the data with its relationships intact

Once the map is built, migrate the data: products, price books, active quotes, subscriptions, assets, and approvals. Referential integrity is the one requirement you can’t negotiate on. CPQ data forms a chain that runs from quote to quote line, then to product and price book. Move a parent without its children, or load a child without its parent, and you get orphaned records and broken quote history. Keeping those relationships intact from start to finish is central to data integrity, and it’s what prevents data loss and data corruption during the Salesforce data migration process.

Here’s the catch: a migration can import data without a single error and still be wrong. Accurate data transfer means more than successful record creation. It has to hold at the field, object, and relationship level, and the data has to keep its business meaning.

The specific mechanism depends on the project. A data loader can be the right fit for a straightforward Salesforce data import or a smaller dataset, but relational CPQ migrations usually need tooling and sequencing that understand the dependencies between Salesforce objects. Whatever approach you pick, migration execution should document the data import order, transformations, validation rules, failure handling, and recovery procedures.

PII has to be masked before regulated data leaves production. Names, contact information, account details, and other sensitive data carried in quote records don’t need to appear in cleartext in a downstream org, least of all in a regulated shop. This isn’t optional polish. Masking and strict security protocols are what keep the migration inside your compliance regime and protect data security while customer data is being transferred.

Data backups belong in the migration plan as well. Before a production migration, take appropriate backups or establish a recoverable source state, so a failed data import or an unexpected transformation can’t permanently compromise existing data.

CPQ vendors often reduce this phase to a single bullet, since safely moving data isn’t what sells their platform. Yet this is exactly where a regulated migration can fail. The work is unglamorous, and it depends on a purpose-built tool that can migrate Salesforce data with referential integrity and mask PII before transfer. A smooth data transfer depends on data integrity, not raw speed.

Phase 5: Seed a sandbox and run a test cutover

Never let production be the first environment where the migration runs. Set up a sandbox that mirrors production, populate it with masked data, and rehearse the whole cutover end to end, in the exact sequence you’ll use at go-live. The test should replicate the full Salesforce data migration process as closely as possible: the same extraction, data transformation, data loading, relationship handling, validation, and release steps.

A seeded sandbox shows you things a spreadsheet never could. You find out if your migration scripts and mappings hold up against realistic volume and data shape, and you get reconciliation figures to compare, such as record counts and pricing outputs in the sandbox against the source org. If quote totals differ, you’ve caught the problem on masked data rather than in front of a customer. If duplicate records, malformed data formats, missing relationships, or inaccurate transformations turn up, the team has somewhere to fix them without disrupting business operations.

Treat this as a formal data migration test, not a technical smoke test. It should include representative data volumes, edge cases, integrations, quote calculations, approvals, reporting, and user acceptance testing.

Salesforce’s sandbox documentation explains the sandbox types and refresh behavior that make a like-for-like rehearsal possible. When you’re ready to create one, here’s how to seed a sandbox for a test cutover using masked, production-like data.

Phase 6: Release with a rollback plan

Cut over in a controlled way, with a clear path back if you need one. The bridge approach helps. New deals go to the new platform, while historical quotes stay available in CPQ as read-only records, so years of closed business don’t have to be migrated all at once. Salesforce lists Bridge among its named rollout strategies, along with Big Bang, Pilot-First, and Cohort-Based. For most regulated orgs, a bridge or cohort rollout is a better bet than a big-bang move.

Whatever cadence you choose, run the cutover as a controlled release with a rollback plan, not a manual scramble. If validation fails after go-live, there should be one clear route back to the last known-good state, not an afternoon spent reversing changes by hand while sales can’t quote.

A rollback plan protects business continuity as well as data integrity. It should say what happens if the new system prices incorrectly, data loading fails, integrations stop working, or migration execution corrupts data unexpectedly. With release management and one-click rollback, a failed cutover can become a quick, controlled recovery instead of an outage.

A deployment that technically succeeded isn’t the goal. A successful Salesforce migration is one where users keep working, data stays available and accurate, and there’s a controlled recovery path if something fails.

Phase 7: Validate outputs and reconcile

Before you trust the new platform, check that it agrees with the old one. Take representative quotes and compare them line by line, old model against new: totals, discounts, which approvals fired, and the reports built from them. If anything differs, understand why before you sign off.

This data validation should go well beyond record counts. Validate field values, parent-child relationships, calculations, data formats, integrations, reports, customer data, and business outcomes. The point isn’t that the same number of records arrived. It’s that the data is still accurate and still means what it meant.

Make it a business sign-off, not only a technical one. The people responsible for pricing and approvals should confirm the outputs reflect how deals are meant to be priced. Include user acceptance testing too, so the people who actually quote, approve, and administer deals can verify that the new system behaves correctly.

User training can start here or before release. A technically flawless data transfer still changes workflows, screens, approvals, and reporting, and training keeps that from turning into disruption.

During the bridge period, reconciliation dashboards should keep comparing source with target. That way, if drift appears three weeks in, it shows up on a dashboard rather than in a customer dispute. It’s also how you maintain data quality. Migration quality isn’t only about cutover day, so keep monitoring key records and outputs until you’re sure integrations and user activity aren’t introducing new inconsistencies.

Phase 8: Decommission CPQ and govern the new model

Retire CPQ on your own terms. Base the sunset date on the longest active contract still running in CPQ, not an arbitrary day on the calendar, and you won’t shut down a system a live deal still relies on. When the date arrives, turn off CPQ triggers and automations so nothing keeps running in the background. Then archive the CPQ data according to your retention policy instead of deleting it.

After that, govern what you built. Set up change governance for the new model so the mess you cleared out in Phase 1 doesn’t build up again. Rules go through review, new products follow the model, and the pricing logic stays clear.

This is also where post-migration support matters. Monitor integrations, user-reported issues, reconciliation results, and data quality after cutover. Ongoing support needs a defined owner and an escalation process, rather than disappearing the moment the migration project closes.

Decommission the old system cleanly, give the new one proper ongoing support, and govern what comes next. Do that, and the migration only has to happen once.

Common mistakes that derail a CPQ migration

The failures in this kind of project are predictable, which means you can avoid them. Moving a messy configuration as-is is the first. Copy outdated rules, duplicate records, low-quality data, and dead SKUs wholesale, and you bring every existing problem along and undercut the reason for migrating. Data cleansing, data deduplication, and data quality checks should happen before any data moves.

Skipping the sandbox rehearsal turns the first production migration into the test. That’s when record counts and quote totals go wrong in front of customers, so always run a representative test migration first.

Without a rollback plan, a cutover has no clear way back. One bad deploy can then turn into a quoting outage, threaten business continuity, or leave teams attempting manual fixes in the production Salesforce environment.

Migrating PII without masking it is a compliance failure that could have been avoided. Regulated and sensitive data shouldn’t go downstream in cleartext, and data security and strict security protocols need to stay part of the migration process from extraction through validation.

A big-bang cutover with no cohorting creates a different risk. If you force everything over at once instead of bridging or using cohorts, you can’t catch problems while the blast radius is still small.

Poor data mapping is another avoidable failure. Incorrect field mappings, missed custom fields, inconsistent data formats, and misunderstood Salesforce objects can produce a migration that technically completed but holds inaccurate or unusable data. Insufficient validation causes the same kind of damage. A successful import doesn’t necessarily mean a successful migration, and without reconciliation and validation, data corruption or subtle pricing errors can stay hidden until the new system is already in use.

Most of these belong to Phases 4 through 6, the stages urgency-sellers reduce to single bullets. They deserve proper weight.

How long does a Salesforce CPQ migration take?

Months, in phases. This isn’t a weekend cutover, and an honest estimate is a range rather than a single number.

A lot depends on the complexity of your catalog and pricing rules, the destination platform, the data volume, the quality of your existing data, and how many active contracts you bridge instead of moving all at once. An organization with a clean catalog, accurate existing data, and a simple pricing model can move quickly once it settles on the right destination. Larger organizations usually take longer, especially with deeply nested bundles, extensive QCP customization, large data volumes, multiple systems, complicated data sources, and strict compliance requirements.

Most of that extra time goes into mapping, sandbox rehearsal, and validation. So if someone gives you a fixed timeline before they’ve reviewed your Phase 1 inventory, they’re guessing. Assess the scope first, then set dates.

Where a migration safety layer fits

Most of this checklist is project work that doesn’t depend on a particular platform. Regulated migrations tend to fail in three places: when the data moves in Phase 4, when the process is rehearsed in a sandbox in Phase 5, and when the release goes out in Phase 6 without a reliable way back. A migration safety layer closes that gap.

Flosum doesn’t create quotes or replace CPQ. It safeguards data migration, sandbox testing, and the release process, so the platform you’ve selected, Revenue Cloud or a third-party CPQ, can go live without data being lost, corrupted, or exposed. By design, it’s neutral about the destination. Flosum isn’t a CPQ product or alternative, and your quoting logic doesn’t live there. Here’s how it maps to the phases the CPQ vendors skip.

Phase 4 is the data migration. Flosum Data Migrator moves Salesforce objects while mapping their dependencies, keeping the quote-to-line-to-product-to-price-book chain intact and masking PII before regulated data leaves production. That helps preserve referential integrity and supports accurate data transfer as sensitive data moves between Salesforce environments.

Phase 5 is about seeding and testing the sandbox. The process creates a production-like test org with masked data, so the team can rehearse the full cutover and the first real migration isn’t also the first actual run. A representative data migration test then flags problems with mapping, data quality, data formats, and relationships before production is affected.

Phase 6 covers release and rollback. Flosum DevOps moves the cutover through a controlled release pipeline, with one-click rollback available if validation fails. That gives the migration project a recovery mechanism and helps protect business continuity during migration execution.

For organizations governed by HIPAA, SOC 2, DORA, GxP, or 21 CFR Part 11, the real safety question is whether the CPQ vendor and migration tooling can provide adequate audit trails, masking, data security, and strict security protocols. If your migration falls under any of these frameworks, see how we handle regulated-industry Salesforce migrations.

Frequently asked questions

For the full detail, here’s the most comprehensive official migration guide. When you’re ready, you can also request a demo using your real data.

‍