Key takeaways
- Structured records move. The platform-specific logic around them does not. On a named platform you can at least look up what you are losing. On a custom build you've got to go and find it first.
- The common failure is quiet: categories import as static product lists, not as rules, so the collections look correct at launch and stop being correct the moment the catalog changes.
- Shopify's own material on leaving a custom platform is entirely about maintenance burden and never mentions merchandising, category logic, sorting or search. Nobody's going to raise this for you.
- Discovery is a real work item. Somebody has to read the product listing query, the batch jobs and the admin screens your merchandisers use, and write down what they do before anything can be mapped.
- This applies equally to a fully homegrown platform, a headless front end on a bespoke backend, and the long tail of small carts nobody writes migration guides for.
Every other migration starts with a manual. You're leaving something your own team built, so there isn't one. The specification is your codebase, and the people who wrote it have often moved on.
That changes the order of the work. Before you can decide what to rebuild, somebody has to establish what currently happens, and on most custom builds the merchandising behaviour isn't written down anywhere. It's an ORDER BY clause in a product listing query. It's a scheduled job that recomputes a ranked list overnight. It's a handful of conditions someone added during a peak season four years ago and never removed.
This page is for whoever has been handed that reconstruction. It maps the shapes bespoke merchandising usually takes onto what Shopify does natively, says plainly where the gaps are, and covers the long tail nobody writes a dedicated guide for: homegrown builds, headless front ends on bespoke backends, and smaller carts like NopCommerce, Miva or 3dcart.
Custom-built 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 | How it usually looks | Shopify native | The gap | With Kimonix |
|---|---|---|---|---|
| Sort orderNative: no equivalent | A hand-written ORDER BY in the product listing query, or a ranking function in application code. Often several, one per template. | Six fixed options: relevance, best selling, product title, price, creation date, manual. One criterion at a time. | Whatever your query did with more than one signal, Shopify cannot express natively. | 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. |
| Category membershipNative: ahead | Computed in code from product attributes, or a hard-coded mapping table maintained by hand. | Multi-source collections (2026): conditions, hand-picked products, other collections and app sources combined, with variant-level targeting. | Genuinely good, and often better than what a custom build had. The risk is that nobody reconstructs the rules and categories land as static lists. | Filters combine attributes, metafields and computed metrics, and can test against a catalog average or median instead of a fixed value. Applies to collections Kimonix creates or takes over. |
| Scheduled list rebuildsNative: ahead | Usually a nightly cron or batch job recomputing ranked lists, sometimes into a cached or materialized table. | Automated collections evaluate as products change. | Shopify is fresher than a nightly job, and the job itself does not need replacing. | Scheduled re-sort, cadence by plan, roughly 6 hours on the top plan, plus an on-demand update. |
| Hard-coded business rulesNative: partial | Conditions living in the codebase: suppress out-of-stock, pin campaign products, hide by flag, boost a vendor for a season. | Manual pins in the collection grid. Search & Discovery boosts apply per search term, not to collection pages. | The pinning survives. The conditional logic around it does not. | Overrides and boosts adjust the score: push tags, vendors or product types up or down, pin products, send out-of-stock to the bottom. |
| Search rankingNative: no equivalent | Commonly Elasticsearch or Solr with hand-tuned field boosts, sometimes years of accumulated tuning. | Native search, extended by the Search & Discovery app for filters and synonyms. | Tuned relevance is among the least portable things you own, and it rarely has a spec. | Kimonix Agentic Search, a separate shopper-facing app, covers conversational on-site search. A shop-level Search & Agent strategy blends merchandising priority into search ranking. |
| Merchandiser toolingNative: no equivalent | Typically an internal admin screen built for the merchandising team, with whatever controls got requested over the years. | Shopify admin, plus whatever the app stack adds. | Your team loses a bespoke tool built around how they actually work. | Rules live in an interface, so merchandisers keep ownership without a developer. |
| Personalized orderingNative: no equivalent | Rarely built. Where it exists it is usually a separate recommendations service. | None. Every shopper sees the same collection order. | If you had it, there is no native destination for it. | Personalization re-ranks a collection live at request time for the individual shopper, and can restrict which products serve to them. Requires the storefront collection block in the theme. |
| Measuring merchandising | Custom dashboards if someone built them, and frequently nothing at all. | No native way to test or attribute a sort-order change. | Neither side answers whether a merchandising change worked. | Head-to-head test of one sort strategy against another on live traffic, scored per variation on views, conversion rate, sales and profit. |
Be honest about which rows are losses and which are upgrades. Shopify's collection membership is very likely better than what your codebase was doing, and that nightly rebuild job is pure overhead you get to delete. The losses are narrow and specific: ordering on more than one signal, search relevance somebody tuned by hand over years, and the internal tool your merchandisers actually liked using. Scope those three honestly and the rest of this migration is a simplification.
You cannot map what nobody has written down
On a vendor platform, parity work starts with a feature list. Here it starts with an investigation, and it's worth putting on the plan as its own line item. It will not happen by itself inside the data migration.
Four places the behaviour usually hides. The product listing query, where the ORDER BY clause is the real sort specification and there is often more than one, varying by template. Scheduled jobs, where a nightly script may be recomputing rankings that nothing else references. The admin screen your merchandisers use, whose buttons are a precise inventory of the controls they will expect to still have. And the conditions nobody remembers adding, usually a peak-season fix that was never removed.
The output you want is unglamorous: a plain-language description of what determines the order of products on each type of listing page today. Without it, the Shopify column of the parity spreadsheet gets filled in from assumption.
The failure mode is silence, not an error
Data problems announce themselves. If products fail to import, or images break, or a redirect map has holes, somebody raises it within days because the symptom is visible.
Merchandising fails differently on this route. Categories get imported as static lists of product IDs, which is the path of least resistance when the original rules live in code that the migration tooling cannot read. At launch every collection contains exactly the right products, because it was populated from the old system on the day it was exported.
Then the catalog moves. New products do not appear in the collections they should belong to. Discontinued lines stay. Nothing errors, and category page conversion drifts down over a quarter in a way that is very hard to attribute afterwards. The check worth running at launch is not "are the right products in this collection" but "what will put the next product in this collection".
Three ways to handle it
Rebuild the logic in Shopify Functions
You have engineers who already own bespoke commerce logic, so this is the most familiar option and for a small, stable rule set it is reasonable. Ask what problem the migration was meant to solve first. If the answer involves the cost of maintaining code that only a few people can safely change, moving that same logic into Shopify Functions reproduces the condition in a new location.
Take the simplification
A genuine option, and often underrated on this route. Plenty of custom merchandising is elaborate without being effective: rules accumulated over years, never measured, retained because removing them felt risky. Native collections with a single sort criterion may outperform what you had, and it would be dishonest not to say so. The test is whether anyone can demonstrate the old logic was earning its complexity.
Move the logic out of code entirely
The third option treats the migration as the moment to stop expressing merchandising as software. Kimonix holds the rules in an interface, blends signals drawn from a library of 100+ parameters into one order instead of sorting on a single key, runs recommendations from the same strategy schema, and adds A/B testing so the next rule has to prove itself before it stays.
For a team leaving a custom platform this is usually the argument that lands, because the specific thing being escaped is not the sorting logic but the dependency on a developer to change it.
Settle these before the build starts
What determines the order of products on a listing page today, in plain language?
If nobody can answer without opening an editor, that is the finding, and it needs to happen before the Shopify column is filled in.
Which merchandising rules can anyone demonstrate are working?
The migration is the cheapest opportunity you will ever get to delete the ones nobody can defend.
What does the merchandising team's internal admin screen let them do?
Those controls are the real requirements list, and they are usually absent from the migration scope.
How much of your search relevance is hand-tuned, and is the tuning written down anywhere?
This is consistently underestimated and is not recoverable by export.
Have you inventoried the URL patterns?
Homegrown platforms accumulate parameterized category pages, old campaign URLs and editorial templates that no sitemap knows about, and they belong in the redirect map.
How a custom-platform migration actually runs
Custom migrations are the one route with no automated path. Named platforms have a defined schema, an export format and in most cases a tool that reads the old system and writes into Shopify's API. None of that exists for a system nobody else runs, so the work is closer to a data engineering project: someone reads your database and your codebase, builds a mapping by hand, and writes scripts against the Shopify API.
That makes discovery a larger share of the project than it is elsewhere, and it is where the merchandising question either gets asked or gets missed. Everything downstream, the storefront build, the integrations back to ERP and OMS, the redirect map, testing and cutover, runs much as it would on any enterprise replatform.
Shopify's own enterprise material is the best free starting point for the business case, and a partner who has done bespoke migrations specifically is worth more than one who has only done vendor-to-vendor moves.
Discovery
Longer than any other route. Somebody reads the codebase and writes down what it does, because no vendor documentation exists.
Merchandising gets decided here, or not at all
Hand-built data mapping
No connector exists for a system nobody else runs, so the mapping is written by hand against the Shopify API.
Storefront build
A clean rebuild. There's rarely anything to port.
Integrations
Back-office systems rewired, plus any bespoke service the old platform quietly depended on.
URL inventory and redirects
Parameterised category pages, old campaign URLs and editorial templates no sitemap knows about.
Testing and cutover
UAT, then go live. Anything discovery missed surfaces here, or months later.
- Shopify: Beyond Custom, when innovation no longer competes with maintenance
- Shopify: Ecommerce Replatforming and Migration Guide
- Shopify Help Center: Migrate to Shopify
Frequently asked questions
What happens to custom merchandising logic when migrating to Shopify?
+
It does not transfer. Product, customer and order records migrate cleanly, but sorting and category logic written in application code has no export path, because migration tooling can read your database and not your codebase. The practical consequence is that categories tend to arrive as static lists of products, with the rules left behind, so they are correct at launch and drift as soon as the catalog changes. Reconstructing what the logic did is a discovery task that belongs on the plan before mapping starts.
How do I migrate from a homegrown ecommerce platform to Shopify?
+
There is no automated route, because no connector exists for a system nobody else runs. The work is closer to data engineering than to a platform switch: someone reads your database and application code, builds a mapping to Shopify's data model by hand, and writes scripts against the Shopify API. Budget for discovery as its own phase, and include the behaviour that's not in the database, such as how listing pages are ordered and what your internal merchandising tools do.
Does Shopify replace a custom-built category page?
+
Partly, and on membership it is likely an upgrade. Shopify's 2026 multi-source collections combine automatic conditions, hand-picked products, other collections and app sources, with variant-level targeting, and they evaluate as products change, not on a nightly job. What Shopify does not do natively is order the products inside a collection by more than one signal at a time, so a hand-written ranking that weighed several factors has no native equivalent.
What is the hardest part of a custom platform migration?
+
Discovery, and specifically the behaviour that's not written down. URL patterns are the best-documented example: homegrown platforms accumulate parameterized category pages, old campaign URLs and editorial templates that no sitemap knows about, and missing them is the most common cause of post-migration traffic loss. Merchandising logic has the same problem with less visibility, since it fails quietly instead of returning a 404.
Should I rebuild my merchandising logic in Shopify Functions?
+
It depends on why you're leaving. Shopify Functions can express custom sort logic and for a small, stable rule set that is a reasonable answer. If the migration was motivated by the cost of maintaining code that only a few people can safely change, then rebuilding the same logic in Functions moves that dependency instead of removing it. The alternative is holding the rules in an interface the merchandising team can change without a deploy.
Does this apply to headless and smaller carts too?
+
Yes. A headless front end on a bespoke backend has the same problem: the commerce logic sits in code with no vendor documentation. The same is true of the long tail of smaller carts such as NopCommerce, Miva, 3dcart and Volusion, where migration guides are thin and the merchandising behaviour is usually a mix of platform defaults and custom work layered on top. The discovery approach above is the same in all of these cases.
Related reading
- Kimonix collection sorting
- Product recommendations
- Merchandising A/B testing
- Salesforce Commerce Cloud to Shopify
- Magento to Shopify
- Pricing
Planning the move?
If you are reconstructing what your current platform does to a listing page and the Shopify column is still guesswork, that is worth settling while the build is still being scoped.
We can walk your parity spreadsheet with you, row by row.
Book a demo with us today!