How Race Technologies Migrated from Drupal to Shopify Plus with Fitment-First Year/Make/Model Search
TL;DR
What We Shipped
Fyresite moved Brembo’s official partner for the Americas, Asia-Pacific and the Middle East off a content-only Drupal site. The new Shopify Plus storefront asks one question first: what do you drive. To make that work, Fyresite built a Year/Make/Model fitment architecture on Shopify metaobjects and a single Algolia index behind every fitment surface. On top of that sits a configurator for multi-thousand-dollar Brembo brake systems. Finally, one custom theme serves both consumers and the dealer network through native Shopify B2B.
Took a brand that had never sold online to a live Shopify Plus storefront.
The previous Drupal site was content-only. There was no cart, no checkout, no accounts and no pricing.
Rebuilt vehicle fitment as structured data on Shopify metaobjects.
Vehicle Type, Year, Make, Model and Submodel now live at both the product and variant level, rather than as tags or a flat compatibility list.
Solved the "same car, different answer" problem.
A dedicated fitment-note layer keys each warning to a specific vehicle-and-SKU pairing. As a result, the edge cases that used to live in a sales rep's head now render on the page.
Standardized every fitment surface on Algolia.
Five separate vehicle selectors across the site read from one index, which covers roughly 75 technical specification fields.
Built a two-layer brake system configurator tied to NetSuite part numbers.
Storefront-facing builders sit on top of the real ERP kit SKUs. That includes a custom caliper paint path for a product with no SKU in NetSuite.
Served consumers and dealers from one custom theme.
A single Shopify Plus storefront carries a DTC experience and a native Shopify B2B experience, so there are no two codebases to maintain.
Brembo's Official Partner for the Americas Brings a Fitment-First Catalog Online With Fyresite
Industry
- Automotive
Services
- B2B
- Complex Customizations
- Custom Product Selector
- Drupal to Shopify Migration
- Netsuite Integration
- Shopify Plus
- Y/M/M Vehicle Fitment
The Problem
Race Technologies has been the official Brembo partner for the Americas, Asia-Pacific and the Middle East since 1998. It sells braking systems to dealers, builders and race teams across automotive and powersports. Its Drupal site, however, was a catalog to look at rather than a store to buy from. There was no cart, no checkout and no pricing. Every order and every fitment question moved through a person. Meanwhile, product data lived in NetSuite, the eTools PIM, Drupal and spreadsheets, and nobody had ever forced it into a shape a storefront could use.
Fitment is where that gets expensive. A Brembo big brake kit costs several thousand dollars, and it either bolts to the car or it does not. A wrong answer means a freight return and a customer who pulled their wheels off for nothing. On top of that, the data carried decades of edge cases. Some systems require modifying a steering knuckle on older Porsches. Some kits fit only cars ordered with a specific factory brake package. Chassis codes appear in some records and not others. A flat compatibility list cannot express any of that, and neither can a tag-based filter. Underneath it all, automotive and powersports share a vocabulary of calipers, discs and pads. The old architecture had no reliable way to keep the two catalogs apart.
The Solution
Fyresite handled the Drupal to Shopify Plus migration and built a fitment-first storefront. In practice, that means vehicle compatibility is the primary navigation layer, not a filter bolted on after the fact.
Vehicle records live in Shopify metaobjects, and Fyresite assigns them at both the product and variant level. So a kit can fit a vehicle while a particular disc option within it does not. A second metaobject definition stores fitment notes against specific vehicle-and-SKU combinations. Because of that, a warning fires only for the exact pairing it applies to, and it renders in plain language on the page.
Every fitment query runs through a single Algolia index. That index carries the vehicle data alongside roughly 75 technical specification fields, from caliper piston count to disc vane design to pad compound. Five entry points read from it. Those are the header selector, the homepage selector, the product page fitment panel, the brake system family finders and the dealer quick order form. They share one component set, so the answer cannot drift between them. Fyresite also solved the automotive and powersports split at the taxonomy level. As a result, the two catalogs behave as separate stores from the customer’s point of view while sharing one platform, one theme and one fulfillment operation.
On top of the fitment layer sits a configurator for the brake systems themselves. A Brembo GT system is a set of choices about disc size, construction, caliper color and pad compound. Each combination resolves to a real kit part number in NetSuite. Fyresite built a two-layer product model, so the storefront presents a clean builder while the transaction lands on the ERP’s actual SKU. The same store then serves two audiences through native Shopify B2B. Consumers get the vehicle selector, the configurator and the fitment warnings. Dealers get a quick order form, company accounts with location-level pricing, and checkout rules that run in Shopify Functions. In short: one codebase, one catalog and one set of fitment data to keep correct.
Fyresite Parts Intelligence™
What Parts Intelligence looked like on Race Technologies
A first-ever storefront, a fitment architecture built from clean source data, and a configurator that speaks ERP, all sequenced so the same vehicle gets the same answer everywhere it is asked.
Modeled fitment as structured data, not tags
Vehicle records became Shopify metaobjects with Year, Make, Model and Submodel. Fyresite can assign them at product or variant level, with defined precedence when both exist. Chassis codes stayed inside the model and submodel strings, so the taxonomy stayed shippable.
Made the edge cases first-class
A separate fitment-note metaobject stores each note against a vehicle-and-SKU pair. So a warning can apply to one car and not the next, even when both buy the same part. Notes render as explicit “ONLY FITS” and “WILL NOT FIT” statements.
Standardized every fitment surface on one engine
All fitment inputs and results run on Algolia, and Shopify’s native search plays no part in fitment. Five selectors share one index and one component set. As a result, two selectors can never disagree about the same vehicle.
Rebuilt the fitment index from source
The first import inherited drift from the legacy export, because the old system derived replacement-part fitment from the parent kit. Instead of patching it, Fyresite wiped the automotive data and reimported it from a clean source file. The team also renormalized the vehicle taxonomy to the industry standard.
Built the configurator against real ERP part numbers
Storefront builder products carry no SKU of their own. Instead, every configuration maps to a backing product that exists in NetSuite. So nothing is on sale that operations cannot pick, pack and account for.
Carried the old URLs, and the vehicle context, forward
Fyresite mapped legacy kit pages by part number. Legacy vehicle pages redirect with the vehicle carried as query parameters, so a customer arriving from an old bookmark lands with the selector already filled in.
Custom Features
What we engineered
Metaobject Fitment Architecture
Vehicle compatibility modeled as Shopify metaobjects at both product and variant level, with defined override behavior. It replaces the tag-based and spreadsheet-based approaches the catalog had accumulated.
Vehicle-Specific Fitment Notes
A second metaobject definition that stores notes against unique vehicle-and-SKU combinations. So a caveat that applies to one car does not leak onto every other vehicle that shares the part.
Algolia Fitment Index
A purpose-built index covering vehicle year ranges, makes, models, submodels, universal-fit flags and category, plus roughly 75 technical specification fields. It powers every fitment surface on the storefront.
Two-Layer Brake System Configurator
Storefront-facing builder products sit on top of backing kit SKUs. Metaobject-backed metafields drive the options, and secondary selections persist as line item properties rather than separate cart lines.
Dual-Audience Shopify B2B Storefront
One custom Shopify OS 2.0 theme serving a consumer DTC experience and a native Shopify B2B experience. Catalog visibility, pricing, payment rules and ordering workflow diverge by audience on a shared codebase.
Live Shipping Rate Middleware
Custom carrier service middleware that returns live rates for a catalog where box dimensions vary from a brake pad set to a full multi-box system. It uses a dimension waterfall and automatic residential versus commercial classification.
Metaobject Fitment Architecture and Vehicle-Specific Notes
Brembo’s compatibility data does not reduce to a list. The same part fits one car outright, another only with a particular factory brake package, and a third only after a suspension modification. The client described the failure mode during build: “If you search a 1995 Porsche 911 Carrera you get the front system, but it says the rear system doesn’t fit. If you search a 1995 Porsche 911 Carrera [993] it says the rear system fits, but the front system doesn’t. It’s the same car.”
Fyresite modeled vehicle records as Shopify metaobjects rather than tags. Fitment groups attach at the product level and, where an option diverges, at the variant level. The harder piece was the note. Because a single SKU can appear against hundreds of vehicles, a caveat stored on the product would surface for every one of them. Instead, a separate metaobject definition stores the vehicle and SKU combination independently, so a note binds to that pairing alone. Select a 1995 Porsche and the steering knuckle warning appears. Select the car next to it in the list and it does not.
As a result, conditional fitment knowledge that used to depend on a phone call now renders on the page at the moment of decision.
Two-Layer Brake System Configurator
Brembo sells a GT system as a kit, and the kit part number in NetSuite changes with disc size, disc construction, caliper color and pad compound. The legacy site grouped multiple kit part numbers under a single parent system, so customers could shop the system rather than the SKU. Shopify needed to replicate that grouping without losing the SKU underneath, because the SKU is what inventory, fulfillment and accounting run on.
Fyresite built a two-layer product model. The storefront presents builder products that carry no SKU and exist purely to host the configuration experience. Behind them sit the backing products, the real kit SKUs, hidden from the consumer storefront. Metaobject-backed metafields drive the options, so adding a caliper color or pad compound is a data change, not a code change. Pad choices attach to the cart line as a line item property rather than a second line. Custom caliper paint has no single SKU in the ERP. So the configurator adds the base caliper variant plus a paint line item matched to the system’s piston count and finish.
The result is a configurator that behaves like a product experience on the front end and like ERP data on the back end. Nothing needs manual reconciliation between the two.
One Shopify Plus Store for Consumers and Dealers
Race Technologies sells to two audiences that want opposite things from a website. A consumer buying a big brake kit needs education, confidence and guardrails. The site has to confirm the vehicle, surface the warnings, and make the configuration explicit before anything reaches the cart. A dealer, on the other hand, knows the part numbers and orders across multiple vehicles in one session. They need negotiated pricing, and they measure the site by how fast they can get out of it. The original plan called for two Shopify stores sharing a theme.
Native Shopify B2B matured into the better answer. Running both audiences from one store meant no fitment data syncing between stores and one source of truth for every vehicle record.
Consumers get the vehicle selector and the configurator. Dealers get a quick order form that searches the same Algolia index but runs at dealer speed. Paste a part number, lookup fires on blur, and quantities and PO number sit on the same row. Dealer-only products publish to a separate sales channel, so they never appear in consumer search or Google. Companies carry locations, locations carry catalogs, and parent accounts support sub-accounts with their own pricing and permissions. Checkout rules run in Shopify Functions, so they apply to storefront orders, quick orders and rep-built draft orders alike.
The result is two different buying experiences with one codebase, one catalog and one set of fitment data to keep correct.
Vehicle-Aware SEO Migration
A content-only site that Google has indexed for years still carries real organic value. Race Technologies’ legacy URL structure included both product-family pages and a large set of vehicle-specific pages. A standard redirect map would have preserved the link equity but thrown away the intent.
Fyresite mapped legacy kit pages by part number where a live SKU match existed. Where a part is discontinued or never carried over, the page routes to its product line hub instead. Ambiguous cases, where an old page could plausibly resolve to more than one current product, went to the client rather than to a guess. Vehicle pages got the more interesting treatment. Rather than dropping a customer onto a generic collection, the redirects carry the vehicle as query parameters. So the landing page opens with the selector already populated for the car that customer was searching for.
As a result, legacy traffic lands on a page that already knows what the visitor was looking for. The redirect map ships as documented client-owned data rather than a black box.
Integration Solutions
Shopify Plus
Algolia
NetSuite
Pacejet
Shopify Functions
Got a tech problem?
Let's solve it together
