Rebuilding a legacy Shopify theme on Online Store 2.0

Many established Shopify stores still run on a theme built before Online Store 2.0, heavily customized over the years by different developers. Content lives in theme settings and hard-coded snippets, every new landing page needs a developer, and the codebase has quietly accumulated jQuery plugins, unused sections and app snippets from integrations long since removed. At some point the cost of each small change exceeds what a rebuild would cost over a year. This is how we recognize that point and how we rebuild without disrupting trading.

Signs it is time to rebuild

We look for a combination of these symptoms rather than any single one:

• Product and collection templates are hard-coded, so merchandisers cannot add or reorder sections outside the homepage.
• Apps cannot use theme app extensions because the theme lacks JSON templates, so they inject code directly into theme files.
• Mobile Core Web Vitals fail at the 75th percentile, and previous speed work has not moved them.
• Simple requests, such as a new promotional block, regularly take several days of developer time.
• No one on the team fully understands the codebase, and changes regularly break unrelated pages.

When three or more apply, a rebuild usually pays for itself within a year through reduced development cost alone, before counting any conversion improvement.

A theme is not old because of its age. It is old when the team is afraid to change it.

Audit before you design

The old theme is a record of business decisions, even when the code is messy. Before design begins, we catalogue every template, section, snippet and customization, and note what each one does for the business. Hidden logic lives in surprising places: a snippet that hides certain products from wholesale customers, a cart script that enforces minimum quantities, a collection template that sorts differently for one category. Missing any of these at launch creates real operational problems.

We also pull analytics for the last year to see which templates and page types actually drive revenue. The rebuild should put its effort there. A lookbook template with a few dozen visits a month does not need the same attention as the product page.

Designing the new theme architecture

Online Store 2.0 changes the structure of a theme at the foundation. Templates become JSON files that list sections, sections can appear on any page, and blocks inside sections let merchandisers compose content. Our rebuild plan covers:

1. A section library designed around the merchandising team's recurring jobs, typically 15 to 25 sections with tight schemas.
2. A content model of metafields and metaobjects for product details that previously lived in descriptions or hard-coded snippets.
3. Alternate templates only where product types genuinely differ, rather than one template per product.
4. Theme app extension support so apps plug in through blocks and embeds rather than editing theme code.
5. A performance budget for each template, enforced in CI with Lighthouse checks against a staging theme.

We usually start from a clean foundation rather than forking a marketplace theme, but the choice depends on the brand. For some stores, a well-built marketplace theme with a handful of custom sections is the most economical option, and we will say so.

We also agree on a code freeze for the old theme once the rebuild is underway. Small changes still happen, since the business cannot stop trading for eight weeks, but each one is logged so it can be replicated in the new theme. Without that log, the new theme launches missing whatever the marketing team added in the meantime, and the first week after launch is spent reconstructing it.

Migrating content and launching safely

The rebuild happens in an unpublished theme on the live store, so products, collections and apps are real from day one. Content migration runs in parallel with development: theme settings are rebuilt as section content, hard-coded copy moves into sections or metaobjects, and product details move into metafields. For large catalogues we script this through the Admin API.

Before launch, we run a structured comparison between the old and new themes:

• Every template type rendered side by side on mobile and desktop.
• Cart and checkout flows tested with discounts, subscriptions, gift cards and international addresses.
• Structured data, meta tags and canonical URLs compared by crawler, since theme changes can affect SEO even when URLs stay the same.
• App functionality verified for every installed app.
• Analytics and pixels firing correctly, compared against the old theme's events.

Publishing a theme is instant and reversible, which makes launch less dramatic than a platform migration. We still publish early in the week, outside any promotion, and keep the previous theme unpublished for a few weeks as an immediate fallback.

What clients typically see afterwards

The results vary, but the pattern is consistent. On a recent rebuild for a DTC accessories brand, mobile Largest Contentful Paint at the 75th percentile improved from around 3.8 seconds to 2.1 seconds, and the share of theme JavaScript fell by more than 60 percent. More importantly for the team, landing pages that used to take a developer two days now take a merchandiser an afternoon. Conversion rate rose modestly in the following quarter, though we are always careful to separate the rebuild's effect from seasonal changes.

Rebuilds like this are the core of our custom Shopify themes work. If a full rebuild is more than you need right now, our Liquid section builds can bring Online Store 2.0 flexibility to the templates that matter most, and store speed tuning can recover performance in the meantime.

Thinking about a rebuild?

Send us your store URL and a short list of what frustrates your team about the current theme. Request a quote here, and we will reply within 24 hours with a fixed price and a recommendation on rebuild versus refactor.