How to Test a Salesforce CPQ Seeded Sandbox Migration

To test a Salesforce CPQ to Revenue Cloud (formerly Agentforce Revenue Management) migration, use a CPQ seeded sandbox that mirrors your production environment closely: production-like test data volumes, record relationships preserved, and PII masked.

An empty Developer sandbox can’t validate the migration on its own. The order goes like this. Use sandbox seeding to load data into a production-like Salesforce sandbox, migrate or rebuild the CPQ configuration that Revenue Cloud needs, check quoting and pricing, and then rehearse the cutover. You want realistic CPQ data without exposing sensitive production data any more than you have to.

A real test needs four things. The first is a production-like sandbox, not an empty one, with real or production-representative data volumes and intact relationships, so the bugs, errors and scenarios that could break go-live show up before production does.

The second is masked PII and strong data security. Depending on your organization’s security policies, contractual obligations and regulatory requirements, unmasked production data may not belong in lower-trust environments at all, so mask sensitive data and keep the relationships your testing depends on.

Third, you need a repeatable loop: seed data, migrate or rebuild the required configuration, validate, fix, reseed. Two to four full cycles is a practical project plan, though the right number depends on how complex the migration is and what each run turns up.

Last comes a rehearsed cutover with a rollback path. Don’t touch the production environment until the dry run is clean and you’ve defined how you’ll recover if something goes wrong.

This page is only about testing the Salesforce CPQ-to-Revenue Cloud cutover. The general process of populating a Salesforce sandbox with seed data for development and testing has its own guide. What follows takes that same sandbox seeding process and applies it to a CPQ-to-Revenue Cloud migration.

Urgency shapes the plan, so it’s worth being clear about it. Salesforce CPQ is now end of sale, which isn’t the same as shut down. Existing Salesforce CPQ customers can keep using the product, add users under the applicable terms, renew licenses and get support.

Salesforce hasn’t announced an end-of-life date for CPQ, either. The real pressure sits in the cutover rather than some sudden cliff, and good testing cuts that risk and gives the team more confidence before it changes production.

Why you cannot test a CPQ migration on an empty sandbox

Salesforce CPQ keeps much of its behavior in data rather than metadata. Price rules, product options, discount schedules, configuration attributes and other CPQ configuration elements are records, often tied together through deep parent-child dependencies.

A quote line points back to a product. That product connects to a price book entry, and CPQ pricing can also hang on price rules, conditions, custom fields, configuration records and other related data.

Quote templates and approval configuration can be part of the wider quoting process too. So moving to Revenue Cloud means transferring, transforming or rebuilding the relevant configuration-as-data and logic. It isn’t a matter of deploying a small bundle of metadata. For more on the transfer itself, see migrating your CPQ data.

A newly created Developer sandbox gets a copy of production configuration and metadata, but your production records don’t come with it. Admins and developers can load test data into it. Even so, an empty Developer sandbox can’t expose the failures that actually break a go-live:

• Broken lookups and orphaned records. These only appear when related records move in the wrong order, fail to sync or get dropped.
• Pricing that recalculates differently in realistic scenarios, because a rule that looks fine against five products may behave differently across a much larger product catalog and CPQ data set.
• Behavior at realistic record counts, which a 20-account sample will never show you.

A raw Full Copy has the opposite problem. A Full sandbox contains production data, so it can expose many of those failures, and it’s the Salesforce sandbox type intended for staging, performance testing and load testing.

But copying real customer data into a lower environment can create a data security and compliance problem unless the sensitive data is properly protected. The 29-day refresh interval for a Full sandbox also limits how quickly the team can repeat full refreshes. The most valuable migration test then gets rationed, because resetting the environment is expensive or slow.

For many migration scenarios, the middle path is a seeded sandbox with production-like test data, preserved relationships and masked sensitive data. A seeded Partial Copy can be a practical option for repeated functional migration testing. A Full sandbox is still the better call where the test genuinely needs every production record, or for formal performance and load testing.

One distinction matters here. A native Partial Copy doesn’t guarantee every ordinary lookup relationship in the production data it samples. Salesforce guarantees relationship sampling for Master-Detail and required lookup relationships, but not for every standard lookup.

When relationship integrity is essential to CPQ testing, the seeding process has to select and load the related records deliberately. That’s the environment a Salesforce CPQ migration test needs: enough representative data to expose migration bugs, without turning the test org into one more uncontrolled copy of production.

What "production-like" means for migration testing

“Production-like” carries a lot of weight, so it’s worth defining. For a CPQ-to-Revenue Cloud test, a production-like Salesforce sandbox has four properties:

• Realistic data volumes. You need enough records to reproduce how pricing and quoting behave across representative production scenarios. Twenty sample accounts will pass every test and prove very little.
• Referential integrity across the test data, meaning no broken lookups, no orphaned records and no unnecessary manual remapping. If the relationships don’t survive seeding or migration, you’re measuring a broken data set, not your migration.
• The complex application layers. That’s the Salesforce CPQ and Revenue Cloud objects plus the data and systems they touch: products, price books, orders, contracts, approvals, custom fields, integrations and relevant quote templates.
• Masked PII and other sensitive data, obfuscated as required so the environment can safely support developers, admins, QA, implementation partners and, where appropriate, training users.

Miss one and the test misleads you in its own particular way. With too little data, volume-related bugs stay invisible. Broken relationships send your team chasing errors that don’t exist in the production environment. Leave out application layers and you’ve validated only part of the migration. Fail to protect sensitive data and the test itself adds data security and compliance risk you didn’t need.

Sandbox type sets the ceiling on how much data you get and how often a Salesforce sandbox refresh can happen. Seeding is how you fill that environment with the specific production-like test data you need for development and testing. They’re separate decisions, and both matter. Here’s how each sandbox type scores for CPQ-to-Revenue Cloud migration testing:

The practical takeaway is that a seeded Partial Copy makes a useful default for many functional Salesforce CPQ-to-Revenue Cloud migration tests. It has room for sizable production-like subsets and a five-day refresh interval, which gives the team more space to iterate than a Full sandbox does.

With a sandbox seeding tool you can also reseed data between full Salesforce sandbox refreshes, within the storage and technical limits of the target sandbox.

Use a Full sandbox when the test truly depends on every production record, or when you need Salesforce-supported performance, load or final staging tests. The slower refresh interval is what you trade for that level of fidelity.

An empty Developer or Developer Pro sandbox is still valuable for early development, metadata tasks, isolated configuration work and some testing or training. By itself, though, it can’t validate a migration against production data volumes and relationships. Once seeded, a Developer or Developer Pro sandbox can still handle targeted scenarios if its storage capacity is enough.

Flosum Data Migrator is designed to populate Salesforce sandboxes with masked, production-like data while preserving parent-child and cross-object relationships. Teams define a data set once and reseed sandbox environments on demand.

How to mask PII in a migration test sandbox while staying compliant

For a regulated team, this question draws the boundary for everything else. Organizations working under HIPAA, GxP, 21 CFR Part 11, DORA, SOC 2 controls or other security and regulatory frameworks have to decide how sensitive production data can be used in non-production systems, based on their policies, controls, contracts and applicable requirements.

Depending on those requirements, putting unmasked production data in a lower environment can create significant compliance and data security risk

That goes some way to explaining why so many migration tests fall back on thin sample data. Small synthetic or sample data sets can be safer, but they often aren’t enough to validate complex CPQ scenarios. Masked, production-like test data lets the team get useful test coverage and still protect sensitive data.

Salesforce provides data-masking capabilities for sandbox environments. Depending on which Salesforce feature you use, masking can replace values with random or similarly mapped data, apply a defined pattern or remove sensitive values. The aim is safer data in the lower environment, with the original production environment left unchanged.

For migration testing, though, masking the visible values is only one part of the problem. The data also has to stay functionally useful, so pricing, quoting, integrations and other CRM processes still behave as expected.

If a masking or data-loading process breaks the keys and relationships that connect a quote line to its product, price book, account, contract or related CPQ configuration, the migration test can fail for reasons that have nothing to do with the migration. Lose those relationships and the results mislead you. Keep them intact and the test is worth far more.

That’s the job of the test-data process. It has to handle production-like volumes within the selected sandbox’s limits, maintain referential integrity, protect sensitive data and make seeding repeatable so the team can run the same process again. The approach pays off beyond migration testing, too, in controlled development, QA, UAT, integration testing and training users, anywhere production-like scenarios add value.

The test-and-cutover loop, step by step

Testing a Salesforce CPQ migration isn’t a one-time pass. You run the process, see what breaks, fix it and run it again until the results become predictable. That’s the loop.

Seed a production-like sandbox

Populate the selected Salesforce sandbox with the production-like test data the migration needs, with relationships preserved and PII and other sensitive data masked appropriately. For many projects that means a Partial Copy or Full sandbox, although a seeded Developer or Developer Pro environment can support targeted scenarios when its storage and functional limits are sufficient. The rest of the test runs in this environment, so set the sandbox up correctly from the start.

Automated sandbox seeding is usually the more practical way to make this repeatable. Manual seeding is slow and prone to errors, and it’s hard to maintain when dozens of related objects have to load in the correct dependency order. The seeding process should define exactly which records exist in the test environment, which source data gets copied, how sensitive fields are transformed and how related records stay connected.

Flosum Data Migrator is designed to fill this role. It can seed production-like Salesforce sandboxes on demand with masked data while maintaining parent-child and cross-object relationships, which reduces broken lookups, orphaned records and the need for manual remapping.

Flosum also provides relationship-aware seeding templates for complex Salesforce application layers, including CPQ and Revenue Cloud. What a defined seeding template buys the team is repeatability. Admins and developers reuse the same data definition when they refresh test scenarios, instead of building a new data set by hand each time.

Migrate or rebuild the CPQ configuration for the target

Move, transform or rebuild the relevant CPQ configuration to match the target Revenue Cloud design. CPQ price rules, product options, discount schedules, configuration attributes, custom fields and related records don’t all follow the same migration path. Some of the underlying data can be moved or transformed. Other logic has to be redesigned in the corresponding Revenue Cloud configuration.

Where custom fields, quote templates, approval logic or other configuration elements are in the migration scope, include and validate them through the appropriate Salesforce metadata, data or Revenue Cloud configuration mechanism.

Wherever it’s practical, use the same tools, processes, mappings and sequence you’ve planned for production. The point is to rehearse the actual migration, not to take a shortcut that won’t exist during go-live.

Flosum Data Migrator can move relational Salesforce data between orgs while preserving its dependencies. In a CPQ-to-Revenue Cloud project, that makes it part of the data-migration and test-seeding layer. It doesn’t automatically translate CPQ pricing rules, bundle logic or other commercial behavior into the Revenue Cloud model.

The team should also keep the sandbox and migration configuration in sync with the current production design, so the test doesn’t drift away from the system it’s supposed to represent.

Validate

This is what the whole exercise is for. Run comparable quotes in Salesforce CPQ and Revenue Cloud with the same commercial inputs, then compare the pricing, totals, products, discounts and expected outcomes line by line.

The technical implementation doesn’t have to be identical, because the two products use different data and rules models. The commercial result, though, should be understood and validated wherever equivalent behavior is required.

Test more than the happy path. Use the scenarios that create real complexity: different products, bundles, quantities, discounts, amendments, renewals, approvals, customer types and any custom pricing behavior in the Salesforce org.

Make sure approval workflows still trigger where required, integrations keep exchanging the correct data, connected systems receive the expected values and reporting still ties out. Confirm that no records were orphaned and no relationships broke. Validate both standard and custom fields wherever they affect quoting, pricing, integrations, reporting or downstream CRM processes.

If the numbers differ, the cause could be a data issue, a configuration-translation issue, or a functional difference (intended or not) between the Salesforce CPQ configuration and the Revenue Cloud configuration. Finding it here costs far less than finding it after a cutover.

This is also the point where training users starts to pay off. Once the core migration is stable, selected business users can practice realistic quoting scenarios in the sandbox and spot workflow or usability problems before production.

Fix, reseed, and repeat

Fix what validation exposed, reseed a clean sandbox and run the process again. Salesforce doesn’t mandate a number of migration-test cycles. One practical project target is two to four full end-to-end cycles. The first usually uncovers problems, the second checks whether the fixes hold, and later cycles show whether the process is stable and repeatable.

If later cycles are still turning up new material failures, the team should question whether it’s ready to cut over. A green result only has value if you can reproduce it. What keeps repeated testing affordable is a fast data refresh and seeding process.

That’s why a seeded Partial Copy is attractive for many functional migration scenarios. The team can keep reseeding the required data set without waiting for a new Full sandbox refresh every time. When a scenario specifically needs every production record, production-scale load or formal performance testing, a Full sandbox is still the appropriate Salesforce sandbox type.

Rehearse the production cutover and keep a rollback path

Once the loop is clean, rehearse the cutover from start to finish: sequence, timing, freeze window, migration steps, deployment steps, validation checklist, dependencies and the go/no-go decision. Production should only be touched after a clean, repeatable dry run, with a documented rollback or recovery path in place in case something goes wrong on the day.

Be precise about what rollback means. Rolling back a metadata deployment, restoring data and reversing migrated transactional or configuration records aren’t necessarily the same process. Define the recovery method for each part of the cutover rather than assuming one rollback button reverses everything.

Where Flosum DevOps is used for Salesforce metadata deployment, Flosum provides rollback capabilities for deployment changes.

The migration team should still define, separately, how CPQ data and other migrated records will be restored, reversed or otherwise recovered if validation fails. And if cutover validation does fail, execute the recovery plan, correct the cause, reseed the test environment and rehearse again before making another production attempt.

Version and log every seeding and migration job. Flosum Data Migrator records migration and seeding activity for auditability, and that history gives you useful evidence of what data moved and when each process ran.

Common mistakes that make migration tests lie to you

Most weak migration tests fail in the same few ways. Watch for these:

• Testing on config-only or tiny sample data and calling it validated. A pass on 20 accounts tells you very little about production behavior. If the test data doesn’t represent the production scenarios that matter, the green checkmark just creates false confidence.
• Assuming any “real data” is automatically good test data. Production data only helps when the relevant records, relationships, configuration and security controls are carried into the test correctly.
• Assuming a native Partial Copy preserves every relationship. Salesforce’s sampling guarantees Master-Detail and required lookup relationships, but ordinary lookups aren’t always enforced. For relationship-heavy CPQ testing, seed the complete related data set on purpose.
• Loading unmasked production data, or masking badly. Unmasked sensitive data is a data security and compliance risk. Masking that destroys the data your relationships or business behavior depend on is a test-signal risk. You have to solve both.
• Choosing the wrong sandbox type. A Developer sandbox may be ideal for development but wrong for a large migration-volume test. A Partial Copy is useful for repeatable functional testing, while Full is the Salesforce sandbox type for formal load and performance testing or full production fidelity.
• Treating sandbox refresh and data seeding as the same thing. A refresh recreates or updates the Salesforce sandbox from its source under Salesforce’s refresh rules. Seeding populates an existing environment with the data set you define, and a seeding tool makes test-data refreshes more flexible between Salesforce sandbox refreshes.
• Running a single test pass. One clean run doesn’t establish a repeatable process, so iterate until the migration behaves consistently.
• Letting environments fall out of sync. If the CPQ configuration changes in production while the migration sandbox goes stale, the team may end up validating the wrong version of the solution.
• Unrealistic training or test scenarios that skip the difficult price rules and configuration. Cover the quoting patterns users actually run into instead.
• Pushing changes without controlled validation. Every migration or deployment push needs clear validation criteria before the team moves on to the next environment.
• No rollback plan for the real cutover. Hope isn’t a cutover strategy. Decide in advance how you’ll reverse or recover from a bad go-live, and rehearse that as well.

Test the migration before you commit to it

There’s no need to guess if your Salesforce CPQ-to-Revenue Cloud cutover will hold. Test it first with masked, production-like data, repeat the loop until it runs clean, and cut over only once the team has a documented recovery path.

That’s the value of a CPQ seeded sandbox. It gives developers, admins, QA users and migration teams a controlled place to reproduce real scenarios without experimenting directly in the production environment.

Flosum Data Migrator creates that kind of test environment by populating an existing Salesforce sandbox with selected production-like data and masking sensitive fields as required. The seeding process preserves parent-child and cross-object relationships, so validation reflects the real connected data model more closely than a simplified test case would.

Flosum can also move Salesforce CPQ relational data between orgs while preserving its dependencies. In a CPQ-to-Revenue Cloud migration, that capability supports the data-migration and testing layer. It doesn’t replace the work of redesigning CPQ functionality in the target architecture.

Flosum is a destination-neutral migration-safety layer: it doesn’t configure quotes, and it doesn’t replace Salesforce CPQ or Revenue Cloud. Its job is to support the controlled movement and seeding of Salesforce data, so the move to whichever destination you’ve chosen can be tested again and again.

For teams building a broader Salesforce release process, Flosum’s DevOps capabilities can also support metadata deployment, governance, auditability and rollback. Together, those controls help developers and admins stay confident as changes move between development, testing, staging and production environments.

Frequently asked questions

Request a demo and spend 30 minutes working with a production-like, masked sandbox seeded with your own data for a CPQ-to-Revenue Cloud migration.

‍