CCv2 Data and Media Migration: DB Sync, AzCopy, and Choosing Your Code Freeze

Code migrates on every deployment; data migrates once, under time pressure, with customer records inside. The data and media transfer is the phase of a CCv2 migration where speed, security, and consistency all bind at the same moment (the production copy typically happens inside a two-to-six-hour cutover window), and where mistakes are the least reversible. This guide covers the execution options, the tooling, the verification discipline, and the project-level decision that shapes everything around it: what happens to feature development while the migration runs.

Who Executes: SAP or You#

Two delivery models exist, and the choice is contractual as much as technical:

• SAP-executed: the Data and Media Migration Package puts SAP CX Services in charge of secure connectivity, the data and media transfer per environment, and verification, slotting into your project plan. You buy certainty and experience; you give up schedule control and learn less.
• Self-serviced: your team (or your integrator) owns everything: target environment readiness, connectivity, both transfers, verification. SAP can still be engaged for support, but you lead.

Self-service is entirely realistic with today's tooling, and the rest of this guide assumes it; if you buy the package, this guide becomes your checklist for supervising it.

Tooling#

Database: SAP Commerce DB Sync. The open-source tooling for schema-and-data copy between commerce databases started life as the Commerce Migration Toolkit (CMT); its successor, SAP Commerce DB Sync, is the one to use now (same GitHub home under SAP-samples, actively maintained, and it added staged/incremental copy capabilities that matter for cutover design). Two facts to internalize: it is a code template, not a supported product, so your team owns its operation (community-supported, contributions welcome); and it ships with its own configuration, performance, and troubleshooting guides that are required reading before the first run, not during the first incident.

Media: AzCopy. Media files move to Azure Blob Storage with AzCopy, and three operational rules come from the field:

1. Install AzCopy on a host with direct access to the media files; copying through an intermediate hop halves your throughput exactly when the cutover clock is running.
2. Transfer over the VPN to the cloud environment.
3. Target access needs a SAS token, which is issued through an SAP support ticket; file it with lead time, because a cutover waiting on a token is a self-inflicted delay.

Connectivity: self-service VPN. The Cloud Portal's self-service VPN covers most cases without SAP involvement, but budget real calendar time anyway: your networking team and the cloud side must agree on parameters, and "the tunnel is up" is a prerequisite for every other rehearsal. Where a dedicated tunnel is impossible under your security constraints, raise it in planning, not execution; workarounds exist but need design. Transfers of personal data outside a secured channel are not a shortcut, they are an incident.

The Rules of the Copy#

• Like-for-like environments: development to development, stage to stage, production to production, preserving data segregation. Deliberate exceptions (an on-premise test dataset seeded into cloud production for pre-go-live testing) are legitimate but should be explicit decisions, not conveniences.
• Same schema on both sides. The source and target must run the same code version at copy time; the platform upgrade happens before the data migration, never during it. This single rule is behind the whole code-freeze discussion below.
• Database differences are work items. Azure SQL is the target, full stop. If the source is Oracle, MySQL, or HANA, transformation is part of the copy (DB Sync handles the mechanics; your job is testing the semantics). Note the collation default: CCv2 databases are case-sensitive; if your source was not, that difference will surface as bizarre lookup failures, and a different collation is a support-ticket conversation to have early.
• Data and media move together. Media references live in the database; a database snapshot paired with a media copy from a different moment produces broken references. Align the two.
• Clean before you copy. Every gigabyte of expired carts, stale cronjobs, and orphaned audit rows (see the data maintenance guide) is transfer time, cutover risk, and target-side performance debt. The cleanup is the highest-return preparation task in the whole migration, and it also keeps you inside the storage limits of your subscription's service description, which is a real gate someone should check against the source system's size in week one.

Phases#

Planning#

Decide the environment scope honestly (a dev environment that gets re-initialized on every deployment has nothing worth migrating; an on-premise pre-production full of curated test data might), then sequence four activities per in-scope environment: connectivity established, code base migrated and deployed on the target (schema parity), data and media copied, and validation. Plus one activity at the end of the project: decommissioning the migration plumbing (VPN, temporary hosts) after a stable go-live, with the source environments' retirement on your own schedule.

Execution, per environment#

The loop that repeats for each environment, and gets faster each time:

1. Confirm prerequisites (connectivity, schema parity, target deployed)
2. Configure DB Sync for the environment's source and target
3. Run the data copy
4. Verify the data: table and row counts source versus target, at minimum
5. Configure the media transfer
6. Run AzCopy
7. Verify the media: checksums, not just file counts

The verification steps are numbered because they are skipped under time pressure, and they are precisely the steps that distinguish "migration complete" from "migration probably complete". For production, this entire loop runs inside the cutover window, which is why the lower-environment runs double as timed rehearsals: by production night you know, not estimate, that your data copies in three hours and your media in one.

Incremental copy changes the cutover math for large databases: DB Sync's staged approach lets you bulk-copy the big tables ahead of the window and transfer only deltas during it. If your full copy rehearsal does not fit the window, this is the lever, and it needs its own rehearsal because delta logic is exactly where subtle data loss hides.

Rollback, rehearsed#

The cutover rollback plan is a document plus a test, never just a document. The items that belong in it, each verified once in rehearsal: reverting DNS, pointing every integration back at the source environments, and the easily forgotten state resets, with order ID seed values as the canonical example: if the new system generated orders during a failed cutover, the old system's sequences must not collide with them on rollback. Walk the plan against your own integration inventory and add your equivalents.

After the copy: test with the data#

Migrated data enables the two test rounds that matter: functional validation that the data is complete and means the same (spot-check orders, customers, catalogs, media rendering), and performance testing on the migrated dataset, because the target environment's behaviour with your real data volume is the thing no synthetic test predicted (the migration planning guide covers why, and DB Sync's performance guide helps with the copy-side tuning). If those tests need production-shaped personal data, the anonymization obligation from the data protection guide applies before the data is used, not after.

Code Freeze: The Decision That Shapes the Project#

Most moves to CCv2 are an upgrade and a migration (U&MP), and the central scheduling question is what feature development does meanwhile. The physics behind the options: during either project's technical phase, new features are absorbable because testing follows; during the migration (data copy) phase, database-affecting changes are prohibited, because the copy depends on a stable schema; during testing phases, every change erodes the coverage you are paying for. Branch model for the discussion: master (production, hotfixes only), upgrade, migration, develop.

The recommendation is unambiguous: options 1 and 2, with option 2 the practical sweet spot for projects long enough that a total freeze is politically impossible: the upgrade completes and stabilizes, a defined window delivers the queued features on the stable base, then the migration phase begins with its freeze intact. Options 3 and 4 are what you accept when the business overrules, and they come with named costs: option 3's deferred mega-merge regularly consumes weeks and re-testing that nobody scheduled, and option 4 requires per-feature discipline that must be enforced, not hoped for: frontend changes are broadly safe throughout; logic changes during the migration phase need case-by-case review with the migration team; and database changes during the migration phase are flatly forbidden, because they do not add risk to the data copy, they invalidate it.

Whichever option is chosen, write it into the project charter with the phase boundaries dated, because "we agreed on a freeze" and "marketing was told about the freeze" are different facts, and the second one is the one that holds on the night the data moves.