Migrating Homesware from Shopify to Custom Next.js: What Actually Happened (Real Numbers, Real Stack)

In late 2025, UK homeware retailer Homesware hit the ceiling of Shopify Plus. Their B2B wholesale flow needed customer-tier pricing across 12 segments, a custom approval workflow for new accounts, and integrations with their warehouse-management system that Shopify's apps couldn't deliver. We migrated them to a custom Next.js + Postgres + Stripe stack over 11 weeks. Page load went from 4.2s to 0.9s. Lighthouse score went from 52 to 96. Conversion lifted 18% within 60 days. Here's the full technical breakdown — the stack choices, the bugs we hit, the patterns that worked.

The setup: what Shopify Plus could not do

Homesware sells home decor wholesale to ~600 UK retailers and decorators, plus a B2C arm that's about 30% of revenue. Their B2B operation requires:

• 12-tier pricing. Each customer is assigned a tier (1-12) based on annual volume; prices are 10-45% below MSRP depending on tier. Some customers get bespoke pricing on specific SKUs.
• Net-30 / Net-60 payment terms. Approved accounts pay on invoice, not at checkout.
• Multi-step approval for new accounts. New trade applicants must submit VAT number, business registration, and trade references; approval involves a credit check.
• Warehouse integration. Real-time inventory sync with their on-premise WMS (Microsoft Dynamics-based).
• Bulk order entry. Trade customers paste a CSV of SKU + quantity and check out as a single order with PO number.
• Custom shipping rules. Free shipping above £500 for B2C; pallet-based shipping for B2B with regional carrier preferences.

Why Shopify Plus broke

Shopify Plus handles ~70% of the above out of the box. The remaining 30% required 4 custom Shopify apps (built by us), an external pricing engine, and a fragile webhook chain. By mid-2025, the architecture had become:

Shopify Plus → 4 custom apps → external Node.js pricing service → external account-approval workflow → external WMS bridge. Total monthly platform cost (Shopify Plus + Stripe + app subscriptions): £3,800. Page-load median: 4.2 seconds, mostly from the custom apps fetching pricing serially. Lighthouse score (mobile): 52. Conversion was visibly suffering from speed; the team's Storefront API queries were timing out under load.

We modeled two paths: rebuild the custom apps to be faster within Shopify, or migrate to fully custom. Custom won on three axes: (1) page-load could drop below 1s with edge rendering, (2) checkout could be customized fully (Shopify's checkout is locked unless you're on Shopify Plus + Checkout Extensibility, and even that's limited), (3) platform cost would drop by ~£3,000/month after migration.

The stack we picked (and why)

• Front-end: Next.js 15 with App Router. React Server Components for product pages (zero client JS for above-fold content), client components only where needed (filters, cart drawer).
• Hosting: Vercel. Edge rendering for product pages, ISR for category pages (revalidate every 60s on demand or via webhook from the CMS).
• Database: Postgres on Neon. 8 GB primary + a read replica in London. Postgres because the pricing logic is genuinely relational; SQL queries with CTEs were 10x cleaner than equivalent NoSQL.
• Search: Algolia. 14K SKUs, faceted search, instant typeahead. Indexed via webhook from our CMS.
• CMS: Sanity. Content team manages PDPs, blog, marketing pages.
• Auth: Clerk. Off-the-shelf for the auth UI and session management; we wrote the customer-tier authorization layer ourselves.
• Payments: Stripe. B2C: standard checkout. B2B: payment authorization with manual capture on order ship, plus invoice-based net-30 via Stripe Invoicing.
• Email: Resend. Transactional email for order confirmations, shipping notifications, invoice reminders.
• Analytics: Posthog (self-hosted) + GA4. Posthog for product analytics, GA4 for marketing attribution.
• Observability: Sentry + Vercel Analytics + Datadog APM.

The architecture

Three Next.js routes handle ~95% of traffic: /products/[handle] (product detail), /collections/[slug] (category browse), and /cart. All three use React Server Components by default — meaning the HTML is rendered on Vercel's edge with data already inlined, and the client hydrates only the interactive parts (size selector, add-to-cart button, quantity picker).

Pricing for a logged-in B2B customer is computed in a single SQL query that joins the customer's tier, any bespoke overrides, and any active promotion. The query is wrapped in a Postgres function so it can be called from a single Server Component fetch with row-level security enforcing that customers can only see their own pricing.

The checkout flow is custom — we don't use Stripe Checkout for B2B because we need to support 'order now, pay on invoice.' Instead we render a custom checkout form, validate inventory via a server action, create a Stripe PaymentIntent (B2C) or Invoice (B2B), and write the order to Postgres with status 'pending payment' or 'pending fulfillment.' The WMS bridge is a separate background job that polls every 60 seconds for orders ready to ship.

The migration plan that worked

• Week 1-2: Discovery. Mapped every Shopify metafield, every custom app's responsibilities, every webhook destination. Wrote a data dictionary.
• Week 3-4: Built the new schema in Postgres. Wrote a one-way data sync from Shopify to Postgres (read-only initially) so we could validate counts and edge cases against the live source of truth.
• Week 5-7: Built the storefront and customer area on Next.js. Pointed at the synced Postgres. Daily review with Homesware's team. Resolved ~80 edge cases in pricing and inventory that hadn't surfaced in the audit.
• Week 8: Soft-launched to a 5% traffic split via Vercel's split-routing. Monitored Sentry, Posthog, and Stripe for anomalies. Found 12 small bugs in the first 48 hours, fixed in 24.
• Week 9: Ramped to 50%. Two production issues — one race condition on inventory decrement (fixed by moving to a Postgres advisory lock), one Stripe webhook idempotency bug (fixed with proper deduplication).
• Week 10: 100% traffic to new stack. Turned off Shopify Plus storefront (kept Shopify Plus admin for legacy reporting until end of contract).
• Week 11: Cleanup, DNS verification, documentation handover.

Real before/after numbers

• Page load (median, mobile, product page): 4.2s → 0.9s (78% improvement)
• Page load (P95, mobile, product page): 7.8s → 1.6s (79% improvement)
• Lighthouse Performance (mobile): 52 → 96
• Lighthouse SEO: 78 → 100
• Lighthouse Accessibility: 72 → 98
• Time-to-First-Byte (edge): 1,100ms → 120ms
• Total monthly platform cost: £3,800 → £620 (Vercel + Neon + Sanity + Algolia + Clerk + Resend)
• B2C conversion rate: 1.42% → 1.68% (18% lift)
• B2B order abandonment rate: 31% → 14% (mostly from removing the slow legacy checkout)
• SEO traffic, 90 days post-launch: +34% organic sessions (despite the URL structure staying stable — Google rewarded the speed and Core Web Vitals improvements)

Three things we'd do differently

• Start the WMS integration earlier. The Dynamics bridge was the riskiest piece and we left it for Week 6. We'd start it Week 1 next time.
• Bigger soft-launch window. Five percent for 5 days wasn't enough to surface all edge cases. Ten percent for 10 days would have caught the inventory race condition in staging.
• Use Inngest or a queue from day 1. We hand-wrote background jobs initially; switched to Inngest in Week 10. Should have started there.

Lessons for any Shopify → custom migration

Shopify is genuinely good at what it does. Don't migrate just because custom is shinier — migrate because Shopify has hit a ceiling that's measurable in revenue or cost. For Homesware, the ceiling was clear: platform cost £3,800/month, page-load 4.2s, conversion suffering visibly.

Plan for 10-14 weeks, not 4-6. Migration projects nearly always take longer than greenfield because the existing edge cases have to be reproduced or explicitly retired.

Keep Shopify admin running through migration. The B2B team didn't switch admin UIs until week 10, which kept ops smooth.

Invest in observability from day one. Sentry caught 8 production bugs in the first 48 hours that would have hurt revenue if we'd waited for user reports.

Frequently Asked Questions

How much did the Homesware migration cost?

Total engagement: £58,000 over 11 weeks, fixed-bid. ROI hit within 8 months from platform-cost savings alone (£3,180/month saved × 8 months ≈ £25K), plus the conversion lift. By month 18 the migration was net-positive even before accounting for the conversion improvement.

Why Next.js instead of Remix or Astro?

We evaluated all three. Next.js won on (a) Vercel hosting maturity, (b) React Server Components for fast PDPs, (c) ecosystem (Stripe / Clerk / Sanity all have first-class Next.js examples), and (d) team familiarity. Remix would have worked; Astro is great for content but we needed more interactivity than Astro is optimized for.

Why Postgres instead of MongoDB or DynamoDB?

The pricing model is genuinely relational. A B2B customer's price for SKU X depends on their tier, active promotions, bespoke overrides, and inventory location. Joining these in SQL is clean; doing it in document or KV stores becomes a tangle. Postgres on Neon scales to 100K+ rows/second of reads with read replicas; nothing about Homesware's load required NoSQL.

How do you handle Shopify's good admin UX after migrating off?

We built a custom admin in the same Next.js codebase. Shopify's admin is genuinely good; ours is purpose-built for Homesware's workflows (bulk order entry, customer-tier management, approval queue). Took ~3 weeks of the 11 to build.

Can Apex migrate my Shopify / WordPress / Webflow store?

Yes. We've done ~12 of these. We always start with a 1-2 week paid discovery to determine if migration is the right call — sometimes the answer is 'stay where you are, but fix X.' If migration is right, expect 10-14 weeks at USD 40K-150K depending on scope.