Why Enterprise Migrations Fail, and How to De-Risk a Salesforce Commerce Cloud Move to Shopify

Enterprise replatforming has a reputation problem. Ask most ecommerce leaders about migrations and you'll hear the same anxieties: they run over budget, they slip the timeline, and something always breaks at launch. That reputation is why so many brands stay on platforms they've outgrown for years longer than they should. A lot of those teams are running on Salesforce Commerce Cloud, where the GMV-based cost structure punishes every good quarter, and they've decided they would rather keep paying the tax than take on the risk of moving.

What we've found running enterprise migrations to Shopify is that the disasters are real but they aren't mysterious. The same failure patterns show up again and again, and nearly all of them are preventable. Migrations rarely go wrong because migration is inherently chaotic. They go wrong because a specific, predictable risk wasn't planned for.

This is written for the technical owner, the person who has to reason about the cartridge stack, the SCAPI surface, and what happens to a heavily customized checkout when it moves to a platform that doesn't let you own checkout the way SFCC does. So instead of adding to the anxiety, we want to walk through what tends to go wrong and how disciplined teams prevent each failure before it happens.

Failure One: Discovery That Wasn't Deep Enough

The most common root cause of migration problems isn't a technical failure during the build. It comes from an incomplete understanding of the current state before the build starts, and on SFCC the current state is usually a decade of accumulated cartridge archaeology that nobody has fully mapped.

Salesforce Commerce Cloud sites accumulate complexity in predictable places. Custom cartridges layered on top of SFRA, with overrides nobody fully documented. LINK cartridges that were modified in ways that diverge from the vendor's version. Business logic embedded in controllers and hooks where it shouldn't live. Job schedules that quietly keep the business running. Edge-case workflows that a small but important customer segment depends on. When discovery is rushed, none of this gets found until it breaks in production, where it costs far more to fix.

How to prevent it: Treat discovery as a deliverable rather than a formality. Proper SFCC discovery inventories the entire cartridge path: which cartridges exist, what each one overrides, which LINK cartridges were modified, and where custom commerce logic actually lives. It maps every job, every integration, and every business rule before a line of code gets written. That work also means sitting down with the people who use Business Manager every day, because the knowledge about how the site really works rarely lives in documentation. Brands that invest in thorough discovery pay more upfront and a great deal less later. The ones that rush it pay the difference at launch.

Failure Two: Catalog and Data Migration Treated as an Afterthought

Teams plan extensively for the new site's design and functionality, then treat the migration of catalog, content, and customer data as a mechanical task to handle near the end. That sequence is backwards, and on an SFCC move it produces a large share of the pain, because SFCC's data model does not map cleanly onto Shopify's.

SFCC organizes products around a master catalog and storefront catalogs, with category assignments, a flexible custom-attribute system, and price books that can run deep. Shopify organizes around products, variants, collections, and metafields. Moving between the two is a remodeling job, not a copy-paste. A product structure that relied on dozens of custom attributes and shared variation logic in SFCC has to be deliberately re-expressed in Shopify's product, variant, and metafield model. The places where the two models don't line up are where data tends to degrade. Add years of inconsistent data entry, abandoned attributes, and duplicate entries, and the catalog almost never maps cleanly on its own.

How to prevent it: Start catalog and data migration planning early, in parallel with design and development. Audit the SFCC data model during discovery so you know which attributes carry meaning and which are dead weight. Design the Shopify product, variant, and metafield structure deliberately, then map old to new explicitly. Use the migration as a chance to clean house, since most brands discover a meaningful percentage of catalog data that shouldn't move at all. And build in validation time to confirm the migrated data is accurate before launch, rather than after customers find the errors.

Failure Three: Underestimating Integration and Middleware Complexity

Enterprise commerce doesn't exist in isolation. The platform connects to ERP, OMS, PIM, CRM, marketing automation, loyalty, subscriptions, tax, and more. On SFCC these connections typically run through custom integration cartridges and the OCAPI or SCAPI surface, and they are consistently the most underestimated part of the migration. They are also where timelines slip most dramatically.

The mistake is assuming an integration is simple because it sounds simple. "We just need to connect our ERP" can mean a clean, well-documented API integration, or it can mean reverse-engineering an integration cartridge someone built five years ago that touches three other systems in ways nobody fully remembers. The difference between those two situations is enormous, and you won't know which one you have until discovery tells you.

How to prevent it: Map every integration during discovery, and assess the real complexity of each one instead of the assumed complexity. Identify which integrations are clean API calls and which are fragile custom middleware living in a cartridge. Sequence the hardest integrations early, while there's still time to solve them properly. And build in contingency for the integration that turns out worse than it looked, because on every enterprise migration at least one of them does.

Failure Four: Checkout and Promotions That Don't Transfer Cleanly

This is the failure most specific to an SFCC move, and the one a technical buyer scans for first, so we'll name it plainly. SFCC lets you own the checkout and run a sophisticated promotions engine: qualifiers, campaigns, layered price books, and custom controller logic that the business has come to depend on. Shopify's model is more constrained by design. You work within Checkout Extensibility, Functions, and UI extensions rather than owning the checkout outright, and complex SFCC promotion logic does not map one-to-one onto Shopify's discount system.

Pretending otherwise is how these migrations derail. A promotion stack that assumes SFCC's campaign-and-qualifier model has to be re-expressed in Shopify Functions and discount APIs, and some of it will need to be redesigned rather than ported. The same is true for any checkout customization that assumed full control of the flow.

How to prevent it: Inventory the checkout customizations and the full promotion catalog during discovery, and classify each one. It either transfers cleanly, needs redesign in Functions, or shouldn't carry forward at all. Resolve this early, while it can still shape the architecture, rather than late, when it forces rework. An honest version of this conversation, where the partner tells you what doesn't move cleanly and how they plan to handle each case, is worth a lot more than a plan that implies the checkout comes along for the ride. Owning the constraint is what separates a partner who has done this before from one who is about to learn on your project.

Failure Five: Losing SEO Equity at Launch

A migration that nails the design, the functionality, and the data can still become a business disaster if it tanks organic search performance. For a brand where organic drives significant revenue, that's a direct hit that can take months to recover from, and it's almost entirely preventable.

The culprits are predictable, and SFCC has its own URL conventions that make them concrete. The pipeline-era and SEO-friendly URL patterns, the category and product path structures, and locale handling all have to be mapped deliberately to Shopify's URL model. Change URL structures without proper redirects, lose metadata, break internal linking, or alter page structures in ways that confuse crawlers, and rankings will move in the wrong direction.

How to prevent it: Treat SEO preservation as a first-class workstream rather than a checklist item. Map every existing SFCC URL and implement comprehensive redirects to the Shopify equivalents. Preserve metadata, structured data, and the content that drives rankings. Maintain internal linking structures. Run the new site through technical SEO validation before launch. Then monitor closely in the weeks after, using real field data rather than a one-time lab score, so any ranking volatility gets caught and addressed quickly instead of surfacing in a quarterly traffic report.

Failure Six: Underestimating the Content Model Rebuild

Brands assume that because they're keeping the same content, moving it is straightforward. But the new platform requires a different content model, and rebuilding the content architecture is real work that frequently gets underscoped. On an SFCC move this has the cleanest concrete example in the whole project: content slots and Page Designer components do not become Shopify sections and metaobjects on their own.

The way content was structured on SFCC reflects SFCC's constraints, including slot configurations, content assets, and Page Designer page types and components. Shopify has its own model built on sections, blocks, and metaobjects. Mapping one to the other while preserving everything that mattered, and taking advantage of what the new platform does better, is design and architecture work rather than data entry. Teams that treat it as data entry either recreate SFCC's limitations on Shopify or scramble late when they realize the content model needs genuine design thinking.

How to prevent it: Design the new content model deliberately and early. Decide which Page Designer components map to Shopify sections, which content moves to metaobjects, what should be improved, and what should be retired. Treat the content model as foundational architecture that everything else depends on, because that's what it is. Done right, you end up with a content model that's better than what you had rather than a migrated copy of the old one.

Failure Seven: Planning for the Launch Instead of the Launch-and-After

Many migrations are scoped and staffed to get the site live, with little thought given to the period immediately after. That's a mistake, because the first weeks post-launch are when real customer behavior reveals what pre-launch testing couldn't. No amount of QA fully replicates production traffic at scale. Edge cases surface. Performance under real load reveals issues. Customer behavior exposes friction nobody anticipated.

If the team has dispersed and the budget is exhausted the day the site goes live, those issues sit unaddressed, and the brand's experience of the migration ends up defined by the problems that weren't fixed rather than the value that was delivered.

How to prevent it: Plan the cutover and the post-launch period with the same rigor as the build. Lower DNS TTLs ahead of the switch so you can move traffic quickly. Define explicit go and no-go criteria, write the cutover runbook, and decide what triggers a rollback before you need one. None of that is about heroics. Process discipline is what makes a cutover boring. Keep the team engaged through stabilization, and budget for the optimization the first weeks will inevitably surface. The most successful migrations we've run treat launch as the midpoint of the engagement, not the end of it.

How Agentic Delivery Changes the Risk Equation

Most migration risk comes down to time and capacity. There's more work to do than there is time to do it well, so corners get cut. Discovery gets rushed, catalog mapping gets compressed, integration complexity gets underestimated, and post-launch support gets descoped. The failures above are downstream of capacity constraints as much as anything else.

This is where AI-accelerated delivery changes the risk profile, but only when it's pointed at the work that actually consumes a migration. On an SFCC move, that work is concrete and well-suited to it: analyzing and cataloging a large cartridge stack to surface every override and dependency, generating the URL-to-URL redirect map across thousands of legacy paths, and translating content-model structures from Page Designer into Shopify section and metaobject definitions. These are high-volume, well-defined tasks where senior engineers paired with AI agents get through the grind faster, with the engineer reviewing and owning the output rather than handing it off.

AI doesn't make migrations effortless. What it does is free capacity from the implementation grind so that more of it can go toward the disciplined work that prevents failures: deeper discovery, real data validation, careful checkout and promotion redesign, SEO preservation, and post-launch stabilization. Speed applied to the right work is a form of risk reduction.

The Real Lesson

Enterprise migrations don't fail because migration is dangerous. They fail because a specific, predictable risk wasn't planned for: discovery that wasn't deep enough, catalog data treated as an afterthought, integration complexity underestimated, checkout and promotions assumed to transfer cleanly when they don't, SEO equity lost, content models underscoped, or post-launch ignored.

Every one of these is preventable with the right discipline and the right experience in the room. Brands that have bad migration experiences usually worked with a partner who treated the migration as a build project. The brands that have good experiences worked with a partner who treated it as a risk-management exercise that involves building a site.

The urgency facing brands on Salesforce Commerce Cloud is real, between the cost structure, the development friction, and the growing distance between where the platform is and where the business is going. When the work is done right, the perceived risk of migrating consistently exceeds the actual risk. The way to make a migration safe isn't to avoid it. It's to plan for the failures before they happen.

TAG has deep experience running enterprise migrations to Shopify, including off Salesforce Commerce Cloud, and we scope every engagement around the risks that actually cause migrations to struggle. If you're evaluating a move off SFCC and want a clear picture of what it would involve, where the real risks are for your specific architecture, and how to de-risk it, we're happy to walk you through it.