Dutchie Plus Sunset 2026: Migration Guide for Dispensaries Losing Headless Commerce — Three Migration Paths, Decision Tree, and 8-Step Apex MenuEdge Cutover

Dutchie Plus is the headless commerce tier of the Dutchie POS stack. It exposes a GraphQL API that returns store metadata, product catalogs, pricing, availability, and checkout primitives in JSON. Operators consume that data in a custom front-end — usually Next.js, Astro, or Gatsby — and render a fully branded storefront with server-side rendering, custom URL structures (/shop/flower/blue-dream instead of /embed?menu=xyz), product-level schema markup, and unrestricted SEO indexability.

The standard Dutchie embed, by contrast, drops an iframe onto a host page. The iframe ships from dutchie.com, not the client's domain. Googlebot crawls the iframe wrapper but generally treats its contents as third-party rendered HTML, not indexable content on the host site. Product URLs live on Dutchie's domain, not the dispensary's. Page-level Core Web Vitals are tied to Dutchie's render budget, not the operator's.

Plus solved every one of those constraints. It is also expensive to maintain — GraphQL schema drift, store-level metadata variance, and SSO-gated regional inventory have generated significant support load. Source: industry reporting and Dutchie's own enterprise documentation indicates Plus serves a small enterprise minority while consuming a disproportionate share of integration support hours. Sunset is the predictable end-state.

The deprecation window matters. A 6-month runway means SEO equity must be re-anchored before the API stops responding. Operators who wait until the cutover date to plan will lose indexed URLs, product schema, and ranking position simultaneously.

Three paths are available. They are not equal. Each carries a different cost in SEO retention, engineering hours, and ongoing operational risk.

The cheapest path. Strip the headless front-end. Drop the standard Dutchie embed iframe onto a /menu page. Done in a sprint.

Cost: indexation. Product URLs disappear. Schema disappears. The menu becomes an iframe that contributes nothing to organic ranking. Bud Authority's own audits across 24 client repos show iframe-embedded menus generate 60–80% less organic menu-page traffic than headless-rendered equivalents over a trailing 90-day window. For any operator who invested in product-page SEO, this path is a write-down of that investment.

When it makes sense: a dispensary that never indexed products in the first place, runs a low-volume single location, and primarily drives traffic through GBP and Leafly. The headless cost was always speculative for them.

Bud Authority's solution. A Cloudflare Worker sits between the dispensary domain and the Dutchie embed (or any upstream menu vendor). The Worker rewrites the embedded HTML so menu content is served from the dispensary's own domain, with full URL control, server-rendered product pages, and indexable schema — regardless of what's on the other side.

When Dutchie Plus sunsets, MenuEdge continues serving menu pages from the dispensary's domain by proxying the standard Dutchie embed and rewriting it server-side. The SEO surface is preserved. Internal links continue to resolve. Product schema continues to emit. Operators do not have to switch POS, retrain staff, or migrate customer accounts. See /services/dutchie-plus-migration, /apex-menuedge, and /dutchie-seo for the architecture detail.

Cost: a one-time integration fee plus monthly Worker hosting (Cloudflare's CPU-time pricing is sub-cent per request at typical dispensary traffic levels). Engineering hours are concentrated in the cutover, not in ongoing maintenance.

When it makes sense: any operator who indexed products under Plus, has organic traffic to defend, and isn't separately motivated to leave Dutchie. This is the default Bud Authority recommendation for clients in scope.

The path selection collapses to four operator-profile questions.

The decision tree resolves most cases in under five minutes. Edge cases — operators with regional inventory variance, SSO-gated medical stores, or compliance frameworks that require provider-specific reporting — should book a scoping call before committing.

Dutchie announced the Plus headless commerce API sunset as part of its 2026 product roadmap with a 6-month deprecation runway. Enterprise customers were notified directly via account-manager communication. Exact end-of-life dates are tier-dependent and operators should request a written timeline from their Dutchie account manager. Plan migration to complete at least 60 days before the API stops responding.

Three options replace Dutchie Plus. The standard Dutchie iframe embed (cheapest, regresses indexation). A full menu-provider swap to Jane, Treez, or Flowhub (60–90 day project, retains headless capability). Or a reverse-proxy layer like Bud Authority's Apex MenuEdge, which sits between the dispensary domain and the standard embed and rewrites HTML so menu content is served from the dispensary's own domain with full SEO preservation.

It depends on the path. Falling back to the standard Dutchie iframe embed loses 60–80% of organic menu-page traffic in Bud Authority's audit data across 24 client repos. Switching providers maintains headless capability but introduces 60–90 days of transitional ranking volatility. A reverse-proxy migration (Apex MenuEdge) preserves indexed URLs, schema, and ranking position because menu content continues to serve from the dispensary's own domain.

Dispensaries facing the Plus sunset should not wait. The 6-month runway sounds long. It isn't, once a baseline crawl, a staging validation cycle, and a 30-day post-cutover monitoring window are subtracted from it.

Book a Dutchie Plus migration scoping call at /services/dutchie-plus-migration.