Salesforce Commerce Cloud to Shopify Migration: What to Map First

A Salesforce Commerce Cloud to Shopify migration can look simple from far away.

The old platform has products, customers, orders, content, promotions, search, merchandising, and integrations. The new platform needs the same business to keep running. It is tempting to turn that into a data migration, a theme rebuild, and a launch date.

That is too shallow.

Salesforce Commerce Cloud and Shopify do not organize ecommerce operations the same way. The migration work is not just moving records from one system to another. It is deciding how the business model that lived inside SFCC should be represented in Shopify, Shopify Plus, apps, integrations, and team workflows after launch.

Before rebuilding the storefront, map the operating model.

Start with what SFCC is doing for the business

The first mistake is treating SFCC as only a store database.

For many brands, Salesforce Commerce Cloud is carrying more than product and order data. It may define catalog hierarchy, master and storefront catalogs, product attributes, price books, promotions, inventory feeds, content slots, jobs, search behavior, customer groups, locale rules, and integrations with ERP, OMS, PIM, CRM, loyalty, support, tax, and fulfillment systems.

Salesforce's B2C Commerce import and export documentation describes import and export as the way B2C Commerce data moves between the platform and backend systems. The B2C Commerce schema reference shows how many object types can sit behind that movement.

That does not mean every object deserves to move as-is. It means the team needs to know what each object does before deciding where it belongs in Shopify.

Create an inventory of operating responsibilities:

• What defines products, variants, attributes, categories, bundles, and merchandising rules?
• What defines price, currency, discount, promotion, and customer-group behavior?
• What creates and owns inventory availability?
• What content is managed in SFCC, and what should move into Shopify, a CMS, or a theme section?
• What jobs, feeds, cartridges, and integrations are critical to daily operations?
• Which workflows are technical debt that should be retired instead of rebuilt?

The goal is not to reproduce SFCC inside Shopify. The goal is to preserve the business rules that still matter and simplify the ones that do not.

Map catalog structure before design starts

Catalog mapping should happen before visual design.

If the team starts with page templates, it may miss the product decisions that shape every collection, PDP, search result, recommendation block, email segment, and feed.

Shopify's migration guidance positions products, customers, orders, gift cards, certificates, discounts, reviews, and website content as essential data areas to plan during a move. For SFCC migrations, product data usually needs extra attention because the old catalog model may not map cleanly to Shopify's product, variant, collection, metafield, market, and metaobject structure.

Before design starts, decide:

• Which SFCC product attributes become Shopify options, variants, metafields, metaobjects, tags, or search filters?
• Which categories become collections, navigation groups, landing pages, or merchandising rules?
• Which product relationships need to survive for bundles, accessories, replacement parts, subscriptions, or recommendations?
• Which catalog fields are only legacy admin clutter?
• Which fields need to feed Klaviyo, search, marketplaces, ERP, support, or reporting after launch?

This is where a migration becomes an operating cleanup. A clean Shopify catalog is not only easier to merchandise. It is also easier to automate, segment, search, translate, and connect to AI workflows later.

Translate price books and promotions into Shopify decisions

SFCC often carries pricing and promotion logic that feels normal to the team because it has been there for years.

That logic still needs to be challenged. A migration is the right moment to ask which price books, customer groups, coupons, promotions, campaign rules, and exceptions are still part of the business model and which ones are leftovers from old campaigns.

Map the pricing layer before choosing the Shopify implementation:

• Markets, currencies, duties, taxes, and regional catalogs.
• B2B, wholesale, staff, VIP, loyalty, and customer-specific pricing.
• Automatic discounts, coupon codes, free gifts, bundles, subscriptions, and tiered offers.
• Promotion conflicts and priority rules.
• Margin rules for launch, email, SMS, affiliate, retail, and marketplace channels.

Some logic belongs in Shopify. Some may belong in Shopify Functions, apps, ERP, loyalty, subscription tooling, or custom middleware. The important part is deciding from the rule, not from the app list.

If nobody maps this layer, the migration team can accidentally rebuild a discount system that the brand no longer understands.

Treat customers and order history as operational context

Shopify's migration page lists essential store data such as products, orders, customers, reviews, and SEO integrity as migration concerns. That is the right starting point, but SFCC to Shopify customer migration should go deeper than moving names and emails.

For the business, customer data is context:

• Can the customer access their account after launch?
• Can support see order history and past issues?
• Can Klaviyo or another lifecycle platform understand previous purchases?
• Can loyalty, subscription, warranty, return, and retail history be interpreted?
• Can finance and operations reconcile historical orders?
• Can consent and suppression rules be trusted?

Decide what needs to move into Shopify, what needs to remain in another system, and what only needs to be available for reporting or support. Do not assume every historical field needs to appear in the storefront. Also do not assume a basic customer import is enough for lifecycle marketing, service, and retention.

This is especially important if the brand has retail, wholesale, B2B, international stores, loyalty, subscriptions, or high support volume. Those customers do not experience the migration as a technical project. They experience it as whether they can log in, reorder, get help, use a benefit, or trust the brand after launch.

Build the SEO map before URLs change

The SEO migration should start before the new Shopify theme exists.

For SFCC, the team needs a complete URL inventory, not only a list of current navigation pages. Pull URLs from the platform, sitemap, analytics, GSC, backlinks, paid landing pages, email links, marketplace feeds, old campaign pages, and any legacy locale or campaign structure that can still receive traffic.

Then decide:

• Which URLs map one-to-one to Shopify products, collections, pages, articles, or landing pages?
• Which URLs should consolidate into a stronger destination?
• Which pages should be rebuilt, retired, redirected, or left out?
• Which metadata, headings, structured data, and internal links need to survive?
• Which filters, search URLs, locale URLs, and old campaign URLs should not be indexed?
• Who monitors 404s, rankings, sitemap coverage, and crawl behavior after launch?

This is where many migrations lose trust. The new site can look clean while search engines, affiliates, email archives, and customers keep hitting old paths.

Do the URL work early. The redirect map should be a launch artifact, not a last-week spreadsheet.

Replace integrations intentionally

SFCC stores often have years of integration decisions hidden behind cartridges, jobs, feeds, middleware, and vendor-specific workflows.

Shopify has a strong app and API ecosystem, but that does not mean every old integration should be replaced one-for-one. Start with the business process:

• What creates product data?
• What updates inventory?
• What owns order routing and fulfillment?
• What owns customer service history?
• What owns email, SMS, loyalty, subscriptions, reviews, search, personalization, and returns?
• What data needs to move in real time, on a schedule, or only for reporting?
• What failure alerts does the team need before customers notice?

The answer may be a Shopify app, a native Shopify feature, a custom integration, middleware, or a retired workflow. The migration should simplify the system where possible, not recreate every old dependency with a new logo.

Test business scenarios, not only pages

A migration is not ready because the homepage, collection page, PDP, cart, and checkout look good.

It is ready when the business scenarios work.

Test scenarios like:

• A customer buys a product with variants, discounts, tax, shipping, and inventory rules.
• A returning customer needs account access or support history.
• A merchandising team launches a collection, changes product data, and updates a promotion.
• An order flows from Shopify to fulfillment, ERP, support, and lifecycle marketing.
• A customer returns, exchanges, cancels, subscribes, or buys again.
• A high-value organic URL redirects to the right Shopify destination.
• Klaviyo, search, analytics, consent, and reporting receive the right events.
• A failed feed or job creates an alert someone owns.

That test plan should be built from the operating map. If the map is thin, QA will be thin too.

Use the migration to simplify how the team runs ecommerce

The best SFCC to Shopify migrations do not ask, "How do we copy the old system?"

They ask, "What does the business need to run better after this move?"

That changes the work. Catalog cleanup becomes a merchandising and automation foundation. Customer migration becomes a retention and support decision. SEO mapping becomes a traffic-protection plan. Integration replacement becomes an operating-model review. QA becomes proof that the team can run the store, not just that the site renders.

Lake House Group treats Shopify migrations as operating-system work, not only platform implementation. If your team is moving from Salesforce Commerce Cloud to Shopify and needs the catalog, customer, SEO, lifecycle, and integration map before the rebuild, talk to Lake House Group about Shopify migration.