NEXSUM_LABS
  1. Home
  2. Work
  3. A manufacturer tamed a 30,000-SKU Adobe Commerce catalog its own team feared
Book a call

[ Case study ]

Industrial manufacturingAdobe CommerceElasticsearch (OpenSearch)ERP syncCustom modules

A manufacturer tamed a 30,000-SKU Adobe Commerce catalog its own team feared

The catalog had accreted for eight years: duplicated attribute sets, category rules that contradicted each other, and reindex jobs that took the site's search down during business hours. Merchandisers worked around the system instead of with it.

CLIENT a mid-market industrial manufacturer — FOCUS Audit the attribute and category debt first

Adobe Commerce DevelopmentEcommerceAdobe Commerce DevelopmentIndustrial manufacturingRepresentative example
Client
a mid-market industrial manufacturer
Industry
Industrial manufacturing
Engagement
14 weeks — systems pod — 2 engineers
Service
Ecommerce / Adobe Commerce Development
Headline outcome
Full catalog reindex duration, with business-hour search interruptions eliminated: 38 min → 4 min, read from Indexer logs over a 30-day window

Representative examplesEvery case study in this library is an illustrative composite of the kind of engagement we deliver — written to show our method and standards, not to name clients.

Where they started

A mid-market manufacturer of industrial components, selling through distributors and directly to large buyers, with an Adobe Commerce catalog that had accreted for eight years across product managers, agencies, and one memorable rebrand. Thirty thousand SKUs carry technical attributes — tolerances, materials, compatibility codes — that buyers filter by. Category pages drive roughly a third of revenue through search traffic. The merchandising team of three knew the workarounds better than the admin: which reindexes to avoid before lunch, which category rules to never touch.

What it was costing

The catalog had accreted for eight years: duplicated attribute sets, category rules that contradicted each other, and reindex jobs that took the site's search down during business hours. Merchandisers worked around the system instead of with it.

What they could see

  • Full catalog reindexes ran during business hours and took site search down with them — merchandisers timed saves around the lunchtime outage.
  • Attribute sets had duplicated to the point where adding a product required choosing between three near-identical sets, each slightly wrong.
  • Dynamic category rules contradicted each other, so the same SKU sat in up to four categories with no one able to say which rule won.
  • Merchandisers kept private spreadsheets of what they refused to touch, because an innocent-looking edit had once reshuffled half the catalog.

The constraints we worked inside

  • The ERP fed the catalog nightly; the cleanup could not break that sync mid-window.
  • SEO traffic on category pages was a third of revenue — category URLs were untouchable.
  • Reindex windows had to fit business hours because there was no staging parity for search.

What had been tried before

An agency two years prior had audited the catalog and delivered a sixty-page report naming the attribute debt and the contradictory rules.
The report named problems but sequenced nothing; with URLs carrying a third of revenue, nobody dared act on it without a plan that preserved category addresses.
The ERP team tightened their nightly export, assuming cleaner input would clean the catalog over time.
New data arrived clean and landed in the same duplicated attribute sets and rule stacks, so the catalog got tidier inputs into the same mess.

What we proposed

We proposed a debt-first cleanup with two guardrails fixed from day one: category URLs would never change, and the ERP's nightly feed would never break mid-window. Every attribute set and dynamic category rule would be inventoried and mapped, duplicates merged under a written naming standard, and rules consolidated before anything was deleted. Indexing would move to scheduled partial-update windows outside business hours, ending the lunchtime search outages. Every merchandising change would run behind a URL-equivalence check, so tidiness could never quietly cost a ranking.

Just as important is what we ruled out, and why:

  • Rebuilding the catalog in a fresh Adobe Commerce instanceEight years of order history, ERP mappings, and the nightly feed's field contracts pointed at the live instance; a rebuild traded one enormous risk for several.
  • Switching search to a third-party SaaS engine ahead of the cleanupIt added a new system to learn during the riskiest phase, and the reindex pain was full-index behavior that scheduled partial updates solved without a new vendor.

How the work ran

01Audit the attribute and category debt first

Every attribute set and dynamic category rule was inventoried and mapped, with duplicates merged under a written naming standard before anything was deleted.

02Move indexing out of business hours

Indexers moved to a scheduled partial-update routine with cron-managed windows, ending the lunchtime search outages.

03Prove category URLs stay put

Every merchandising change ran behind a URL-equivalence check so rankings were never traded for tidiness.

Delivered by the systems pod — 2 engineers over 14 weeks, with working increments reviewed with the client every week.

The stack, and the reasoning

Adobe Commerce
The platform's dynamic-category and attribute machinery is what the merchandising team knows; replacing it would trade a fixable mess for a migration during peak-revenue dependence.
Elasticsearch (OpenSearch)
Reindex pain came from full-index runs on a 30,000-SKU catalog; partial updates against the existing cluster removed the outage without touching search relevance.
ERP sync
The nightly feed is the catalog's source of truth, so the cleanup mapped onto its field contracts rather than asking the ERP team to change theirs.
Custom modules
URL-equivalence checking and naming-standard enforcement had to run inside the admin where merchandisers work — no off-the-shelf tool watches category URLs on every save.

What went wrong

Obstacle

There was no staging environment with search parity, so indexer changes could only be validated against production — exactly the system the reindexes had been taking down.

Handled: We built rehearsal protection instead: indexer changes ran in low-traffic windows behind a search proxy that could fall back to the last good index within seconds.

Obstacle

Merging duplicate attribute sets surfaced products whose history pointed at records the naming standard wanted to retire, and deleting them risked the ERP feed rejecting the rows.

Handled: Retired sets became mapped aliases for the feed rather than deleted entities, and the merge proceeded in monthly slices the ERP team verified between windows.

How we worked together

Cadence
A fortnightly 45-minute review with the merchandising lead and the ERP manager, plus written slice reports after every merge window.
Client side
The merchandising lead owned the naming standard; the ERP manager guarded the feed; both had veto power over their own domain's changes.
Decisions
Conflicting category rules were decided by revenue attribution — the rule attached to the higher-earning URL survived, with the loser documented in the mapping.
They provided
ERP feed contracts, attribute-set export files, analytics access for URL revenue attribution, and merchandising time to validate merged sets.

What changed

The headline: full catalog reindex duration, with business-hour search interruptions eliminated38 min → 4 min, read from Indexer logs over a 30-day window. A second check: category-page url changes across the cleanup at 0.

Merchandisers deleted their workaround spreadsheets in month two — the admin now does what the spreadsheets did. Adding a product means choosing one attribute set from a list that makes sense, and category rules can be read top to bottom by one person in an afternoon. The lunchtime search outage passed into folklore; the team schedules edits for convenience rather than fear. The ERP manager, initially protective of the feed, now requests catalog changes through the same mapping documents we left behind.

The result was read from Indexer logs over a 30-day window against the pre-engagement baseline over the stated window, with a guardrail check on category-page url changes across the cleanup. Where platform-reported numbers and business outcomes differ, this record says which layer it is quoting.

What they own now

  • The written naming standard and the full attribute-set mapping, kept in the merchandising team's wiki.
  • Cron-managed indexer windows documented, with the low-traffic schedule and fallback procedure.
  • The URL-equivalence checker as an admin module, runnable on every merchandising change.
  • Category-rule consolidation records showing every merged rule and its surviving revenue attribution.
  • The search fallback proxy configuration and its rollback drill, rehearsed once with their team.

What we would do differently

We would have built the staging search parity first — we validated index changes against production because there was nowhere safe to rehearse.

EcommerceAdobe Commerce DevelopmentIndustrial manufacturingAdobe Commerce

Next case study

A 40-SKU home goods retailer replatformed to Shopify without a launch-week outage