The Challenge
The client operated a specialized ecommerce business on a custom-built platform that had been in place for more than 15 years. While the underlying commerce system continued to process orders, the customer-facing storefront had become increasingly difficult to compete with.
Its aging architecture limited opportunities to improve the shopping experience, search functionality, and search-engine visibility. The underlying server environment also needed modernization.
Replacing the entire platform, however, would have introduced unnecessary risk and expense. The existing administrative system was familiar to the client’s staff and continued to support their product catalog, order fulfillment, and day-to-day operations.
The challenge was to modernize the customer experience without disrupting a backend that was still doing its job.
The Solution: A Headless Architecture
Rather than replace the legacy commerce platform, I designed and built a new headless storefront using Next.js and React, supported by a custom PHP Backend-for-Frontend (BFF) API.
The new storefront operates independently of the legacy application while continuing to use its existing database, commerce logic, and order-processing infrastructure.
The architecture separates the system into three distinct layers:
- Next.js storefront: Handles the customer-facing experience, page rendering, routing, product presentation, cart, and checkout interface.
- PHP BFF API: Acts as the integration layer between the new frontend and the existing commerce system. It retrieves and transforms legacy data into structured API responses, manages cart sessions, and coordinates checkout.
- Legacy commerce backend: Continues to manage the product catalog, database, pricing, coupons, payment processing logic, and order records. The existing administrative application remains unchanged.
This approach allowed the new frontend to evolve independently without requiring changes to the legacy database schema or the administrative tools used by the client.
Building the BFF Integration Layer
The BFF was central to the project. Rather than expose the legacy database structure directly to the React application, I created a set of purpose-built API endpoints and data transfer objects.
The new frontend receives consistent, predictable data structures for products, categories, navigation, search results, carts, and checkout operations. The BFF handles the translation between those structures and the existing backend’s data model.
This creates a useful separation of concerns: the frontend doesn’t need to understand the legacy database, and future changes to the commerce engine can be handled within the integration layer rather than throughout the user interface.
The same approach also provides a foundation for additional functionality, including more sophisticated parts-finder tools and product compatibility data.
Modern Search and Product Discovery
The legacy platform relied on conventional database queries for product search. That approach was increasingly limiting for a catalog containing thousands of specialized parts, where customers frequently search by part number, manufacturer, product category, or equipment compatibility.
I introduced Meilisearch as a dedicated search engine, with a synchronization process that indexes active products from the existing MySQL database.
Search requests now pass through the BFF, which communicates with Meilisearch and returns structured results to the storefront. This provides a foundation for more capable search, including typo tolerance, part-number matching, and faceted filtering by attributes such as brand and category.
Importantly, search was modernized without replacing the product database or requiring the client to manage a new catalog administration system.
Preserving the Commerce Workflow
A new storefront is only useful if it can reliably complete transactions and hand orders off to the systems responsible for fulfillment.
The new application includes a session-based shopping cart, coupon handling, and a guest checkout flow integrated with the existing Braintree payment infrastructure.
The BFF reuses the legacy checkout and payment logic, then creates orders using the same database structures and status conventions as the original storefront. As a result, orders placed through the new application retain the structure expected by the existing administrative system.
Staff can continue processing orders through the familiar administration panel without needing to learn a replacement system or change their fulfillment procedures.
I also implemented guest order-status lookup, allowing customers to retrieve order information using their order number and billing ZIP code without introducing a new customer-account system.
SEO Transition and Ongoing Optimization
The storefront replacement was also an opportunity to address longstanding SEO issues.
The new application introduced clean, descriptive product URLs while preserving support for the legacy URLs that search engines had indexed over the years. Canonical tags and an updated XML sitemap help search engines recognize the preferred URL structure without abruptly abandoning existing links.
Following launch, I am continuing the SEO work by reviewing and cleaning up the client’s Google Search Console profile, addressing accumulated indexing issues, and monitoring how search engines process the new storefront and URL structure.
Because the site has only recently launched, it is too early to draw conclusions about ranking improvements. The technical foundation is now in place, and the focus has shifted to ensuring that search engines properly discover, index, and evaluate the new site.
A Controlled Production Migration
The new storefront was developed as an isolated application alongside the existing production system.
This allowed development, integration, and testing to take place without modifying the live storefront or interfering with ongoing order processing. The new application was evaluated independently before the final domain transition.
The new architecture also provides a straightforward rollback path, with the original storefront retained as a fallback during the transition.
This approach reduced the risk associated with replacing a long-established ecommerce platform while allowing the client to move forward without a disruptive backend migration.
Results and Business Value
The project established a modern frontend architecture while preserving the client’s existing commerce and administrative infrastructure.
Key outcomes include:
- Modern customer experience: Replaced the aging storefront architecture with a modern Next.js and React application.
- Preserved operations: Retained the existing product database, order structures, payment logic, and administrative system.
- Improved search foundation: Introduced Meilisearch for more capable product discovery and faceted search.
- SEO modernization: Established clean, canonical product URLs, preserved legacy URL compatibility, and began addressing accumulated indexing issues.
- Reduced replacement risk: Avoided a full commerce-platform migration and the operational disruption that would have accompanied it.
- Future flexibility: Created a BFF layer that allows new frontend features and integrations to be developed independently of the legacy backend.
Conclusion
Modernizing a legacy ecommerce platform doesn’t always require replacing everything underneath it.
In this project, the most effective solution was to preserve the parts of the system that continued to serve the business while replacing the component that had become its biggest limitation: the customer-facing storefront.
The resulting architecture provides a modern foundation for ecommerce development while allowing the client to retain familiar administrative tools and established fulfillment processes.