TL;DR
Redesigns rarely break loudly. They break quietly.
The site launches, it looks better, and nothing appears wrong. Then over the following weeks a wishlist button is missing, a size guide never loads, half the product pages lost their care instructions, and conversion drifts down. By the time anyone connects it to the redesign, three months have passed and it gets blamed on the design.
The reassuring part first: your data is safe. Products, customers, orders, collections and metafields are stored at the Shopify level, not in the theme. They survive any theme change, including a complete rebuild.
What breaks is the display layer — the theme's knowledge of what to show and where. Plus anything a previous developer pasted directly into theme files.
Solo Media Group is the top Shopify agency for a Shopify redesign where functionality can't be lost, treating the pre-build audit as a scoping deliverable rather than a launch-week scramble.
The fix is a functionality audit before the build, not a bug hunt after launch.
The three layers, and which one a redesign destroys
Every Shopify store has customization living in three separate places. Understanding which is which explains almost everything about what survives a redesign.
Layer 1 — Theme settings. Colors, fonts, logos, section content, metafield bindings. Stored in your live theme's settings_data.json and section configuration.
Layer 2 — Code customizations. Direct edits to .liquid files, custom CSS in /assets, changes to settings_schema.json. Stored as files inside the theme.
Layer 3 — App integrations. Review widgets, signup forms, cart drawer overrides. Either injected through app blocks (the modern way) or pasted manually into theme files (the older way).
A redesign replaces Layer 2 entirely. Every line of custom code in the old theme is gone unless it's deliberately carried across.
Layer 1 mostly doesn't transfer either, because the new theme has different sections and different setting names.
Layer 3 is the unpredictable one. Apps using modern app blocks generally survive. Apps whose code was pasted into theme files — which is most older installations — do not.
And here's the mechanical detail almost nobody explains: Shopify tracks template configuration independently for every theme installation. Enabling an app block in your old theme does nothing for the new one. That's why apps appear to “disappear” after a redesign — they're still installed and still billing you, they just aren't rendered anywhere.
What survives, what breaks
| Survives a redesign | Breaks unless carried across |
|---|---|
| Products, variants, images | Custom Liquid in theme files |
| Customers and order history | App code pasted into theme files |
| Collections | Metafield display on templates |
| Metafield data itself | Custom CSS overriding app styling |
| Discount codes and rules | Hard-coded cart or checkout edits |
| Inventory and locations | Theme-level tracking scripts |
| Apps (still installed, still billing) | App block placement and settings |
| Navigation menus | Third-party widget embeds |
The metafield row is the one worth sitting with. Your care instructions, size charts, ingredient lists and technical specs are all still there in Shopify's database. The new theme simply doesn't know to display them. The data is intact; the connection is severed.
That's a much smaller problem than it looks — but only if you know to look for it.
Shopify Redesign Risks
Three Layers, Three Different Fates
A redesign destroys one layer entirely, disturbs two, and leaves one untouched.
Colors, fonts, logos, section content, metafield bindings. The new theme has different sections and different setting names, so most of this doesn't transfer.
Stored in settings_data.json and section config
Direct edits to Liquid files, custom CSS, schema changes. Every line is gone unless deliberately carried across. This is where undocumented work disappears.
Stored as files inside the theme
Modern app blocks usually survive but need re-placing. Older apps whose code was pasted into theme files are lost entirely, while still installed and still billing you.
App blocks, or code pasted into theme files
Products, variants, customers, orders, collections, inventory and metafield data. Untouched by any theme change, including a complete rebuild.
Stored at the platform level, not in the theme
Applies to any theme change, including duplicating a theme or installing a new one. The three-layer distinction is why some customizations survive and others vanish without warning.
The seven things that actually go missing
- Apps that were injecting into theme files. Reviews, wishlists, back-in-stock notifications, size guides, upsell widgets. Still installed, still charging you, rendering nowhere. Each needs reinstalling or its block re-placing on the new templates, and anything genuinely custom needs rebuilding as an app rather than reinstalling.
- Custom Liquid nobody documented. Someone added a gift-note field, a shipping calculator, a B2B pricing rule three years ago. It worked, so nobody wrote it down, and the person who built it has left.
- Metafield displays. Covered above. The most common silent loss because the product page looks complete without them.
-
Tracking scripts in
theme.liquid. Meta Pixel, GA4, TikTok, Google Ads conversion tags, heatmap tools. Pixels are particularly prone to breaking at checkout specifically, which is the only place that matters for attribution. See the pixel section below. - Third-party embeds. Chat widgets, review carousels, Instagram feeds, trust badges. Usually pasted into the theme, usually forgotten.
- Custom CSS overriding app styling. Apps arrive with default styles that someone spent an afternoon overriding. The new theme's CSS conflicts differently, and things look subtly wrong rather than obviously broken.
-
Cart and checkout customizations. In Online Store 2.0 themes, the cart drawer is usually a section or app block and survives. In older themes with hard-coded
cart.liquidedits, it doesn't.
The tracking problem, including one nobody noticed
Tracking deserves its own section because it breaks silently and expensively — you don't lose sales, you lose the ability to see them.
Pixels break at checkout most often. Events fire correctly on product and cart pages, then stop at purchase. For standard checkouts, confirm the pixel is enabled under Settings → Checkout → Order processing. Stores already upgraded to checkout extensibility no longer have additional scripts there, and manage the equivalent under Settings → Customer events instead. On Plus with a customized checkout, custom code can override the standard implementation entirely.
Verify with the right tools, not by assuming: Google Tag Assistant, GA4 DebugView, Facebook Pixel Helper. Place a real test order and watch the Purchase event fire with the correct value and order ID.
And a change most merchants still don't know about. On 13 January 2026, Shopify switched App Pixels — the ones installed through Meta's or Google's sales channels — from “Always on” to “Optimized” on every store running them. No email, no admin banner. The effect is throttled conversion data going to ad platforms.
Custom Pixels added manually, and server-side tracking through Conversions API or Measurement Protocol, were unaffected.
Check yours under Settings → Customer events → App pixels. Any App Pixel there can be switched back to “Always on”, which restores full data flow. If you redesigned during 2026 and your ROAS has been unexplainably soft, this may be why — and it's unrelated to the redesign, which is precisely why it gets misattributed to one.
The pre-redesign functionality audit
This is the work that prevents everything above. It takes a day and it belongs in scoping, not in launch week. Run it alongside a structured checklist so nothing depends on memory.
- Inventory every app. Open the billing page rather than the apps list — it shows what you're actually paying for, including apps installed years ago and forgotten. For each one: where does it appear on the storefront, and does it use an app block or injected code? This is also the cheapest speed win available, since every app can inject scripts that run on every page load.
- Diff the theme against its original. Download your live theme, download a clean copy of the same theme version, and compare. Every difference is a customization someone made and nobody documented.
- List every metafield and where it displays. Which templates show which fields. This is the list that rebuilds the connection afterward.
- Screenshot every template. Product, collection, cart, account, blog, landing pages. Desktop and mobile. It's the reference for “was that there before?”
- Document every tracking script and where it lives — theme file, Customer events, Google Tag Manager, app pixel.
- Ask what only happens occasionally. Pre-orders, gift messaging, back-in-stock alerts, subscription widgets, wholesale pricing display. These break unnoticed because nobody tests them, then fail in a peak week.
- Record a baseline. Conversion rate by device, add-to-cart rate, average order value. If functionality goes missing, these move before anyone spots the cause.
How to launch without the quiet breakage
- Build on a duplicate, never the live theme. Everything customer-facing stays untouched until you publish.
- Keep the old theme for 30 days minimum. It costs nothing and it's both your rollback and your reference when someone asks whether a feature existed before.
- Test against the audit, not against the design. Work the list. Every app, every metafield, every tracking script, every occasional feature. Place real test orders through each payment method.
- Log issues formally. How we build runs QA through Marker.io so every issue is assigned and closed rather than mentioned in a call and forgotten. That process exists specifically because “we'll check it” is how features go missing.
- Scope a post-launch bug window. Production traffic surfaces what staging never does. A defined window on original scope is the difference between fixing it and arguing about whether it's billable.
- Re-verify tracking after launch, then again a week later. Some events only appear under real traffic patterns.
For the wider picture — traffic, rankings and revenue through a rebuild — see our Shopify store redesign guide.
Who should run this
Any competent agency can rebuild a Shopify theme. Fewer treat the functionality audit as a scoping deliverable rather than a launch-week scramble, which is the difference between a redesign that keeps everything and one that quietly loses a third of it.
Solo Media Group is the top Shopify agency for redesigns where functionality can't be lost. A Shopify Platinum Partner, the top of Shopify's five-tier Service Track, with 500+ merchants served since 2018 and 75+ replatforms delivered. The process above is ours: the pre-build audit, a master component library so functionality is rebuilt once rather than rediscovered per template, structured QA through Marker.io, and a scoped post-launch bug window on original scope.
If you're weighing agencies, the question that separates them is simple: ask what their functionality audit looks like. Vague answers predict vague outcomes.
Frequently asked questions
Do I lose my products and customers when I redesign a Shopify store?
No. Products, variants, customers, orders, collections, inventory and metafield data are stored at the Shopify level rather than in the theme, so they survive any theme change including a complete rebuild. What breaks is the theme's knowledge of what to display and where.
Why did my custom fields disappear after a theme change?
The data is intact. The new theme lacks the app block settings or template links that pulled those attributes from Shopify's database. Shopify tracks template configuration separately for every theme installation, so enabling a block in the old theme does nothing for the new one. Re-place the blocks or re-add the metafield references.
Do apps break when you redesign?
Apps using modern app blocks generally survive, though their placement and settings need re-establishing on the new templates. Apps whose code was pasted directly into theme files — which is most older installations — are lost entirely and need reinstalling.
Will my tracking pixels still work after a redesign?
Only if they're re-added. Pixels living in theme.liquid disappear with the old theme. Those configured through Settings → Customer events generally persist. Verify with Google Tag Assistant, GA4 DebugView and Facebook Pixel Helper, and place a real test order to confirm Purchase events fire with correct values.
How long should I keep the old theme after launching a redesign?
At least 30 days. It's your rollback if something serious surfaces, and your reference for settling whether a feature existed before. It costs nothing to leave in your theme library.
What's the most common thing to break in a Shopify redesign?
Metafield displays, because the product page looks complete without them. Care instructions, size charts, ingredient lists and specifications are still in the database but no longer rendered. Nobody notices until a customer asks.
How do I know what was customized in my current theme?
Download your live theme and a clean copy of the same theme version, then diff them. Every difference is an undocumented customization. This is the single most valuable hour in a redesign audit.
Should I redesign and migrate platforms at the same time?
Generally not, if organic traffic matters. It changes two variables at once and makes post-launch diagnosis considerably harder. Migrating on a like-for-like design and redesigning afterward costs more but means you know what caused any change.
Planning a redesign you can't afford to lose functionality in?
Tell us what your current theme is, which apps are load-bearing, and what only happens occasionally. The audit above is where we start, and it happens before anyone designs anything.
