Migrating to SAP Commerce Cloud: Assessment, Planning, and the Technical Gap List

A move to CCv2 is never "the same system on different servers". The managed platform makes architectural decisions for you (web tier, database, file storage, scaling), and every place your on-premise solution made a different decision is a work item. The migrations that go smoothly are the ones that found their complete work-item list before the project started; the ones that go badly discover items during cutover week. This guide covers the assessment that produces the list, the planning structure around it, and the recurring technical adaptations, with the 2205 on-premise maintenance deadline having turned this from a strategic option into a scheduling question for most remaining installations.

The Assessment Comes First, Ideally Before the Contract#

The migration assessment is a structured analysis of your current installation's cloud readiness: code investigation, integration architecture, upgrade needs, delivery strategy, infrastructure sizing, and effort estimation. Three practical rules about it:

1. Do it before signing, or as close to that as reality allows. The assessment's output shapes subscription sizing, timeline, and whether an upgrade must precede or accompany the migration; discovering those after commercial terms are fixed converts findings into disputes.
2. The organization executing the migration runs the assessment. If a system integrator will do the project, they assess with their own delivery method; an assessment by one party handed to another loses most of its planning value in translation.
3. Decide the upgrade question explicitly. Old platform versions cannot run on CCv2, so most migrations from legacy versions bundle an upgrade (see the upgrade guides in this series). Whether to upgrade first, migrate first where possible, or do both together is the single biggest structural decision the assessment informs, and each answer has a very different risk profile. Combined upgrade-plus-migration projects should be treated as what they are: two projects sharing a deadline.

Alongside the technical fit-gap, two often-skipped assessment areas earn their keep: roadmap alignment (features on the SAP roadmap that could remove custom code from your migration scope) and compliance review (data protection and residency requirements against the cloud service's terms).

Planning Structure#

Environment sequencing. CCv2 gives you a standard environment set (development, staging, production), and the migration moves your on-premise equivalents across incrementally. Two proven orders: lower-to-higher (DEV, then STG, then PROD), which maximizes learning before production risk, and production-first-then-parallel, which front-loads the riskiest environment while the team's attention is sharpest. Lower-to-higher is the default; production-first suits teams under a hard deadline who can staff the parallel streams.

Workstream separation. Code adaptation, data and media migration, integration rework, and configuration migration are parallel workstreams with different skills and different critical paths. Plan them separately, converge them at rehearsals. The data workstream in particular has its own guide in this series, and its first step (cleaning up the data you are about to move, per the data maintenance guide) should start before everything else, because every gigabyte you delete is migration time and cloud cost you never pay.

Rehearse the cutover. Every environment migration is a timed rehearsal of the production cutover. By the time production moves, the runbook should have executed at least twice end to end.

The Architecture You Are Moving Into#

The constraint list that drives the code adaptations:

• Web layer: standard and closed to customer configuration. No custom load-balancer schemes, no web-server-level caching tweaks, and CDN-with-authentication setups need rethinking against the standard endpoints and IP filtering model. Anything your solution did with Apache configs is either offered by the platform (static media offloading via Cloud Portal) or gone.
• Application layer: horizontal scaling of web, commerce, and Solr nodes is the platform's job, driven by aspects in the manifest. Your job is making the workloads scale-friendly (below).
• Storage layer: Azure SQL Database is the only database, and Azure Blob Storage replaces the filesystem. Both facts generate work items: platform-specific SQL in custom code must become FlexibleSearch or go; large objects near Azure SQL's 2 GB LOB cap need case-by-case analysis; and nothing may rely on local disk, because container filesystems are ephemeral. The default media storage strategy is blob-backed and not changeable.
• Security layer: TLS termination at the web tier, encryption at rest for SQL and blob, encrypted database connections. Mostly good news; the work item is retiring whatever custom machinery duplicated this.

The Code Adaptation List#

The recurring items, from dozens of migrations. Treat this as the checklist to run your codebase against during assessment:

Beyond adaptation, the migration is the natural moment to modernize integration patterns: SAP's strategic direction is side-by-side extensibility over in-app customization, and every integration you convert to Integration APIs, webhooks, or hot folders during the migration (rather than porting its custom in-app implementation) permanently shrinks your upgrade surface. The integration options guide covers the menu; the planning point here is that these conversions belong in the migration scope discussion, sized and consciously chosen, not discovered as "while we are here" scope creep in sprint six.

Builds, Environments, and Configuration#

The delivery-mechanics work is real but well-marked: repository connected to the Cloud Portal, manifest.json defining extensions, properties, aspects, and tests, Solr configuration moved into the repository's customization structure, language packs declared in the manifest. The first-deployment guide in this series walks this end to end, and its patterns (configuration reuse via useConfig, secrets in service configuration rather than Git) should be adopted from the first migrated environment rather than retrofitted.

Configuration migration is its own small workstream with a deceptive shape: most properties carry over as-is, but the exceptions are operationally critical: endpoint exposure and IP filter sets, certificates (now managed in the portal), host aliases for external system resolution, and every property that encoded an on-premise path, host, or port. Inventory these from the current local.properties early; the ones nobody remembers configuring are the ones that surface as mystery failures in smoke testing.

Verifying the Migrated System#

Smoke tests gate each environment's migration: login and logout, homepage, PDP rendering with correct prices, listing pages, search, order placement, and, the one that finds the most issues, third-party communication in both directions. Integration failures dominate migration defects because credentials, allowlists, and network paths all changed; test every integration from the migrated environment explicitly.

Performance benchmarking is not optional, and the reasoning deserves stating plainly: CCv2's scalability exists to absorb traffic growth, not to compensate for non-performant code, and code tuned for your old infrastructure (its disk latencies, its database, its network topology) can behave differently on the new one. Re-run your performance baseline (journeys, volumetrics, and targets per the performance engineering guide) on the migrated staging environment and compare against the on-premise numbers. Degradation found here is a tuning task; degradation found by customers after cutover is an incident with a press cycle.

Cutover#

The production cutover inherits everything above: the rehearsed runbook with timings, the data and media migration procedure (its own guide, including the code-freeze options that determine how long you dual-run), DNS and traffic switching, and the same production regression and post-go-live support model as any major deployment (the upgrade execution guide's patterns apply verbatim).

The summary that fits on one slide: assess before you commit, decide the upgrade question consciously, run the adaptation checklist against your codebase early, clean data before moving it, rehearse the cutover twice, and benchmark before customers do it for you. The platform migration itself is well-trodden; the projects that struggle are the ones that treated the list above as discovery work for the execution phase instead of input to the plan.