Key takeaways
- SFCC sorting rules weight multiple attributes together. Shopify's native collection sort uses one criterion at a time. That single difference is the root of most post-migration merchandising complaints.
- Shopify's 2026 collections release closed real ground on membership: multi-source collections, variant-level targeting and Sidekick setup mean deciding what belongs in a collection is no longer the weak point. It did not change how collections are ordered, which is still one key at a time, and ordering is where SFCC merchandisers spend their time.
- Einstein predictive sort and Einstein recommenders have no native Shopify equivalent. Neither does A/B testing a collection's sort order.
- The capabilities are recoverable without custom code. KARL LAGERFELD went live on Shopify with around 100 category and listing pages built, and kept merchandising with their business team, not developers.
- Settle this while the plan is still being scoped, not after launch. Rebuilding merchandising logic post-launch is the expensive path.
You've decided to leave Salesforce Commerce Cloud. The agency is picked, the SOW is signed, the data mapping is scoped, and somebody has started filling in the parity spreadsheet. Then you reach the row marked sorting rules, and there's nothing obvious to put in the Shopify column.
That's not a gap in your plan. SFCC merchandising isn't a feature you export. It's logic your team built over years, and Shopify's data model hasn't got a slot shaped like it. Your products will move cleanly. The rules that decided what shoppers saw first won't.
So this page is written for whoever is filling in that spreadsheet, which in practice is usually the agency's solution architect and the merchandising lead between them. It goes capability by capability: what SFCC does, what Shopify does natively, where the real gaps are, and what closes them.
SFCC merchandising on Shopify: what maps, what does not
The pill on each row says how Shopify native handles that capability on its own, before any app.
| Capability | On SFCC | Shopify native | The gap | With Kimonix |
|---|---|---|---|---|
| Sorting rulesNative: no equivalent | Rank products on category and search pages, weighting several attributes together. Scoped at category, search or global level. | Six fixed options: relevance, best selling, product title, price, creation date, manual. One criterion at a time. | No way to weight profit, conversion rate and stock depth together in a single order. | Sorts on a library of 100+ parameters, blended into one weighted score. Each sorter carries a weight of 1 to 100 and a direction, for example units sold at 100, conversion rate at 70, in-stock variant ratio at 40. A shop-level Search & Agent strategy applies the same approach to storefront search ranking, so merchandising priority and relevance are blended, not separate. |
| Boost and bury rulesNative: partial | Elevate or suppress specific products by condition. | Product boosts in the Search & Discovery app, assigned per search term (up to 10 terms per product). | Boosts apply to search results, not collection pages, which is where most catalog browsing happens. | Rule-driven ordering applies across every collection, not only search. |
| Explicit or static sortingNative: at parity | Merchandisers pin products to fixed positions. | Manual sort in a visual grid: drag to reorder, or move a product to a numbered position. | At parity, and the 2026 grid made it better. Manual order and automated order remain mutually exclusive. | Pins hold the positions you set, by typed position number or drag, and everything unpinned sorts around them. |
| Dynamic attributesNative: no equivalent | Calculated values usable as sort inputs. | None. Sorting reads only the six built-in criteria. | No computed or derived signals can influence order. | Most sorters are computed, not read off the product: conversion rate, in-stock variant ratio, real margin, days since restocked, aggregated over a lookback window of up to 90 days. Not freeform formulas, you weight a fixed library of sorters. |
| Category assignmentNative: ahead | Classification and primary categories supporting deep hierarchies. | Multi-source collections (2026 release): automatic conditions, hand-picked products, other collections and app sources combined in one collection, with variant-level targeting and Sidekick setup. | Much closer than it used to be. Hierarchy is still flatter than SFCC, but membership logic is genuinely capable. | Filters read computed performance metrics (units sold, conversion rate, margin) as well as attributes and metafields, and can test against a catalog statistic such as the median instead of a fixed number. Applies to collections Kimonix creates or takes over. |
| Search refinementsNative: partial | Faceted navigation, including store-inventory refinement. | Filters via the Search & Discovery app. | Narrower faceting, and less control over how refinements behave at scale. | Kimonix Agentic Search, a separate shopper-facing app, covers the query side with conversational on-site search. It isn't a faceted-filter replacement, so refinement depth still comes from Search & Discovery or a dedicated filter app. |
| Einstein predictive sortNative: no equivalent | Personalizes result order per shopper using shopper-to-product affinity. | None. | No native way to vary collection order by individual shopper. | Personalization re-ranks the collection live at request time for the individual shopper, and can also restrict which products serve to them. Requires the storefront collection block in the theme. |
| Einstein recommendersNative: no equivalent | Rule-based recommendation lists with promote, demote and hide controls. | Basic related-product recommendations. | Little merchant control, and recommendations are disconnected from collection logic. | Recommendation elements run on the same engine and strategy schema as collection sorting, with the same sorters, filters and boosts, so the two cannot contradict each other. They render live from a theme placeholder. |
| Merchandising A/B testingNative: no equivalent | Available through Einstein and Control Center. | None for collection sort order. | No native way to prove a merchandising change actually helped. | Runs a collection's current order against a challenger strategy on live traffic, splitting shoppers between variations. Reports views, conversion rate, sales and profit per variation, then applies the winner or reverts. |
If you read one row, read the first. SFCC sorting rules weight several attributes at once. Shopify's native collection sort uses exactly one. That sounds abstract until you have to choose. Sort a collection by best selling and the top slots fill with products that have been live for three years. Sort by newest and you bury the things that actually convert. Sort by price and you ignore both. On SFCC you weighted all three and let stock level break the tie. That is the capability with nowhere native to land.
Why merchandising is the capability that gets missed
Migration plans are organized around things that are visibly broken when they are wrong. If products do not import, you know immediately. If redirects are missing, rankings fall and someone raises it within a week. Merchandising fails differently: everything looks fine at launch, because the collections exist and they contain the right products.
What has actually happened is that a system which used to order products by several business signals at once is now ordering them alphabetically, or by all-time order count, which quietly favors long-lived products over the ones you need to sell this season. Nothing errors. Conversion on category pages just sits lower than it used to, and it takes a quarter to attribute it.
The other reason it gets missed is ownership. Merchandising logic tends to belong to a merchandising team, and the capability mapping tends to be run by engineering and the agency. The capability is genuinely well understood inside the business and genuinely invisible on the migration plan.
Three honest ways to close the gap
Rebuild it in code
Shopify Functions and metafields make it possible to express custom sort logic, and for a small number of well-defined rules this is a reasonable answer. It is also the option that reproduces the problem you were trying to leave behind, because every subsequent change to merchandising becomes a development ticket. Brands who moved off SFCC to get away from developer dependency should weigh that carefully.
Accept Shopify native and simplify
Native Shopify is a stronger answer in 2026 than it was a year ago. Multi-source collections, variant-level targeting and Sidekick handle membership well, and for a catalog in the low hundreds with straightforward seasonality that plus the Search & Discovery app genuinely may be enough. That is worth saying plainly. The judgment call is not really catalog size, it is how many business signals drive your ordering. If the honest answer is one, native is fine. If it is profit plus stock depth plus conversion rate, native still sorts on one key at a time and cannot express that.
Use a merchandising layer
The third option keeps the logic outside both the theme and the developer queue. Kimonix sorts on a library of 100+ parameters blended into a single collection order, so units sold, conversion rate and in-stock variant ratio all pull on the same ranking, handles product recommendations on the same engine, and includes A/B testing so a sorting change can be proven instead of assumed. Because the rules live in an interface, not the codebase, the merchandising team keeps them.
This is also the option that fits the way SFCC teams already work. Merchandisers used to owning sorting rules keep owning them, which is usually the difference between a migration that preserves capability and one that quietly downgrades it.
What this looked like for KARL LAGERFELD
KARL LAGERFELD moved from Salesforce Commerce Cloud to Shopify to gain agility and business autonomy, working with Domaine as migration partner. The known risk going in was the one described above: complex product sorting and category rules that had needed technical setup on SFCC, with no default equivalent on Shopify.
Rather than rebuild that logic in code, merchandising was handled as a separate layer from the commerce foundation. The brand went live with around 100 category and listing pages built, and gained visibility into listing page performance through CTR reporting that had not previously been accessible to the business team.
The part that matters more than launch day is what happened afterwards. The business team manages merchandising themselves, across markets, without routing changes through IT or external developers. Read the full KARL LAGERFELD case study.
Settle these before the build starts
Which business signals currently drive sort order, and how many at once?
If the answer is more than one, native Shopify sorting cannot reproduce it, and better to find that out in planning than in peak season.
Who owns merchandising changes today, and who should own them after launch?
If the honest answer is that merchandisers own them now, a code-based rebuild moves that ownership to engineering, which is usually the opposite of the migration's stated goal.
How deep is the category hierarchy, and what breaks if it is simplified?
Some flattening will be proposed, since it is Shopify's own guidance. Multi-source collections absorb more of that than they once did, so decide it deliberately instead of accepting it as a fixed constraint.
How will you know whether the new merchandising is working?
SFCC teams generally have Einstein reporting. Without a testing and reporting layer on Shopify, a drop in category page conversion is very hard to attribute.
If you want per-shopper or per-market ordering, schedule the theme work now.
Those orders are served live from the storefront, which means a collection block has to exist in the theme template. During a replatform the theme is being built from scratch anyway, so it costs almost nothing to include and is a retrofit if you skip it. Recommendation elements need their own theme placeholder for the same reason. For brands running Shopify Markets the same block carries per-market ordering computed against each market's own inventory.
How a SFCC migration actually runs
The mechanics of an SFCC migration are well covered elsewhere, and by people who do them for a living. In outline: a discovery and parity phase, data extraction from SFCC, storefront and theme rebuild, integrations back to OMS, ERP and PIM, SEO and redirect mapping, then testing and cutover. Complex enterprise migrations commonly run in months, not weeks.
SFCC's data and templating model does not map one to one onto Shopify, so this is a re-architecture, not a copy. That is precisely why the merchandising parity question above is worth settling early: it is a design decision, not a post-launch configuration task.
For the migration itself, Shopify's own enterprise material is the best starting point, and an experienced migration partner is worth more than any guide.
Discovery and parity
Everything SFCC does gets mapped to a Shopify equivalent. Sorting rules, refinements and Einstein logic are the rows that come back blank.
Merchandising gets decided here, or not at all
Data extraction
Catalog, customers and order history out of SFCC. The records move cleanly; this is the well-trodden part.
Storefront and theme build
Rebuilt, not ported. SFCC's templating model has no Shopify equivalent, so this is a re-architecture.
Back-office integrations
OMS, ERP and PIM rewired. Usually the longest pole in the tent on an enterprise move.
SEO and redirect mapping
Every old URL gets a destination. The most common cause of post-migration traffic loss sits here.
Testing and cutover
UAT, then go live. Finding a merchandising gap at this point means launching with it.
- Shopify: Ecommerce Replatforming and Migration Guide
- Shopify Help Center: Migrate to Shopify
- Shopify: Ecommerce Data Migration Guide
Frequently asked questions
Does Shopify have sorting rules like Salesforce Commerce Cloud?
+
Not natively. Shopify offers six collection sort options: relevance, best selling, product title, price, creation date and manual order, and applies one of them at a time. SFCC sorting rules weight several product attributes together and can be scoped to a category, to search, or globally. Reproducing that on Shopify needs either custom development or a merchandising app.
What happens to Einstein product recommendations when you migrate to Shopify?
+
They do not transfer. Einstein recommenders and Einstein predictive sort are Salesforce Commerce Cloud features and have no native Shopify equivalent. Shopify provides basic related products. Brands that relied on Einstein for personalized ordering or recommendation rules generally replace it with a Shopify app during the migration, not after it.
Do I lose my category structure moving from SFCC to Shopify?
+
Categories become Shopify collections and the products map cleanly. Membership logic maps better than it used to: Shopify's 2026 collections release added multi-source collections, which combine automatic conditions, hand-picked products, other collections and app sources in one place, plus variant-level targeting. What is still flatter is hierarchy depth, and Shopify's enterprise guidance continues to recommend simplifying deep trees instead of reproducing them. Conditions built on performance signals such as gross profit, conversion rate or in-stock variant ratio remain outside what native conditions can express.
How long does a Salesforce Commerce Cloud to Shopify migration take?
+
Complex enterprise migrations commonly run in months, not weeks, because SFCC's data and templating model does not map one to one onto Shopify and the back-office integrations (OMS, ERP, PIM) have to move with it. Timelines are best scoped with an experienced migration partner. The merchandising parity decision should be made early in that timeline, since it is an architectural choice, not a configuration task.
Can I keep my merchandising logic when migrating from SFCC to Shopify?
+
Yes, though not by exporting it. The logic has to be re-expressed on Shopify, either in code using Shopify Functions, or in a merchandising layer that scores collections on business signals. KARL LAGERFELD took the second route during their SFCC to Shopify migration and went live with around 100 category and listing pages, with their business team continuing to manage merchandising afterwards without developer involvement.
What data needs to be in place before Kimonix merchandising works?
+
Most sorting signals work from Shopify order and traffic data with nothing extra. Three depend on data you have to supply. Profit and margin sorters need cost-per-item set on your Shopify products, and without it those values come back empty and the sort quietly stops doing anything useful, so it's worth confirming cost data exists before relying on it. Rating and review-count sorters need a connected reviews app. Ad-performance sorters such as ROAS and CPA need Triple Whale connected, and return-rate logic needs Loop Returns connected. Separately, per-shopper and per-market ordering are served live from the storefront, so they need the Kimonix collection block present in your theme template, not just the app installed. On an SFCC migration the cost-per-item question is the one to raise early, because product cost often lives in the ERP, not the storefront.
Is Shopify's Search & Discovery app enough to replace SFCC merchandising?
+
It covers part of it. Search & Discovery handles filters, synonyms and search-side boosts, which addresses some of what SFCC search refinements did. It does not provide multi-attribute collection sorting, per-shopper ordering, or A/B testing of sort order. Whether that is sufficient depends on catalog size and how many business signals drive your merchandising today.
Related reading
- Kimonix collection sorting
- Product recommendations
- Merchandising A/B testing
- Localized merchandising with Shopify Markets
- KARL LAGERFELD case study
- Pricing
Planning the move?
If merchandising parity is on your SFCC migration plan and the Shopify column is still empty, that is the conversation worth having before launch, not after it.
We can walk your parity spreadsheet with you, row by row.
Book a demo with us today!