The 31st setting is what tips it. A merchandiser opens a ticket on a Tuesday morning: the section editor freezes for three seconds whenever she edits hero copy on the home page. The schema looks fine to a developer, the JSON is well-named, the conditional display rules are correct on paper. But on the merchandiser side the editor is past a soft ceiling, and adding a 32nd setting is going to make it worse.
That is the moment the fork shows up. Three options, none of them free. This is the decision log for one of the builds where I had to make the call.
The fork: section settings have outgrown the schema
The pattern is consistent across every Shopify theme I have rebuilt for a DTC brand past the $2M revenue line. A flagship section starts at six or eight settings, the merchandising team grows, and each new campaign adds a setting or two: an eyebrow color override, an alternate CTA label, a visibility toggle for a promo badge. By month nine, the section schema is at 28 settings and the team is talking about adding three more.
The hard limits live a long way out. Shopify's documentation cites a per-section schema cap somewhere north of 25 settings on legacy themes and a softer ceiling on Online Store 2.0, plus a global theme settings cap around 250 entries. The sections-vs-blocks decision rubric I wrote about in the schema-shape question between sections and blocks handles part of this, but it does not address the section that is already over-settled and shipping to merchandisers daily.
The pain shows up in three predictable places once you are past about thirty settings on a single section. Editor lags on input changes, especially on the merchandiser's laptop where memory pressure is higher than on the developer machine. visible_if conditional rules start contradicting each other, so a setting that should hide for a layout variant stays visible. And the naming becomes overloaded: there are three settings with color in the name and the merchandiser cannot tell which one controls the eyebrow.
None of those three is a Shopify bug. They are signals that the schema is doing too much. The decision is what to do about it.
Option A: flatten the existing schema
Flatten means staying inside the section schema and reducing what is actually exposed. Group related settings under a header schema entry to give the editor visual breaks. Collapse two redundant boolean toggles into a single select. Promote three near-identical color settings to a color_scheme reference. Add visible_if rules so the conditional fields only appear when their parent layout is selected.
What flattening gives you is real but limited. Editor lag eases because fewer fields render at any one time, even though the schema itself is still long. Merchandiser sees four or five visible controls per layout variant instead of the full thirty. Naming gets less overloaded because the redundant fields get merged. None of this requires a metafield migration or a theme refactor of any depth.
What it costs is a six to twelve month runway, not a fix. The schema is still long. The next campaign that needs three new fields drops you back into the same place. Flattening is the right move when the schema bloat came from cosmetic settings (colors, label text, toggle states) that are genuinely section-owned, and when the team's appetite for a deeper migration is low. It is not the right move when the bloat came from data that should have lived on the product or collection in the first place.
Option B: migrate cosmetic settings to metaobjects (or metafields)
The deeper move is to ask which settings belong on the section at all. A surprising fraction of section settings on mid-market DTC themes are really product or collection data wearing a section's clothes. Hero copy that varies per landing page is template data. A testimonial set that appears on home, PDP, and a campaign page is shared content. Brand color tokens are theme-wide. Each of these has a better home than the section schema.
Metaobjects, which Shopify shipped GA in December 2022 and which became viable for content modeling around the second half of 2024, are the natural target for shared content. A testimonial metaobject definition with quote, attribution, avatar, and rating fields can be referenced from any section. The section schema collapses to a testimonials_collection_handle setting that points at a metaobject collection, and the section iterates and renders.
What this gives you is a section schema that drops from thirty-plus settings to eight or twelve layout settings. The data lives on the resource, not on the page. Editor lag goes away because the schema is short. The merchandiser stops scrolling. New campaigns add metaobject entries, not section settings.
What it costs is a real migration. The fields that exist on hundreds of templates have to be read, written into metaobject entries, and the Liquid has to learn to fall back through the chain (metaobject value, then section setting, then hardcoded default) during the dual-write window. The pattern I use for that fallback chain is the same one I described in the metafield-driven section pattern, and the migration tooling looks identical to a metafield migration. I usually budget three weeks for this on a mid-sized DTC theme, plus a fourth week of monitoring before flipping the dual-write off.
Option C: split the section into two or three smaller sections
Sometimes the schema is bloated because the section is conceptually doing two jobs. A "hero" section that supports both a campaign hero and a homepage seasonal hero will have settings that belong to one but not the other. The conditional rules pile up. The merchandiser has to remember which fields apply to which mode.
Splitting means extracting one of those modes into a sibling section. The campaign hero becomes its own file with its own schema, focused on campaign-specific fields. The seasonal hero shrinks because its variant logic moved out. Two sections of fifteen settings each are easier to reason about than one section of thirty.
What this gives you is conceptual clarity per section and a schema budget per section that is easier to keep under the soft ceiling. Each section file reads end to end without a visible_if thicket. Naming gets to be specific to one mode.
What it costs is friction in the theme editor at the merchandiser level. They now place two sections instead of one. They have to remember which one to use for which campaign. Reordering on a template gets noisier. Splitting is the right move when the original section is genuinely two things, and the wrong move when it is one thing with one or two variants. The split has to make the merchandiser's job clearer, not just the developer's.
What we chose at the four-layout build
The build I keep referencing was a Q4 2025 DTC theme rebuild that needed four layout variants for the same content module: columns, scroll, collapsible, slider. The first proposal from the agency that owned the previous theme was to add forty blocks to the existing section schema. I refused that path for the reasons covered in the three-layer Shopify theme pattern past 2M, and chose Option B with a metafield contract on the product.
The migration ran over three weeks. Week one was the schema audit: I exported every existing section's schema and every set value across the catalog, classified each setting as section-owned (layout, spacing) or resource-owned (copy, media, accent color), and wrote a metafield definition for each resource-owned field. Week two was the dual-write window: Liquid read from the metafield first, fell back to the section setting, fell back to a hardcoded default. Merchandising team kept editing as usual, and a script that ran nightly synced new section-setting changes into the metafields. Week three was the cutover: section settings for the migrated fields were removed from the schema, the dual-write fallback became metafield-only, and the section file dropped from 380 lines of schema to 110.
“The merchandiser stopped scrolling. The section schema went from a place she avoided to a place she edits without thinking about it.”
The thing I caught in week three that I almost shipped was a Liquid template that referenced one of the removed section settings on a single archived landing page. The theme editor had not flagged it because the page was unpublished. The way I caught it was a theme preview snapshot diff: render every published and unpublished template against the new schema, compare against a baseline, and flag any template that lost a previously visible field. I would not run a schema migration without that diff again.
What I would revisit with what evidence
Two things I would change about how I ran this.
First, I did not benchmark editor performance pre-migration. I had merchandiser reports of lag at thirty-plus settings, but no numbers. Today I would measure input-to-render lag on the merchandiser's actual hardware before deciding between Option A and Option B, because the choice depends on whether the lag is bad enough to justify a three-week migration. The skill I now use for this kind of pre-migration audit is in the Claude Code skills I use for day-to-day Shopify work, specifically the section auditor that flags schema bloat with measured editor latency.
Second, the metaobject pattern I used for shared testimonials in this build was right for that brand. It would not be right for a brand below $2M revenue with a single team member managing content. Metaobjects need a shape decision up front, and that shape is harder to revise than a section setting. I would push a smaller brand toward Option A and revisit Option B only when content reuse across templates was provable, not theoretical.
How merchandisers feel before and after
The clearest signal that the migration worked was in the support tickets, not the codebase. Pre-migration the merchandising team filed two or three theme-editor performance complaints a month, and the editor session for the home page section took twelve to fifteen minutes when an A/B campaign rolled out because they had to scroll through thirty controls and remember which ones to change. Post-migration the section showed eight controls, the merchandiser knew at a glance which were layout and which were content, and the average editor session was closer to four minutes.
That is the test I now use to decide whether a section schema is past its ceiling. It is not the count of settings, although the count is a reasonable proxy. It is whether the merchandiser has internalized the schema, or whether she has to think about it every time. Once she has to think, the schema is too long for her actual job, and the question is which of the three options to take.
Frequently asked questions
What is Shopify's actual hard limit on section settings?
The documented per-section schema cap is around 25 settings on legacy themes and softer on Online Store 2.0. The global theme settings cap is roughly 250 entries. In practice the soft ceiling that matters to merchandisers is around 25 to 30 settings per section, well below either documented hard limit, because that is where editor lag and visual scanning break down.
Should I migrate everything to metaobjects?
No. Layout settings (column count, alignment, spacing) belong on the section. Content that varies per resource (hero copy on a product, testimonial text, accent color tied to a collection) belongs on the resource. The migration is for the second category, not the first.
How long does a section settings to metaobject migration take?
On a mid-sized DTC theme, three weeks is the budget I plan: one week of audit and metaobject definition, one week of dual-write Liquid fallback, one week of cutover and template diff verification. Smaller themes can run in one week. Larger catalogs with thousands of products need a fourth week of bulk operation runs on the Admin API.
What if my brand is below $2M revenue?
Start with Option A. Flatten the schema, group settings under headers, add visible_if rules. The metaobject migration has a real cost in setup and ongoing schema discipline that pays back at scale. Below $2M you usually do not have enough shared content to justify it, and the team is small enough that the editor lag is a smaller problem than the migration's complexity.
How do I A/B test which option will work?
Run a feature-branch theme on a single template. Implement Option A on the most-used section in that branch, measure editor latency on the merchandiser's actual hardware before and after, and ask the merchandiser to do a normal editing pass. If the latency drop is under 30 percent or the merchandiser reports no real change, the schema bloat is not cosmetic and Option B is the move.
Where does this fit in the broader Shopify stack?
Section settings sit at the layout layer of the theme architecture, with metafields and metaobjects sitting at the data layer below. The decision in this article is about which layer a given setting actually belongs to. The full layering is in the theme architecture for DTC brands past 2M, and the apps and services that sit alongside it are covered in the Shopify app stack decisions that age well.
Sources and specifics
- The 30-setting soft ceiling figure is from one Q4 2025 DTC theme rebuild and corroborated across two earlier mid-market DTC builds in 2024-2025. It is not a Shopify-published limit.
- Shopify's documented per-section schema cap is roughly 25 settings on legacy themes; Online Store 2.0 raised the practical ceiling but the merchandiser-side editor lag emerges before either documented number.
- Metaobjects shipped GA on December 15, 2022. The Theme Editor's native support for metaobject references stabilized in 2024.
- The three-week migration timeline assumes a single developer running schema audit, dual-write Liquid, and cutover sequentially. Larger catalogs require an additional week for Admin API bulk operations.
- The template snapshot diff approach catches references on unpublished or archived templates that the Theme Editor's drift warnings do not surface.