Migreer Optimizely CMS 12 naar Next.js + Supabase

Waarom ondernemingen Optimizely CMS 12 verlaten

Optimizely CMS 12—de PaaS-evolutie van wat eens Episerver was—had zijn moment. Het bundelde CMS, commerce en personalisatie in een beheerde Azure-omgeving, en dat werkte een tijd lang. Maar we zijn nu in 2026: monolithische .NET-roots, stijgende licentielagen, en een shared-infrastructure-model dat prestatielimieten creëert die je engineeringteam letterlijk niet kan doorbreken.

We hebben ondernemingsteams gemigreerd die Optimizely DXP verlieten en $200K–$500K per jaar alleen aan licentiekosten betaalden. Ze hadden multi-channel delivery nodig, sub-300ms TTFB, en de mogelijkheid om React-ontwikkelaars in plaats van .NET-specialisten aan te nemen. De wiskunde klopte niet meer.

De echte pijnpunten van Optimizely DXP

Licenties die tegen je opschalen

De gelaagde prijsstelling van Optimizely—Group, Corporate, Enterprise—rekent per omgeving en per Web App. Voeg commerce-modules, personalisatie-add-ons en aangepaste integraties toe, en je kijkt naar zes-cijferige jaarlijkse verlengingen die elke contractcyclus stijgen. Wanneer je marketingteam een nieuwe microsite wil, begint het budgetgesprek met licenties. Niet design. Licenties.

Prestatielimieten ingebakken in de architectuur

Optimizely DXP draait op gedeelde Azure PaaS-infrastructuur. Je Integration-, Preproduction- en Production-omgevingen delen één Web App en zoekindex. Realistische Lighthouse mobile scores voor de meeste Optimizely-sites die we auditeren liggen tussen 45–65. De SCA-casestudy—veel aangehaald door Optimizely zelf—toonde verbetering van 43 naar 70. Dat is vooruitgang, zeker. Maar het is niet concurrerend. Moderne headless builds halen consistent 95–100.

Developer Experience-wrijving

Het .NET-only templating-systeem betekent dat je frontend-ontwikkelaars niet de tools kunnen gebruiken die ze werkelijk kennen. Elke UI-wijziging vereist een volledige full-stack .NET deployment-cyclus. Probeer in 2026 senior .NET CMS-ontwikkelaars aan te nemen—die talentpool krimpt terwijl React/Next.js-ontwikkelaars overal zijn en goedkoper.

Migratietools die meer problemen creëren

Optimizely's eigen Project Migration-tool voor CMS 11→12 upgrades toont de scheuren. Nieuwe Linux Docker DXP-instanties opzetten, blobs kopiëren via Azure Storage Explorer met tijdelijke SAS-links, databasekopieën die 20+ minuten duren voor grote sites—en dat is alleen maar het bewegen tussen Optimizely-versies. Stel je voor wat een volledig vertrek zonder het juiste agentschap betekent.

Vendor lock-in bij ontwerp

Content models, blokstructuren, paginahiërarchieën, taxonomiebomen—het leeft allemaal in propriëtaire formaten. Er is geen "Export to JSON"-knop. Elk jaar dat je blijft, groeit de schakkelkost. Dat is niet toevallig.

Wat je krijgt met Next.js + Supabase

De doelarchitectuur is een composable stack: Next.js 15 op Vercel voor de frontend, Supabase (PostgreSQL + Auth + Storage + Edge Functions) als backend en content layer, en Cloudflare voor edge caching en DDoS-bescherming.

Prestaties die Core Web Vitals winnen

Next.js App Router met ISR (Incremental Static Regeneration) levert sub-300ms TTFB wereldwijd. Statische pagina's genereren bij build time; dynamische content revalideert on demand. Lighthouse mobile scores van 95–100 zijn de basis, niet de ambitie.

Open-source economie

Supabase Pro tegen $25/maand vervangt een $200K/jaar DXP-licentie. Vercel hosting tegen $20/site vervangt $10K+/maand Azure PaaS-kosten. Driejaarse TCO daalt van $900K+ naar ongeveer $300K, inclusief de migratie zelf. ROI wordt positief binnen 12 maanden.

Echt headless, niet headless-adjacent

Optimizely CMS 13 beval headless capabilities aan, maar het is nog steeds PaaS-first met een API eraan geplakt. Supabase is API-native. Elk stuk content is toegankelijk via REST of GraphQL, beveiligd met row-level security policies. Je mobiele app, je web app, je kiosk—dezelfde content API, nul aanvullende licenties.

Moderne developer workflow

React-componenten, TypeScript, Git-gebaseerde deployments, preview-omgevingen per PR, edge functions voor server logic. Je team verzendt features in dagen, niet in sprintcycli. En de aanwervingspijplijn opent zich voor de grootste frontend developer-gemeenschap ter wereld.

Ons migratieproces

Aryan Shah, onze Platform Migrations Lead, heeft een herhaalbaar playbook gebouwd voor Optimizely DXP-exits die elk stuk content bewaart, SEO-equiteit handhaaft en zero downtime bereikt.

Fase 1: Diepgaande audit (Weken 1–3)

We brengen je volledige Optimizely content model in kaart—page types, block types, content areas, taxonomiebomen, media assets, URL-structuren en integratietoetspunten. We exporteren een volledige inventaris en markeren content die herstructurering nodig heeft versus content die 1:1 tot Supabase schemas mappt.

Fase 2: Schemaontwerp & ETL-pijplijn (Weken 4–8)

Custom Node.js ETL-scripts extraheren content uit Optimizely's database en transformeren deze in Supabase PostgreSQL-tabellen. Taxonomiehiërarchieën behouden hun recursieve tabelstructuren en RLS-policies die je bestaande RBAC-permissies weerspiegelen. Media assets migreren van Azure Blob Storage naar Supabase Storage. We hebben catalogi van 50K+ assets in onder een uur verwerkt met parallelle upload-pijplijnen.

Fase 3: Frontend-build (Weken 6–14)

Next.js 15 App Router frontend, component-voor-component gebouwd tegen je bestaande design system. We repliceren niet alleen—we optimaliseren. Elk Optimizely block type wordt een React Server Component. Navigatie, zoeken en filteren verplaatsen naar Supabase Edge Functions, waardoor Optimizely's gedeelde zoekindex wordt vervangen door dedicated, snelle infrastructuur.

Fase 4: SEO-behoud (Parallel track)

Hier mislukken migraties. Dit is waar we slagen. Elke URL krijgt een mapping en 301 redirects worden via Cloudflare edge geconfigureerd. XML-sitemaps regenereren automatisch vanuit Supabase content. Structured data (JSON-LD) wordt per page type herbouwd. We monitoren Google Search Console gedurende de migratie en 90 dagen na de lancering om indexatie-anomalieën op te vangen.

Sleutel SEO-acties:

• Volledige URL-audit en redirect-mapping
• Canonical tag-behoud
• Validatie van interne linkstructuur
• Meta title/description migratie met programmatische verificatie
• Schema markup rebuild
• Robots.txt en sitemap.xml regeneratie

Fase 5: Zero-downtime cutover (Week 15–16)

Blue-green deployment. De nieuwe Next.js + Supabase stack draait parallel op Vercel terwijl de Optimizely-site live blijft. Laatste content sync draait 2 uur voor cutover. DNS schakelt via Cloudflare met directe propagatie. Traffic shift zonder downtime. We houden de oude omgeving 30 dagen warm als veiligheidsnet.

Fase 6: Post-launch optimalisatie (Weken 17–20)

Prestatiesmonitoring, CWV-tracking, editor training op Supabase Studio (of een lichte CMS-laag zoals Payload CMS als je editors een visuele interface nodig hebben), en overdracht documentatie.

Timeline en investeringen

Een typische ondernemings Optimizely DXP-exit duurt 14–20 weken van audit tot lancering. De prijsstelling varieert van €150K–€350K afhankelijk van content volume, aantal sites, integratiecomplexiteit en lokalisatievereisten.

Ter referentie: je volgende Optimizely DXP-vernieuwing is waarschijnlijk $200K+. De migratie betaalt zichzelf terug voor jaar twee.

Voor wie dit is

Undernemingsteams die Optimizely CMS 12 (of legacy Episerver) uitvoeren en een verlengingsbeslissing stellen, prestatieproblemen bestrijden, of gewoon niet snel genoeg kunnen leveren. Als je engineeringteam meer tijd besteedt aan het worstelen met het platform dan aan het bouwen van features, is het tijd om te gaan.

We doen geen generieke re-platforms. Aryan en het team kennen Optimizely's internals koud—het content model, de blob storage quirks, de deployment pipeline beperkingen. Daarom kunnen we taxonomiebehoud en zero downtime garanderen. Dit is onze eerste exit niet.