DEV Community

Paradane
Paradane

Posted on

How We Migrated a Client from WordPress to a Custom Next.js Storefront

#webdev #nextjs #ecommerce #softwaredevelopment

Last year, a client came to Paradane with a WordPress/WooCommerce store that was buckling under growth. Page loads were hitting 6 seconds, the checkout flow broke under concurrent users during sales, and every plugin update felt like defusing a bomb. They needed something faster, more reliable, and flexible enough to support their expansion plans. Here's exactly how we migrated them to a custom Next.js storefront — and what we'd do differently next time.

The Starting Point

The existing stack:

  • WordPress 6.x with WooCommerce
  • 47 active plugins (yes, we counted)
  • Shared hosting that throttled CPU after 200 concurrent visitors
  • A custom theme that had been patched by 4 different developers over 3 years
  • No staging environment — changes went straight to production

The pain points:

  • Product pages took 4-6 seconds to load (LCP was 8.2s on mobile)
  • Checkout would randomly fail when more than 15 users were active
  • Adding a new payment provider meant finding a WooCommerce plugin, testing it live, and praying
  • The admin dashboard was so slow that updating inventory took 30+ seconds per product

The Target Architecture

We designed a headless commerce setup:

┌─────────────────────────────────────────────┐
│                 Next.js 14                   │
│  ┌──────────┐  ┌──────────┐  ┌───────────┐  │
│  │  Product  │  │  Cart &   │  │   Blog    │  │
│  │  Pages    │  │  Checkout │  │  (ISR)    │  │
│  └──────────┘  └──────────┘  └───────────┘  │
└──────────────┬──────────────────────────────┘
               │
       ┌───────┴────────┐
       │  API Gateway   │  (Node.js/Express)
       └───────┬────────┘
               │
    ┌──────────┼──────────┐
    │          │          │
┌───┴───┐ ┌───┴───┐ ┌───┴───┐
│Woo    │ │Payment│ │Search │
│REST   │ │(Stripe│ │(Types │
│API    │ │direct)│ │ense)  │
└───────┘ └───────┘ └───────┘
Enter fullscreen mode Exit fullscreen mode

Key decisions:

  • Kept WooCommerce as the backend. The client's team already knew it, and the REST API is solid. No need to replatform the entire commerce engine.
  • Next.js App Router with Server Components. Product listing pages render on the server with streaming — users see content immediately while images load progressively.
  • Incremental Static Regeneration for the blog and marketing pages. Rebuilds every 10 minutes when content changes, serves static HTML otherwise.
  • Stripe Elements embedded directly. No WooCommerce payment gateway plugin — we call Stripe's API from the frontend for a faster, more reliable checkout.
  • Typesense for search. Replaced the slow WordPress native search with instant typo-tolerant search. Index syncs from WooCommerce via webhooks.

The Migration: Phase by Phase

Phase 1: API Layer (Week 1-2)

We built an Express API gateway that sat in front of WooCommerce's REST API. This let us:

  • Cache product data aggressively (Redis, 5-minute TTL for product details)
  • Normalize the WooCommerce API responses (their JSON structure is... creative)
  • Add rate limiting and request validation
  • Keep the WordPress site running untouched while we built the new frontend

Phase 2: Product Pages (Week 3-4)

We rebuilt the product listing and detail pages in Next.js, pulling data through the API gateway. The first deploy was a separate subdomain (next.theirbrand.com) so we could test with real traffic without affecting the main site.

Immediate wins:

  • Product page load dropped from 5.2s to 0.8s
  • Mobile LCP went from 8.2s to 1.9s
  • Category pages with 100+ products loaded instantly (server-side rendering with streaming)

Phase 3: Checkout (Week 5-6)

This was the hardest part. The old checkout had 7 steps, 3 plugin dependencies, and a fragile AJAX cart. We rebuilt it as a single-page flow:

  1. Cart review (client-side, synced with WooCommerce session)
  2. Shipping address → real-time shipping rate calculation via WooCommerce API
  3. Payment → Stripe Elements embedded, tokenized on the client
  4. Order confirmation → WooCommerce order created via API, confirmation email triggered

We also added:

  • Address autocomplete (reduced form errors by 60%)
  • Cart persistence across devices (WooCommerce session + localStorage fallback)
  • Abandoned cart recovery (webhook to the client's email platform)

Phase 4: Cutover (Week 7)

We pointed the primary domain to the Next.js deployment on Vercel, kept WordPress running on a subdomain for the admin team, and monitored everything through Datadog. The cutover took 45 minutes with zero downtime — we used a gradual DNS switch with both versions live simultaneously.

The Results

Metric Before (WordPress) After (Next.js)
Avg page load 5.2s 0.8s
Mobile LCP 8.2s 1.9s
Checkout completion rate 62% 84%
Concurrent users before degradation ~200 5,000+
Time to add payment provider 2-3 days 4 hours
Plugin count 47 0

Revenue increased 18% in the first month after migration, mostly from the improved checkout completion rate and faster page loads reducing bounce.

What We'd Do Differently

  1. Start with the checkout, not the product pages. The checkout was the biggest revenue lever. We should have prioritized it in Phase 1 instead of Phase 3.
  2. Build the API gateway as a separate service from day one. We initially called WooCommerce REST directly from Next.js Server Components, then had to refactor when we needed caching and rate limiting. The gateway should have been step zero.
  3. Set up staging earlier. We tested on a subdomain with real traffic, which worked but was stressful. A proper staging environment with synthetic traffic would have caught the cart session bug we found on launch day.
  4. Plan the WordPress retirement timeline upfront. The client still uses WordPress for content management, which is fine, but we didn't define how long that dual-system arrangement would last. Six months later, they're still paying for WordPress hosting they barely use.

Is This Right for You?

A headless migration makes sense when:

  • Your store's frontend performance is hurting conversion rates
  • You need custom checkout flows that WooCommerce plugins can't deliver
  • You want to add channels (mobile app, POS, wholesale portal) that share the same commerce backend
  • Your development team is comfortable with a modern JavaScript framework

It's probably overkill if:

  • Your store is doing under $50k/month in revenue
  • Your current WordPress setup is fast enough (under 2s page loads)
  • You don't have a developer who knows Next.js or similar

At Paradane, we've done this migration pattern three times now, and the ROI has been clear every time: faster stores make more money. The key is keeping the commerce engine you know (WooCommerce, Shopify, BigCommerce) and replacing only the customer-facing layer.

Have you migrated a store from WordPress to a headless setup? What surprised you most? Drop your experience in the comments — I'm always looking to learn from other teams' migration stories.

Top comments (0)