Switching from Searchspring to Layers: A Shopify Plus Migration Guide

If you run a Shopify Plus store on Searchspring and you are weighing a move to Layers, start with the honest part. Searchspring's merchandising console is well-earned, and merchandisers have owned it for years.

So this guide skips the teardown. It walks through what changed under Searchspring, what you run today, what ports over, and what you rebuild.

Why are Searchspring customers looking right now?

Because the platform they chose is being folded into a different one. In January 2025, Searchspring combined with Klevu and Intelligent Reach into a single company, Athos Commerce, backed by the growth-equity firm PSG.

Searchspring is now an Athos product. The three brands are being folded into one rebuilt stack.

Athos has published the timeline. The new platform reaches general availability in Q1 2026 after a slip from 2025, and the legacy platforms retire from 2027.

So the decision is not "stay put versus move." You are migrating regardless. The only question is where you land: Athos's new platform, or a tool built only for Shopify Plus.

None of this makes Searchspring a bad product. The ground under it is moving, and that is reason enough to look at your options.

Should you switch from Searchspring to Layers?

Switch if you are done running a platform-agnostic suite on quote-only pricing, you want real-time catalog sync, and you want native Shopify depth your team controls.

Stay on Searchspring, or move to Athos, if you sell across Magento or BigCommerce too, or if Searchspring's merchandising heritage is the one thing you care about and the ownership change does not bother you.

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

• One Shopify Plus store, or a Markets setup, not a multi-platform estate.
• A team tired of negotiating a quote-only bundle with no published plan matrix.
• A merchandiser who wants native Shopify context, not a copy of the catalog behind a JS layer.
• A team that would rather own its storefront markup than run a vendor's hosted Snap components.

What are you actually running on Searchspring?

More than a search box. A live install has five moving parts, and each one behaves differently the day you move off it.

1. A platform-agnostic suite on a quote. Site Search, Merchandising, and Personalization run across Shopify, BigCommerce, and Magento. Pricing is quote-only, with no published plan matrix, so you negotiate blind.
2. A daily catalog copy with a delta layer. Searchspring ingests a copy of your catalog and indexes "at least daily," with Live Indexing adding near-real-time single-product updates on Shopify. Behavioral ranking runs on IntelliSuggest tracking.
3. A JS layer in your theme. Searchspring renders your search and category UI through Snap, its AJAX front-end components injected into the storefront, plus the template and script wiring that goes with it.
4. Tuning locked in the console. Boosting rules, campaigns, and IntelliSuggest scores live in the Searchspring console. The merchandising is strong, but the tuning data does not export.
5. Synonym and redirect upkeep. Relevance leans partly on synonym and redirect lists your team keeps in the console, term by term.

What changes when you move to Layers?

The suite collapses to one bundle, the sync goes real-time, and your catalog stops being a feed. Here is the map.

What ports over, and what you retire?

Two things port: your synonym and redirect lists, and the few boost rules that encode a real merchandising call. The rest stays behind. Campaigns and IntelliSuggest scores have no clean export, and we relearn those signals from your shoppers after cutover anyway.

Your synonym and redirect logic is worth carrying across, at least the handful of terms that still matter. You re-enter those on Layers rather than lifting a live export.

Your boosting rules, campaigns, and IntelliSuggest scores live in the Searchspring console with no export, so those get re-authored, not migrated.

On Layers, the ongoing tuning work shrinks. There are no synonym lists to keep, because our query understanding expands queries automatically. You can still add an explicit synonym when a brand term needs it.

The IntelliSuggest scores you cannot export do not need porting either. Layers starts learning from your shoppers at cutover and keeps tuning.

Expect a short ramp as it gathers signal. We re-author the boost rules that reflect a real decision up front, so nothing important waits on the model.

How does the migration actually work?

A staged switch, not a big-bang cutover. You build and prove it on a draft theme first, before a single shopper sees it. Then you publish and move template by template, with your old theme ready to restore.

1. Map your URLs and config first. Record Searchspring's synonyms and search-term redirects, and scope which search and collection URLs stay put. Those URLs live in your Shopify theme routes, so they hold through the switch and you rarely need SEO 301s.
2. Install Layers and sync the catalog. Installing the app syncs your catalog through real-time webhooks at the store level. Nothing shopper-facing changes yet.
3. Rebuild the storefront UI on a draft theme. This is the real work. Snap was rendering your search and category UI, so that UI gets rebuilt on the Layers SDK, and our team owns the build. The app embed handles auth, tracking, and redirects with no theme code.
4. Validate before you publish. Preview merchandising on your live storefront with live preview, and validate search on the draft theme, confirming collection pages stay server-rendered with crawlable product links. Searchspring keeps serving production.
5. Bring over the little that ports, retire the rest. Re-enter your synonyms and redirects if you still want them, re-author the handful of boost rules that reflect a real decision, and drop the synonym maintenance for good.
6. Publish, and cut over template by template. Both systems can coexist behind template gates during the transition. We scope tracking per template so events are not double-counted, and revenue reads from your native Shopify order data, one source of truth.
7. Prove each surface, with rollback ready. Validate ranking changes with Layers' sort-order experiments (in beta, comparing Layers sort orders against each other) or a matched pre and post read. Rollback stays instant.
8. Retire Searchspring last. Only after cutover, remove the Snap embeds and injected snippets, strip the theme includes, and cancel the Searchspring subscription.

How do we de-risk the switch?

Yes, this is an engineering project, and the frontend rebuild is the bulk of it. 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 re-platforming.

We do not A/B test Layers against Searchspring. You de-risk with a phased rollout, so each surface goes live only once it is proven on a draft theme.

Then you check ranking changes against a sort-order experiment, which compares Layers sort orders against each other, or a matched pre and post read.

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

📌 CUSTOMER PROOF PLACEHOLDER

Replace with a named Searchspring-to-Layers switch quote once we have one on record. We do not have a public Searchspring migration to cite yet, so this guide should not imply one. The proof below is a platform migration and a developer view, both real and used honestly.

Rainbow Shops came off Salesforce Commerce Cloud rather than Searchspring, but the outcome is the one that matters here: a merchandising team that got its control back.

David Cost, their VP of eCommerce, said 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."

On the frontend rebuild, 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 Searchspring does that Layers does not, and the reverse

Credit where it is due. Searchspring's merchandising is its heritage: a drag-and-drop console with scheduled and segmented campaigns, dynamic pinning, and up to 15 custom sort options.

It is platform-agnostic, so it works across Magento and BigCommerce, and since the merger it also ships real semantic search. If you sell on several platforms, that reach is a genuine advantage.

What we do that Searchspring does not: we assume Shopify Plus from the ground up, in one bundle.

Real-time webhook sync instead of a daily batch, one index for every Market, native metafields and B2B catalogs, and ranking that adds return rate to your sort score.

The trade-offs are real:

• We only serve Shopify Plus, not Magento or BigCommerce.
• Our review volume is younger than a decade-old platform's.
• We do not do email or marketing personalization.
• You build your storefront markup on our SDK, not Snap's hosted components.

If those are dealbreakers, Searchspring or Athos may be the better fit, and that is fine.

What does this cost?

Searchspring does not publish a plan matrix. Directory listings cite starting tiers around Essential $699, Advanced $899, and Expert $1,099 a month.

Athos's newer Onsite, Offsite, and Complete Discovery tiers are all quote-only, with no published price.

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 Searchspring? Partly. Your synonyms and redirects are worth re-entering, though the console offers no clean export. Boosting rules, campaigns, and IntelliSuggest scores can't be exported at all. You re-author those on Layers rather than migrate them.

What about the Athos migration and the 2027 sunset? That is the reason to run this comparison now. Searchspring customers face a move onto Athos's rebuilt platform on the sunset timeline regardless, so the real question is the destination, not whether to move.

Be clear-eyed that the paths differ. Athos describes a lighter "upgrade path" for Searchspring customers, while moving to Layers means rebuilding the storefront UI on our SDK.

We take that build on, and we will not pretend the two migrations are identical.

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.

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

Do I have to rebuild my search UI? Yes. Searchspring renders your storefront search UI through Snap, so moving off it means rebuilding that UI on the Layers SDK. Our team does that build during onboarding. The app embed handles the plumbing with no theme code.

How long does it take, and do I need engineers? Not on your side. Theme implementation, SDK wiring, and cutover are handled by our team.

A standard theme often goes live in around a week, and a heavily customized storefront takes longer, because the frontend rebuild is the gate, not sync speed. We scope the timeline against your actual theme before you commit.

Does Layers support Shopify Markets and B2B? Yes, from a single index. Markets configuration, per-country pricing, 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 Searchspring does today, and give you the staged migration plan before you decide anything.

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