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.

Two commands carry the whole media transfer, and the flags on them are the difference between a copy you can prove and a copy you can only assert:

# Bulk pass. AzCopy stores no content hash unless you ask for one, and without
# a stored hash there is nothing to verify the transfer against afterwards.
azcopy copy '/opt/hybris/data/media/*' \
  'https://<account>.blob.core.windows.net/<container>?<SAS_TOKEN>' \
  --recursive --put-md5

# Reconciliation pass after the media freeze. Compare by hash, not by
# last-modified time, and see what it would change before it changes it.
azcopy sync '/opt/hybris/data/media/' \
  'https://<account>.blob.core.windows.net/<container>?<SAS_TOKEN>' \
  --recursive --put-md5 --compare-hash MD5 --dry-run

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. It is two property sets over the same connection, and the second one is the one to rehearse, because delta logic is exactly where subtle data loss hides:

# Pass 1, days before the window. Full copy, target tables truncated first.
# The excluded list is DB Sync's default: runtime state nobody should carry over.
migration.data.incremental.enabled=false
migration.data.truncate.enabled=true
migration.data.tables.excluded=SYSTEMINIT,StoredHttpSessions,itemdeletionmarkers,\
  tasks_aux_queue,tasks_aux_scheduler,tasks_aux_workers

# Pass 2, inside the cutover window. Only rows changed since pass 1 began, and
# truncation off, because truncation here would delete what pass 1 just copied.
migration.data.incremental.enabled=true
migration.data.incremental.timestamp=2026-03-14T22:00:00Z
migration.data.incremental.tables=Orders,OrderEntries,Addresses
migration.data.truncate.enabled=false

The timestamp is parsed as ISO-8601 ISO_ZONED_DATE_TIME, so it carries an offset; set it to the moment pass 1 started reading, not the moment it finished. If your full copy rehearsal does not fit the window, this is the lever.

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.