Migrating a 40,000-part motorcycle catalog from a legacy FileMaker system to a modern e-commerce platform sounds straightforward – until you realize the old system contains decades of business logic that absolutely cannot break.
That was the core tension in our work with BMW Classic: how do you modernize without disrupting a highly specialized, globally shipping operation? Here’s what actually happened, and what we learned.
The real problem wasn’t the old technology
BMW Classic runs one of the most specialized online shops in the motorcycle world – genuine parts for everything from 1920s classics to current models, with worldwide shipping. The platform they were running had done its job for years, but it had reached its limits:
- SEO was essentially broken. The site was barely indexed, which meant customers searching for long-tail spare parts – often very specific queries – simply couldn’t find the shop.
- Content updates were slow and risky.
- The system wasn’t built to support modern marketing workflows or a smooth purchasing experience.
The hidden complexity: a significant portion of the business logic lived inside FileMaker, a legacy database system that had accumulated years of operational knowledge – product structures, compatibility rules, fulfilment logic. That’s not something you just switch off.
Keeping the business running while rebuilding it
The biggest architectural decision we made early on was this: don’t replace FileMaker in a big bang. Build around it, carefully.
This meant designing a dedicated sync layer – a structured integration that connects FileMaker with the new custom-built storefront, keeps product and catalog data in sync, and insulates the shop from the risks that come with legacy data sources. If FileMaker becomes temporarily unavailable, the shop keeps running. That stability is only possible because of the abstraction layer between them.
What this taught us is that preparation and understanding of the existing system matters more than the technology you’re migrating to. We spent significant time with the architects of the old shop before writing a single line of the new one. That investment paid off directly in the quality of the integration.
Two systems, two responsibilities: why Payload CMS was the right call
A shop like BMW Classic needs two fundamentally different things working in parallel: a structured commerce layer for parts data, pricing, compatibility, and stock – and a flexible content layer for landing pages, campaigns, and editorial storytelling.
Trying to force both into a single system creates compromises in both directions. So we separated them intentionally.
Payload CMS became the content brain. It gave the BMW Classic team the ability to publish and update marketing content, build campaign pages, and manage editorial material without needing a developer for every change. That kind of operational independence matters – especially for a team managing a catalog this size.
The custom commerce layer handled the rest: product data, checkout, pricing, and order flow. Connected through the sync layer, both systems together gave BMW Classic something they didn’t have before – speed without risk.
SEO as a product requirement, not an afterthought
One of the clearest decisions we made going in was to treat SEO as a core requirement – not a layer added after development. For a shop selling 40,000+ spare parts, organic discoverability isn’t a nice-to-have. It’s the difference between capturing long-tail search demand and missing it entirely.
In practice, this meant:
- A clean, indexable URL and navigation structure from day one
- Fast page loads via Next.js and Digital Ocean infrastructure
- Scalable metadata and content architecture that grows with the catalog
- A navigation model built around the way real customers actually search – by model family, then category, then part
The previous platform had essentially no SEO foundation. Fixing that structurally, rather than patching it, was one of the most commercially relevant things we did in this project.
What we’d do the same – and what we’d watch more closely
The design and technical architecture held up well. Building a storefront around the real buyer journey – find the right model, navigate categories confidently, validate part details, purchase without friction – is the right approach for a parts shop at this scale.
What we’d watch more closely next time: even more rigorous documentation of FileMaker data structures before migration begins. Legacy systems often contain edge cases that only surface under real conditions. The more thoroughly you map the old system upfront, the fewer surprises appear during sync testing.
The other key learning – and this applies beyond BMW Classic – is that a sync layer isn’t just a technical workaround. It’s actually a long-term architectural feature. Future migrations, additions, or replacements of any single component don’t require rebuilding the whole platform. That’s a real advantage as the business evolves.
Where things stand
The shop is live, stable, and continuing to develop. We’re ongoing with SEO improvements, UX refinements, and expanding the content layer. A project like this doesn’t end at launch – it enters a growth phase, and the foundation needs to be solid enough to support that.
If there’s one thing worth taking away from this project: the hardest part of migrating a legacy system isn’t the new technology. It’s respecting and understanding the old one well enough to build around it safely.
Working with a content-heavy platform or considering a CMS migration? Our Payload CMS services are built for exactly these kinds of projects – complex data, editorial independence, and no big-bang risk.
Related: Learn how we developed an ERP-Shopify connector and merged the e-commerce store for Rokker.
