Testing a CCv2 Migration: The Two Extra Test Dimensions That Decide Success

Migrating an existing SAP Commerce solution to Commerce Cloud is not the same test problem as an upgrade, even though the two share most of their machinery. An upgrade changes your code against a moving platform; a migration also moves your data, your media, and your integration endpoints into a new infrastructure with different rules (ephemeral storage, no SMTP server, Cloud Hot Folders instead of SFTP). So migration testing carries every phase an upgrade needs plus two dimensions that upgrades barely touch: data and media migration testing and integration re-validation. Get those two wrong and you deploy a solution that compiles, passes regression, and then loses orders or drops media the moment real data flows. This guide is the migration test plan, sequenced the way risk demands. It complements the upgrade-testing guidance (shared phases) and the CCv2 data-and-media migration guide (the migration mechanics this validates).

The Sequence Is the Strategy#

The phases are not a checklist to run in any order; the sequence encodes where the risk is:

1. Data and media migration testing and regression testing run first and in sequence. These gate everything else, because a data discrepancy or a broken key scenario invalidates any test that assumes correct data underneath it.
2. Only after both pass do acceptance, integration, security, and performance testing run in parallel.

The logic: there is no point acceptance-testing a checkout on data that migrated wrong, or performance-testing against a catalog that half-loaded. Data and regression establish the trustworthy foundation; the parallel phases then validate different facets of a solution you already know is standing on correct data. Front-loading data testing also obeys the universal QA law: discover discrepancies at the start, when they are cheap, not at the end, when they are a launch-threatening scramble.

Test on Production-Shaped Data, Everywhere#

One rule underpins every phase and is worth stating alone: refresh the target environment with production data before testing. A migration validated on a thin sample is a migration validated against the one scenario that never happens (small, clean data). Realistic tests need realistic data: production-scale catalogs, real customer volumes, the messy edge-case records that only exist in a live system. And because a CCv2 subscription has multiple environments (Development, Stage, Production), data and media migration testing must run for every provisioned environment, since each has its own database and its own opportunity for the migration to go wrong.

The production-like environment for the heavy testing is stage (or an extra production instance if purchased), accessible to the actual business users who will run acceptance, refreshed from production so the test mirrors reality.

Dimension One: Data and Media Migration Testing#

This is the phase upgrades do not have, and it splits into two validation levels that catch different failures:

• Data-level validation: did the data arrive intact? Table and row counts reconciled between legacy and target, entitlement and referential integrity preserved, no silent truncation or transformation loss. This is the "nothing fell off the truck" check, run as reconciliation queries comparing source and target (the FlexibleSearch and hAC guides give you the tools).
• Application-level validation: does the migrated application run correctly on the new database and media? Data can arrive intact and still break the application if a transformation subtly changed something the code depends on. This is the "the truck's contents still work" check, run by exercising the application against the migrated data.

Both are mandatory because they fail independently: perfect row counts with a broken application (a transformed enum the code no longer recognizes), or a happy application hiding a 2% row loss nobody counted. Media gets the same treatment: the assets migrated, and the application can actually resolve and render them from the new (cloud-backed, ephemeral-aware) media storage.

Dimension Two: Integration Re-Validation#

The second migration-specific dimension, and the one that surprises teams who thought integrations would "just work." Every current integration must be validated against the CCv2 solution, because the infrastructure changed underneath them:

• File-based integration moved to Cloud Hot Folders. Your old Hot Folders / NFS / SFTP setup does not exist on CCv2 (ephemeral storage, no SFTP server); the cloud-native replacement rides Azure Blob Storage (the cloud hot folders guide). Validate it concretely: upload product media/images through Cloud Hot Folders and confirm the instance processes them. A file-integration path assumed-working and never tested is a launch-day data gap.
• Email has no SMTP relay. CCv2 provides no mail server (the architecture and SES guides), so transactional email must be re-validated against your chosen provider (your SMTP or a third-party service like SES). Order confirmations and password resets are money-path email; test them explicitly.
• Every third-party integration re-validated end to end: the legacy applications your solution talks to, the communication between them, error handling, and the credential/network changes the migration introduced (VPN, private endpoints, the web architecture guide). Integration testing is where migration projects under-budget most often; give it real time in the plan.

The Shared Phases, Migration-Flavored#

The phases migration shares with upgrades, with their migration twists:

• Regression: the full suite against the production candidate, confirming key scenarios survived the move. Run throughout the project, but the complete suite against the release candidate is the gate to the parallel phases.
• Acceptance: reuse your existing acceptance criteria (from the original build or the concurrent upgrade), add cases for any new functionality you are porting over, and have the actual production business users run it and sign off. Their sign-off is the human gate on the release candidate.
• Security: the full security suite on the candidate, because a migration can introduce issues two ways: a bug in the target platform version, or code adaptations made during the migration. The security hardening guide's checklist plus an independent test.
• Performance: measure and compare source versus migrated, on production-refreshed data, after all code is migrated. Any degradation against your source baseline is resolved before production, not explained away after (the performance engineering guide's baseline discipline).

Checklist#

• Data/media and regression run first and in sequence; they gate the parallel phases
• Every environment (Dev, Stage, Prod) tested for data and media migration
• Data-level validation (counts, integrity, entitlement) and application-level validation both run
• Media resolves and renders from cloud-backed storage
• Cloud Hot Folders validated by actually processing files; old SFTP/NFS paths confirmed replaced
• Transactional email re-validated against the provider (no SMTP relay on CCv2)
• Every third-party integration re-validated end to end with real error handling
• Regression suite green on the candidate; acceptance run and signed off by production business users
• Security suite plus independent test; performance compared to source baseline on production-shaped data
• Target environments refreshed from production before every serious test

A migration deploys the same code you tested and the same data you migrated, which is exactly why testing both, together, on realistic data, is the whole job. The estates whose migrations go quietly are the ones that discovered their data discrepancies and broken hot folders in week one of testing; the ones that make the news discovered them in week one of production.