The Situation
A German designer-furniture retailer runs ecommerce, 18 physical stores, and a B2B contract-furnishing business, and its marketing team could not update its own website. Landing pages and site content lived inside code templates and JSON files instead of a content system. Every wording change, every new page, every small update to the Careers or FAQ pages needed a developer to ship it. Content could drift out of sync between languages with no clean way to see which version was current.
The platform underneath all of this was a decade-old system the client's own team had built and maintained in-house: a legacy OXID eShop core, a newer Next.js storefront running across three production replicas, a separate checkout application, and a WordPress blog, all served behind nginx. The client reached out for hourly help introducing Payload as a CMS layer on top of that existing system.
What the Review Found
Fitting a CMS into an actively used, decade-old ecommerce architecture already mid-migration to Next.js required a different approach than a standalone Payload install. Product, pricing, and inventory data needed to stay owned by the existing commerce system, with Payload holding editorial and page content only. An early content audit mapped dozens of potential collections across the platform's B2B and blog sections, and the client deliberately scoped the first phase down to two pages: Careers and FAQ, migrated from static OXID templates into structured, localized Payload content, running inside the existing Storefront codebase rather than as a separate application.
A second finding surfaced once the build was underway. The storefront runs three Next.js replicas in production. An ordinary in-memory content cache would leave some replicas serving stale pages after every publish, since cache state on one replica has no way to know about a change on another. That pushed the scope to include a shared caching layer. The client's technical lead framed the requirement precisely: "we should regard Redis as a replacement for the APC cache in the old shop system. It serves as a central cache instance for the Next.js apps."
The Outcome
Payload went in embedded inside the existing Next.js Storefront project, backed by its own PostgreSQL database, while product, pricing, and order data stayed exactly where they were in the legacy commerce system. Marketing now has structured, localized Careers and FAQ page models with live preview and draft/publish workflows, ready to edit without a developer in the loop. Publishing a change triggers cache revalidation automatically across all three production replicas, backed by a shared Redis layer built specifically to replace the ad-hoc, replica-local caching that came before it. Delivery landed under the original estimate: about 18.9 hours against a 20-to-30-hour range, on a system with no existing precedent for a Payload integration to follow. The pages are built and integrated into the storefront codebase, with the client controlling the timeline for public rollout.