Switching from Constructor.io to Layers: A Shopify Plus Migration Guide

If you run a Shopify Plus store on Constructor.io and you are weighing a move to Layers, here is the honest version.

Constructor.io built real AI, and its ranking is good. What grinds teams down is everything around that ranking on Shopify: a batch feed, an index per market, and a storefront you wired up and now have to keep alive.

This guide is the technical walk-through. What you are actually running today, what maps to Layers and what does not, why the migration is lighter than it looks, and how we de-risk the cutover so your revenue never sits on the line.

Should you switch from Constructor.io to Layers?

Switch if you run one Shopify Plus store, or a Shopify Markets setup, and you are paying an enterprise price for a platform that treats Shopify as one connector among many.

Stay on Constructor.io if you run search across several ecommerce platforms, or your catalog and traffic are large enough that its models clearly earn their contract.

We only build for Shopify Plus. If Shopify is not your whole world, we are the wrong tool, and we will say so early.

The teams that switch and are glad they did tend to share a profile:

• One Shopify Plus store, or a Markets expansion, not a multi-platform estate
• A mid-market catalog paying an enterprise contract that the traffic never quite justifies
• A merchandising team that wants to own sort order without filing an engineering ticket
• A developer team tired of maintaining a bespoke search frontend and a tracking pipeline

What are you actually running on Constructor.io?

More than a search box. A live Constructor.io integration is a pipeline, a tracking layer, and a custom storefront, and every piece of it is yours to unwind when you leave. Five things make up the surface.

1. A batch feed pipeline. Constructor.io ingests your catalog as feed files over HTTP or FTPS, with a daily full sync and deltas no more than every five minutes. It is a batch model, and a catalog change takes 30 to 40 minutes to propagate across your store.
2. A required tracking beacon. With either a frontend or backend integration, a JavaScript beacon is still required across your storefront to capture clicks and conversions and train the models. It is hand-wired, and it is load-bearing.
3. A search UI you built. Constructor.io's client library does not render results in the DOM. Rendering the search page, the autosuggest, and the collection grids is left to you, through Constructor.io's UI libraries or your own code.
4. Hand-authored config with no clean export. Synonyms and redirects are manually entered in the dashboard, and there is no first-class "export my configuration" path. The only way we have found to pull it out is to script GET calls against the API endpoint by endpoint.
5. A platform-agnostic core bolted to Shopify. The Shopify connector is read-only and pulls your catalog through the Admin GraphQL API, dropping Liquid UI components into your theme. In practice it also means a separate index per market and per language, rather than one index for all of them.

None of this is theoretical. A 9-figure haircare brand documented all of it before they moved to Layers. On Constructor.io:

• Every catalog change took 30 to 40 minutes to sync, and the sync slowed the storefront while it ran.
• Recommendation pods they set by hand took five minutes to two days to appear, and the "frequently bought together" pod never worked right without custom code.
• Adding one new metafield meant waiting on the Constructor.io team, with site downtime.
• Search filters had to be reset by hand on every collection, and hiding a few collections from the filters once wiped them off the site entirely.
• Switching a storefront from one market's index to another returned empty best-seller pages and sent shoppers to a broken URL.
• Color filtering they needed for part of their catalog was not supported.
• Long search queries returned "undefined" in the search bar.

Their own summary: "Because so much manual work was required to keep the platform working at a comparative level with manual merchandising, we had limited opportunity to focus on analytics or optimization."

What changes when you move to Layers?

The short version: the pipeline gets shorter, the index gets singular, and your catalog stops being a feed and starts being your actual Shopify store. Here is the map.

You delete your config, you do not port it

Migrations feel terrifying because you assume you have to carry everything across. With Constructor.io, you mostly cannot.

Synonyms, redirects, and searchandising rules are hand-authored with no bundled export, so lifting them out means scripting API calls one endpoint at a time. The personalization models and the clickstream that trained them stay on Constructor.io's servers and do not transfer.

On Layers, most of that config is unnecessary. Our query understanding expands queries automatically, informed by your actual catalog, so there are no synonym lists to migrate, because there are none to keep.

You carry over the handful of redirects and rules that encode a real business decision, and you delete the rest. There is no export to wrestle out of Constructor.io, because there is almost nothing to move.

How does the migration actually work?

A staged switch, not a big-bang cutover. You build and prove it on a draft theme before a single shopper sees it, then publish and move template by template, with your old theme one revert away.

1. Map your URLs and redirects first. Before anything gets built, scope which search and collection URLs stay put and which Constructor.io redirects encode a real business decision. URL and redirect parity is planned up front, not patched at the end.
2. Install Layers and sync the catalog at the store level. Installing the app connects to Shopify and syncs your catalog through webhooks. Sync happens at the store level and changes nothing shoppers see until you enable the storefront on a live theme.
3. Build the Layers frontend on a draft theme. Wire the search page, autosuggest, collection grids, and facets to the Layers SDK, and enable the app embed for identity, cart and market context, and event tracking. This is a real theme build, and our team does it. Leave Constructor.io's beacon in place for now; it is still serving your live store.
4. Validate before you publish. Check merchandising on your live storefront with live preview, and validate search in the dashboard test tools and on the draft theme. Nothing shopper-facing has changed yet.
5. Retire the rule debt, rebuild only what matters. Drop the synonym lists. Re-key the handful of redirects and merchandising rules that reflect a deliberate call, and let the engine handle the rest.
6. Publish, and cut over template by template. Publish the theme with Layers wired into the search and collection templates. During the transition, both systems can coexist behind template-level gates. Events fire automatically from the app embed, and purchase and revenue come from your native Shopify order data, so keep both systems instrumented during the parallel run and scope events per surface to avoid double-counting.
7. Prove each surface, with rollback ready. Confirm each surface matches or beats Constructor.io before it stays. Validate ranking changes with Layers' sort-order A/B experiments (in beta) where available, or with a matched pre and post conversion read plus manual relevance QA. Your previous theme is one revert away, so rollback is a click, not a rebuild.
8. Retire Constructor.io last. Only after the final surface is live and has baked do you remove Constructor.io's beacon, client library, and Liquid components from the theme, disconnect the Shopify connector, and confirm the app is uninstalled and billing has stopped.

How do we de-risk the switch?

Yes, it is an engineering project. We run it end to end, from the theme build to the cutover, so it does not land on your team.

Onboarding, catalog sync, theme implementation, and strategy are fully managed, at a fraction of the cost of a legacy rollout.

You prove each surface on a draft theme before it goes live, then check it against an experiment or a matched pre and post read before it stays.

Your previous theme is one revert away, so if a change hurts conversion, you put the old one back in a click.

The haircare brand above is one example. Rainbow Shops is another. They came off Salesforce Commerce Cloud rather than Constructor.io, but the outcome is the one that matters here: a merchandising team that got its control back.

In the words of David Cost, their VP of eCommerce, Layers "was the first time we were able to create the kind of sort orders we were used to having in Salesforce," with "a pretty immediate impact on conversion rate."

What Constructor.io does that Layers does not, and the reverse

Credit where it is due. Constructor.io runs genuine machine-learning ranking across many signals, it serves retailers on any platform, and at very large scale its models are excellent.

If you need one discovery engine across Shopify, Salesforce, and a custom stack at once, that platform-agnostic design is a feature, and we are not it.

The storefront build does not go away. Like Constructor.io, we render through your theme, so the search page and collection grids are markup you wire to our SDK.

The difference is what you wire to:

• A maintained SDK with ready-made controllers for search, autocomplete, facets, and sort.
• An app embed that handles identity, context, and event tracking.
• A team that does the build for you, instead of leaving you to babysit a bespoke integration.

Jason Hassold, Founder and Lead Developer at Negative Space, put it this way: "the SDK is easy to use and gives us the flexibility to build any search experience a merchant can imagine. The team's Shopify dev agency roots mean they actually get what dev partners need."

What else we do that Constructor.io does not: we assume Shopify from the ground up. One index for every Market and language, real-time sync instead of batches, native reading of your metafields and metaobjects, and merchandising a non-engineer can run.

The trade-offs are real. We only serve Shopify Plus, our review volume is younger than a ten-year-old platform's, and we do not do email or marketing personalization.

If those are dealbreakers, Constructor.io may be the better fit, and that is fine.

What does this cost?

Constructor.io does not publish pricing; it is enterprise, quote-only. Third-party aggregators put average contracts near six figures a year, though those are estimates, not vendor figures, so treat them as directional.

We price on your last 12 months of collection page views and total search requests, up to 40% below legacy platforms with no six-figure floor.

Usage is uncapped with no overage charges, and all four products are bundled with no feature gating. You can see AI Search, Merchandising, and Visual Discovery working on your own catalog before you commit.

FAQs

Can I export my configuration from Constructor.io? Not cleanly. Synonyms, redirects, and rules are hand-authored with no bundled export, so pulling them out means scripting API calls endpoint by endpoint, and the ML history does not transfer.

On Layers you retire most of it rather than migrate, because our engine expands queries automatically without synonym lists.

Will I lose my search rankings when I switch? Not if you plan for it. Your search and collection URLs live in your Shopify theme routes, so they stay put, and we keep collection pages server-rendered with crawlable product links rather than swapping to a purely client-side grid.

Map your redirects up front and confirm your sitemap, robots, and canonical tags are unchanged through the cutover.

How long does the migration take? A standard theme typically goes live in about a week, since catalog sync is fast and our team runs the build. A heavily customized theme takes longer. The gate is theme implementation, QA, and re-keying merchandising, not sync speed.

Do you need to staff engineers for this? Not on your side. Theme implementation, SDK wiring, and cutover are handled by our team as part of onboarding.

There is real frontend work, the search and collection templates wired to our SDK, and we own it. Your developers only get involved if they want deeper control through the REST API, SDK, and MCP servers.

What happens to my personalization and historical data? Constructor.io's trained models and clickstream stay on its servers. Layers starts learning from behavior on day one and reflects purchase and revenue signals from your native Shopify order data, so ranking improves quickly without importing a history you cannot extract.

Does Layers support Shopify Markets and B2B? Yes, from a single index. Markets configuration, per-country pricing and availability, and B2B catalogs are read natively, so adding a market is a setting, not a new index to stand up.

Ready to see it on your catalog?

We will sync your store to a draft theme, show you Layers running on your real products next to what Constructor.io does today, and give you the staged migration plan before you decide anything.

Book a managed migration and we will do the heavy lifting.