SAP Commerce Cloud Migration Checklist: 6 Phases That Actually Matter

Most SAP Commerce Cloud migration checklists read like marketing brochures. This one covers the unglamorous work that actually determines whether your migration stays on budget and on schedule — from database cleanup to post-launch monitoring.

83% of data migration projects exceed their budgets or schedules (Bloor Group, 2023). The failures almost never come from the platform itself — they come from skipped preparation, discovered-too-late incompatibilities, and integration surprises. This checklist is organised into six phases, in the order they should happen.

TL;DR: SAP Commerce Cloud migrations fail when teams skip preparation. This 6-phase checklist covers: pre-migration assessment (data profiling, performance baselines), compatibility validation (code, extensions, data models), project setup (team, governance, scope), infrastructure configuration (environments, security, CI/CD), go-live execution (testing, data migration, cutover), and post-launch operations (monitoring, optimisation, training). 83% of migrations exceed budgets (Bloor Group, 2023) — following a structured checklist is how you stay in the 17%.

Phase 1: How Should You Assess Your Current System?

64% of organisations cite data quality as the top challenge in technology adoption (McKinsey, 2024). The assessment phase is where you find data quality issues, performance bottlenecks, and hidden customisations — before they become migration blockers.

Establish performance baselines. Measure your current system’s response times, throughput, and load capacity. You need these numbers to validate that the migrated system performs at least as well. Without baselines, you can’t prove the migration succeeded.

Profile your data. How many products, customers, orders, and content items? What’s the data quality? Are there duplicate records, orphaned references, or inconsistent formats? We typically find 15–25% of product data needs cleanup before migration.

Audit your customisations. Classify every custom extension: still needed, replaceable by platform capability, or obsolete. On-prem SAP Commerce installations often have 50–100+ custom extensions accumulated over years. We typically find 25–35% are removable.

Database cleanup. Remove outdated transactional data, temporary records, and orphaned entries. Cleaner source data means faster migration, fewer errors, and better performance in the new environment.

Check encryption and credentials. If your current setup uses Transparent Attribute Encryption (TAE) with custom keys, document all encrypted attributes and plan their migration to Commerce Cloud’s key management.

Phase 2: What Compatibility Issues Will You Hit?

23% of developer time is spent managing technical debt (Journal of Systems and Software, 2023). The compatibility phase is where you identify the technical debt that needs resolution before migration — not during it.

Code adaptation. On-prem customisations often rely on direct file system access, custom build scripts, or server-level configurations that don’t exist in Commerce Cloud’s managed environment. Identify these dependencies early and plan alternatives.

Extension compatibility. Check every third-party extension against Commerce Cloud compatibility. Some extensions have cloud-ready versions; others need replacements. Don’t assume compatibility — verify it with the vendor and test it in a cloud sandbox.

Data model review. Does your type system need changes for the cloud? Are there custom item types that could be replaced by standard Commerce Cloud functionality? Efficient data handling matters more in a managed cloud environment where you can’t tune database configurations directly.

Integration protocol check. On-prem integrations often use protocols (file-based transfers, direct database connections) that don’t work in Commerce Cloud. Map every integration and confirm the communication protocol works in the cloud environment.

Phase 3: How Should You Set Up the Project?

Agile projects succeed 42% of the time compared to 13% for waterfall (Standish Group, 2020). But “doing agile” isn’t enough — the project setup determines whether agile practices actually help or just add ceremony.

Define scope precisely. Is this a lift-and-shift migration, or are you enhancing functionality? The answer changes everything — timeline, budget, team composition, and risk profile. Mixed-scope projects (migrate AND enhance) are the most common source of budget overruns.

Assemble the right team. A mid-size migration needs 3–5 implementation consultants (SAP Commerce, frontend, integration) plus 2–3 client-side resources (product owner, business analyst, IT liaison). The product owner role is critical — they make scope decisions that keep the project on track.

Establish governance. Weekly steering with decision-making authority. Clear escalation paths. Sprint demos every 2 weeks. Decision log that captures what was decided, by whom, and why. This sounds bureaucratic, but it’s what prevents scope creep and unblocks development.

Communication plan. Who needs to know what, and when? Stakeholders who are surprised by migration decisions become stakeholders who delay the project. Regular status updates — even when the news is “on track” — build the trust that speeds up decision-making.

Phase 4: What Infrastructure Decisions Matter?

SAP Commerce Cloud handles most infrastructure management — servers, scaling, patching, CDN. But you still need to make several configuration decisions that affect performance, security, and development workflow.

Environment strategy. How many environments? At minimum: development, staging, production. Larger projects add a dedicated integration testing environment. Commerce Cloud’s subscription model determines how many environments you get — plan this during procurement, not after.

CI/CD pipeline. Set up automated build, test, and deployment pipelines from the start. Commerce Cloud supports deployment through its Cloud Portal, but you need your own CI/CD for code quality gates, automated testing, and consistent deployment practices.

Security configuration. Review and configure: API authentication, user role hierarchees, data encryption at rest and in transit, and compliance requirements (GDPR, industry-specific regulations). Commerce Cloud provides the infrastructure security — you own the application security.

Backup and disaster recovery. Understand Commerce Cloud’s built-in backup capabilities and define your recovery point objectives (RPO) and recovery time objectives (RTO). Test the recovery process before go-live, not after a production incident.

Phase 5: What Does Go-Live Actually Require?

90% of businesses that migrated platforms reported revenue improvements (commercetools, 2024). But getting to go-live requires disciplined execution across four workstreams that must all complete successfully.

User acceptance testing (2–3 weeks). Business users — not developers — test every critical flow with production-like data. Payment processing, order management, inventory sync, content publishing, and every country-specific flow if you’re running multi-market.

Performance testing. Load test with realistic traffic patterns, including peak-day simulation. Validate that auto-scaling handles the load. Benchmark page load times against your Phase 1 baselines and against industry targets (under 3 seconds for key pages).

Data migration dress rehearsal. Run the complete migration pipeline end-to-end on a staging environment. Measure elapsed time — this determines your cutover window. Test delta migration for data created during the transition period. Run at least two full dress rehearsals.

Cutover runbook. Document every step: freeze the source system, run final delta migration, switch DNS, validate critical flows, monitor for 48 hours with the full team on standby. Include rollback procedures for every step. The runbook should be detailed enough that anyone on the team can execute it.

Phase 6: What Happens After Go-Live?

47% of IT leaders cite technical debt as a major driver of overspending (IDC, 2024). Post-launch is where you either build on your migration investment or start accumulating new technical debt. Don’t treat go-live as the finish line.

Monitoring and alerting. Set up dashboards for: page load times, error rates, conversion funnel drop-offs, integration health, and system resource utilisation. Define alert thresholds and escalation procedures. The first 2–4 weeks post-launch need heightened monitoring.

Team training. Your internal teams need to be self-sufficient on Commerce Cloud administration, content management, and basic troubleshooting. Schedule training in phases — basic operations first, then advanced configuration, then customisation development.

Performance optimisation. Real production traffic reveals bottlenecks that testing missed. Plan for a 4–6 week optimisation sprint after go-live to tune: caching strategies, database queries, API response times, and frontend rendering performance.

Continuous improvement backlog. Features that were descoped during migration belong on a prioritised backlog, not forgotten. Schedule regular reviews to decide what to build next — and resist the temptation to add everything at once.

Planning an SAP Commerce Cloud migration? We start with a discovery workshop that covers Phases 1–3 of this checklist — assessment, compatibility, and project setup — so you know exactly what you’re migrating before writing a single line of code. Talk to us.

Frequently Asked Questions

How long does a typical SAP Commerce Cloud migration take?

It depends on scope. A straightforward lift-and-shift from on-prem takes 3–4 months. A migration with significant customisation rework or new functionality takes 4–6 months. Complex multi-market migrations with extensive integration work can take 6–9 months. The Franke project demonstrated that 90 days is achievable with a standards-first approach and strong governance. The biggest variable is usually integration complexity, not platform configuration.

What’s the most common reason migrations go over budget?

Scope expansion during the build phase. “While we’re at it, let’s also add…” is how 4-month projects become 8-month projects. The second most common reason is integration complexity that wasn’t properly scoped during assessment. Both are preventable with a disciplined Phase 1 assessment and clear scope definition in Phase 3.

Can we keep our existing customisations when migrating to Commerce Cloud?

Most customisations can be migrated, but some need rework. Direct file system access, custom build processes, and server-level configurations don’t work in Commerce Cloud’s managed environment. The Phase 2 compatibility check identifies exactly which customisations need adaptation. We typically find 25–35% of customisations are either replaceable by platform capabilities or obsolete.

Should we migrate and enhance at the same time, or do a pure lift-and-shift first?

Separate them whenever possible. A pure lift-and-shift gets you off on-prem quickly with minimal risk. Enhancement can follow in subsequent sprints once you’re stable on Commerce Cloud. Mixed-scope projects (migrate AND enhance simultaneously) are the most common source of budget overruns because every enhancement decision competes with migration tasks for the same resources and timeline.

What team size do we need for a Commerce Cloud migration?

A mid-size migration typically needs 3–5 implementation consultants (SAP Commerce developers, frontend developer, integration specialist) plus 2–3 client-side resources (product owner, business analyst, IT liaison). The client-side product owner is the most critical role — they make scope decisions and provide business context that developers can’t guess. Projects without a dedicated product owner consistently take longer.