David’s Bridal is one of the largest wedding dress retailers in the world, with more than 300 stores in 45 states, Canada, and the UK. In early 2019, David’s Bridal asked for our help on their ecommerce replatform. Another agency had been moving them off their old, on-premise Microsoft IBM system, but the project was stalled. David’s asked us to get it back on track — which we did, tackling a headless Magento2 implementation to support David’s Bridal’s entire operational infrastructure. Two years later, beta.davidsbridal.com went live.

On the surface, it sounds pretty straightforward: an online shop for wedding dresses. But building David’s Bridal a new ecommerce solution was never going to be easy. As a global legacy retailer, everything is happening at a massive scale: tons of operational infrastructure both online and in-store, a huge catalog of SKUs, and years worth of in-house systems at varying stages of evolution. 

Our challenge was to integrate a new ecommerce platform into this existing ecosystem — and have it not only reliably work, but also be able to scale with David’s Bridal roadmap and increase performance on both the front and back ends. Here’s what we did.

We executed David’s Bridal’s new ecommerce solution as a headless Magento2 implementation, decoupling the frontend experience from the back office entirely. There are plenty of compelling reasons to do this — but the biggest one for us was allowing Magento to power the full suite of frontend experiences, from the web store to the dress-finder quiz to the store locator and beyond. A monolith approach, where the front- and backends are integrated, wouldn’t allow us to deliver this true omni customer experience, or grow the ecosystem of applications down the road.

Headless also opened the door to delivering the web store with a progressive web app. That released us from having to build anything with a traditional responsive design in mind. With PWA, we can instead prompt users to download a unique app experience, giving us way more flexibility in our design and build without having to actually create iOS and Android mobile apps.

The agency David’s Bridal had originally hired tried to use Adobe Experience Manager for content and assets. That makes sense: the original agency was a certified Adobe partner. Adobe owns Magento. Adobe says the two systems can seamlessly integrate.

In reality, they can’t (not really) and integrating those two tech stacks was one of the reasons for the stalled project. But the agency’s hands were tied — as a certified partner, they didn’t have much flexibility to find alternatives to Adobe’s prescribed architecture.

Bilberrry isn’t a certified Adobe partner, so we had the freedom to get creative and find a way to make AEM and Magento work together. Ultimately, it was another headless implementation, with AEM on the backend delivering components via API, which we then rebuild on the frontend with REACT. Even though this solution is not quite as flexible as the David’s team originally envisioned — a standalone CMS controlled entirely by the marketing team, with no need for tech support — it actually works, without sacrificing the performance or scalability of the rest of the platform.

Building a web store in and of itself isn’t particularly challenging. It’s connecting the web store with all the other services that make David’s Bridal’s business run that is incredibly challenging: their PIM, the ERP they use to track product inventory and warehouse availability, all the data for imagery and size charts, the transaction hub and all of its corresponding systems, their customer hub and all of its corresponding systems, and on and on. 

These all existed already: some as legacy products that had been around for a decade, some still in the process of being built by David’s in-house team, and every stage in between. It was our job to make it all work in concert.

No services, built but different people on different tech stacks at different times with different requirements, are going to magically talk to each other. To make them start talking, we had to figure out what was going wrong. So we built a logging system on Magento to start tracking errors and failures across all the other services we were going to be integrating with. This in and of itself was a significant undertaking, especially as we had to chase down errors for systems we had no visibility into further and further downstream.

From there, we strategized if our Magento platform needed to flex to accommodate these other services, or vice versa – and then making recommendations for what other teams should update (or going in and fixing it ourselves when we could). When it took more than a single update to make it work, we tackled that too, including building some additional tools, like an advanced ElasticSearch layer to improve performance on filtering large datasets, and a proxy-layer between Magento and the in-house APIs providing data.

Ultimately, our ability to understand and integrate with David’s full operational ecosystem is what made our ecommerce solution successful — but it’s also what took us the longest.