SAP Commerce Cloud Migration Checklist: 6 Phases That Actually Matter

Most migration checklists read like marketing brochures. This one covers the unglamorous work that actually determines whether your migration stays on budget: database cleanup, compatibility testing, cutover runbooks, post-launch monitoring. The stuff nobody wants to talk about at the kickoff meeting. But it’s the stuff that matters.

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, incompatibilities discovered too late, and integration surprises that nobody scoped. I’ve watched this pattern play out across dozens of projects.

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 catch data quality issues, performance bottlenecks, and hidden customisations before they become migration blockers. Spend the time here. It pays for itself ten times over.

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 or failed. I’ve seen teams skip this and then spend weeks arguing about whether performance got worse. Nobody wins that argument without data.

Profile your data. How many products, customers, orders, content items? What’s the data quality like? Duplicate records, orphaned references, inconsistent formats? We typically find 15-25% of product data needs cleanup before migration. Better to deal with that now than drag dirty data into a fresh environment.

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. That’s a proper relief for your migration scope.

Database cleanup. Remove outdated transactional data, temporary records, orphaned entries. Cleaner source data means faster migration, fewer errors, 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. Finding these problems mid-sprint is how budgets explode.

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

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. We’ve been burned by “should work” more times than I’d like to admit.

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. This is the one that catches people off guard the most. De facto, it’s the number one source of “how did we miss this” conversations.

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, or are you adding new functionality? The answer changes everything: timeline, budget, team composition, risk profile. Mixed-scope projects (“migrate AND enhance”) are the most common source of budget overruns. I see it constantly. Pick one. Do the other later.

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 the one I’d fight hardest for. They make the scope decisions that keep the project on track.

Establish governance. Weekly steering with decision-making authority. Clear escalation paths. Sprint demos every 2 weeks. A decision log that captures what was decided, by whom, and why. Sounds bureaucratic, I know. But it prevents scope creep and unblocks development when things get stuck.

Communication plan. Who needs to know what, and when? Stakeholders who get 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 later.

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 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 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 hierarchies, data encryption at rest and in transit, 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 there requires disciplined execution across four workstreams.

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, every country-specific flow if you’re running multi-market. Let the people who’ll actually use the system be the ones who sign it off.

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 staging. 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. I’d push for three if the data volume is large.

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 without guessing.

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. Go-live is not the finish line. It’s the starting line for a different kind of work.

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

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. Every single time. Plan for a 4-6 week optimisation sprint after go-live to tune caching strategies, database queries, API response times, frontend rendering.

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. 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. You’ll 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?

Depends on scope. Straightforward lift-and-shift from on-prem: 3-4 months. Migration with significant customisation rework or new functionality: 4-6 months. Complex multi-market migrations with extensive integration work: 6-9 months. We’ve proven 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 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 flat-out obsolete.

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

Separate them whenever you can. A pure lift-and-shift gets you off on-prem quickly with minimal risk. Enhancement follows in subsequent sprints once you’re stable on Commerce Cloud. Mixed-scope projects (migrate AND add features simultaneously) are the most common source of budget overruns because every enhancement decision competes with migration tasks for the same resources and timeline. I’ve watched this pattern play out too many times to recommend it.

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 at. Projects without a dedicated product owner consistently take longer.