Hey Vercel community 👋
Sharing a case study I think this community will find useful — we migrated a 3-year-old WordPress e-commerce site to a complete headless Next.js stack on Vercel. Zero drops in Google Search Console. Now running $38K/month in revenue on $25/month in total tooling.
Live site: pandapatches.com
The business problem
Panda Patches is a custom embroidered patch e-commerce brand. Think military unit patches, company logos, band merch, scouts, law enforcement, sports teams — anything that needs a stitched-on patch made to spec. The business had been on WordPress + WooCommerce for 3 years and was grinding against hard limitations.
The killer problem: WordPress couldn’t quote a price.
Custom patches don’t have a fixed SKU. Every order is a matrix of variables:
- 9 patch types (embroidered, woven, PVC, chenille, leather, silicone, printed, sequin, 3D)
- Custom dimensions (the customer types in any width × height they want)
- 8+ quantity tiers (with volume discounts that change every 25 units)
- 3 backing options (iron-on, velcro, peel-and-stick — each with different costs)
- 2 border types (merrowed vs hot-cut, priced differently)
- Rush fees that vary by production complexity
Multiply those together and you have thousands of possible price combinations. WordPress had zero way to calculate this live, so every customer who visited the site filled out a contact form and waited 24+ hours for a human to manually calculate a price and email it back. You can guess how well that converted.
Most potential customers didn’t wait. They went to a competitor who showed them a price instantly, or they gave up on the idea entirely. The business was leaking qualified buyers every single day.
On top of that, 7 team members were operating across 5 disconnected tools: WordPress for the store, a separate CRM, Google Sheets for order tracking, a spreadsheet for attendance, and WhatsApp for all team communication. Every order status update was a manual copy-paste across three systems. Monthly tooling costs were pushing $250+ with no real-time visibility across any of it.
The migration
The hard part wasn’t the rebuild. It was preserving 3 years of SEO equity during the cutover. A 3-year-old WordPress site with real Google rankings and organic traffic is exactly the scenario where most migrations fail and the business owner watches their organic search traffic collapse 30 days post-launch.
Here’s the exact playbook we used:
- Full URL audit — exported every indexed URL from Google Search Console before touching any code. Mapped each old URL to its new equivalent on the Next.js site. Zero orphan pages.
- 301 redirects in Next.js middleware — every old WordPress URL gets a server-side 301 to the matching Next.js route. Configured in
middleware.ts. Fast, edge-deployed, no function cold starts. - Meta titles and descriptions preserved — we carried over the exact meta tags from WordPress where they were already ranking. No rewriting, no experiments during migration.
- Schema markup upgraded, not replaced — the old site had basic WordPress schema. We rebuilt it as a complete (Organization, Product, Article, BreadcrumbList, FAQPage) without changing the entity signals Google already trusted.
- Fresh sitemap.xml submitted day one — new sitemap generated automatically via
next-sitemap, submitted to Google Search Console within an hour of DNS cutover. Google started recrawling within 3 hours. - Core Web Vitals improved dramatically — load time dropped from 4+ seconds on WordPress to under 1 second on Next.js. Google rewarded the improvement with better rankings, not worse.
Result: zero drops in Google Search Console. We watched every ranked keyword daily for 30 days post-launch. Not a single drop. No 404 spikes. No impression collapses. No manual actions. After 60 days, rankings actually improved because the new site loads under 1 second, which Google’s 2026 Core Web Vitals algorithm rewards heavily.
The stack (all running on Vercel)
- Next.js 16 with React 19 on Vercel Edge (free tier)
- Sanity CMS for all content (products, blog, pages, site copy)
- Supabase for the ops database, auth, and sales agent dashboards
- Stripe Payment Element handles card payments plus Klarna, Afterpay, and Apple Pay in one integration
- PayPal as an alternative checkout path
- Upstash Redis for rate limiting the calculator endpoint
- Tailwind CSS 3 for styling
- Zod for schema validation on forms and API routes
- React Hook Form for the pricing calculator form state
- Zeptomail for transactional email (order confirmations, quote emails)
- next-sitemap for automated sitemap generation every build
- TypeScript pricing engine running fully client-side, under 5ms per calculation
Total monthly cost for everything above: $25. Vercel free tier carries most of the load.
The pricing calculator (technical highlight)
This is the part other Next.js devs will care about. We pre-compile the full pricing matrix into a TypeScript function at build time. No API calls per keystroke, no server round-trips, no loading spinners. The user selects a patch type, types in dimensions, picks quantity and backing options, and the exact price appears instantly.
Under the hood:
- Pricing rules live in a single
pricing-engine.tsfile with strongly-typed inputs - Volume discount tiers are stored as a sorted array of thresholds
- Each patch type has its own cost multiplier based on material and production complexity
- Border and backing costs are added as flat modifiers
- Rush fees are conditional modifiers based on production queue state
- Total calculation runs in under 5ms on a mid-range mobile device
- Works offline after first page load
The whole engine compiles to about 8KB of minified JavaScript. It ships with the page, there’s no separate API endpoint. Zero infrastructure cost for pricing.
| Metric | Before (WordPress) | After (Next.js on Vercel) |
|---|---|---|
| Monthly revenue | Approx $12K/mo, declining | $38K+/mo, growing |
| Tooling cost | $250+/mo across 7 tools | $25/mo total |
| Load time | 4+ seconds | Under 1 second |
| Lighthouse score | 42 mobile, 68 desktop | 90+ both |
| Time to quote | 24+ hours (manual email) | Instant (self-serve) |
| Google rankings | 3 years of equity at risk | 100% preserved, zero GSC drops |
| Team tools | 7 disconnected systems | 1 unified ops platform |
What we replaced
- WordPress + WooCommerce ($80/mo)
- Separate CRM (HubSpot/Zoho alternative, $50/mo)
- Google Sheets for order tracking (free but 10+ hours/week of manual work)
- Separate attendance tracker ($30/mo)
- WhatsApp for team status updates (chaos)
- Quote email automation tool ($40/mo)
- Cache/performance plugin subscription ($15/mo)
**7 tools, $200+/mo, replaced by one integrated custom build at $25/mo. **
The full technical case study
We wrote up the migration process in detail — the redirect strategy, the pricing engine architecture, the Sanity schema design, and the Supabase ops portal — in a full technical case study. Worth a read if you’re tackling a similar WordPress migration and want the exact redirect mapping approach we used.
What I’d love to discuss
Genuinely curious to hear from other devs in this community:
- Redirect mapping at scale — how do you handle the 301 redirect phase on large legacy sites? We wrote them manually for ~200 URLs, but I’m curious if anyone has automation tips for thousands of URLs.
- Pricing engines client-side — anyone else built large pricing matrices that run entirely in the browser? What are the tradeoffs vs a serverless API route for complex calculations?
- Sanity + Supabase together — we use Sanity for public content and Supabase for private ops data. Anyone split CMS + database like this? Curious how others structure this separation.
- SEO-safe cutover — any horror stories where a migration tanked rankings? What did you learn?
Happy to answer any technical questions about the stack or the migration process. This is my own in-house brand so I can share details other agencies can’t.
Built by Hassan Jamal’s team in Austin, TX. We specialize in WordPress to Next.js migrations with full SEO preservation.