Jouw programmazoekopdracht loopt vast op 8,2 seconden. Alweer. Het is inschrijvingsweek en het studentenportaal zakt door elkaar — 40.000 eerstejaars verversen dezelfde verbroken zoekopdracht, jouw supportwachtrij loopt vol met tickets, jouw VP Inschrijvingen ziet conversietarieven in real-time dalen. Drupal 7 beveiligingspatches eindigen over zes maanden. Je hebt 200+ programmaapagina's, een legacy CMS die je team nauwelijks snapt, en een niet-onderhandelbare eis: nul downtime. Begin 2024 gaf een grote staatsuniversiteit ons precies dit probleem. Ze hadden een volledige migratie naar Next.js nodig voordat Drupal 7 offline zou gaan — en ze wilden dat hun programmazoeker zou stoppen met studenten te verliezen. Hier is hoe we hun volledige portaal in 26 weken hebben herbouwd, de zoekresponstijd naar 340ms hebben teruggebracht, en het hebben uitgerold zonder de site ook maar een minuut offline te halen.

Dit is het verhaal van hoe we het hele ding naar Next.js migreerden met een koppeloze CMS-backend, paginaladingstijden met 73% reduceerden, en het op schema hebben opgeleverd. Ik zal de architectuurbeslissingen delen die we hebben genomen (en degene die we bijna verkeerd hadden gedaan), het daadwerkelijke migratieproces, prestatiebenchmarks, en de lessen die van toepassing zijn op elke grootschalige CMS-migratie.

Inhoudsopgave

Case Study: Een universiteitsportaal migreren van Drupal naar Next.js

Het startpunt: Waarmee we werkten

Laat me het beeld schetsen. De digitale aanwezigheid van de universiteit was gebouwd op Drupal 7, oorspronkelijk gelanceerd rond 2014. In het afgelopen decennium had het zich opgestapeld:

  • ~12.000 inhoudsonderdelen over programma's, cursussen, faculteitsprofilen, nieuwsartikelen en evenementen
  • 200+ academische programmaapagina's, elk met complexe taxonomierelaties (graadniveau, afdeling, faculteit, afleveringsformaat, accreditatieststatus)
  • Een aangepaste programmazoeker gebouwd als een Drupal Views-gebaseerde zoektocht met geexponeerde filters — functioneel maar traag
  • Een studentenportaal met geverifieerde toegang tot adviestools, graadcontroleprogramma's, inschrijvingskoppelingen en gepersonaliseerde dashboards
  • 47 aangepaste Drupal-modules, waarvan 19 niet langer werden onderhouden
  • 3 verschillende themalagen gestapeld bovenop elkaar van opeenvolgende herontwerpen

De site was ondergebracht op twee verouderde virtuele machines achter een institutionele load balancer. Tijdens piekperiodes voor inschrijving (augustus en januari) zou de programmazoeker regelmatig time-out hebben. Het marketingteam was eraan toe gezet een PDF-lijst met programma's als back-up te plaatsen. Dat zegt je alles.

Core Web Vitals waren ruw:

Metriek Drupal 7 (Voor) Doel
LCP 6,2s < 2,5s
FID 380ms < 100ms
CLS 0,31 < 0,1
TTFB 2,8s < 0,8s
Programmazoeker laden 8,4s < 1,5s

Het belanghebbendelandschap

Universiteitswebprojecten zijn uniek uitdagend vanwege het aantal belanghebbenden. We werkten met:

  • Centrale IT — verantwoordelijk voor SSO-integratie, beveiligingsnaleving en hosting
  • Marketing & Communicatie — eigenaar van het merk, inhoudsstrategie en analytics
  • Het registratenkantoor — eigenaar van programmagevens en het student information system (SIS)
  • Individuele faculteiten en afdelingen — elk met hun eigen contentredacteurs (meer dan 80 personen met CMS-toegang)
  • Studentenraad — die luidruchtig pleitte voor mobiel-first design (terecht)

Het verkrijgen van afstemming van al deze groepen nam de eerste drie weken van het project in beslag. We voerden een designsprint uit om gedeelde prioriteiten en non-negotiables vast te stellen.

Waarom Next.js (en waarom niet Drupal 10)

De voor de hand liggende vraag: waarom niet gewoon upgraden naar Drupal 10? Het IT-team van de universiteit was daar zes maanden eerder al aan begonnen. Ze hadden het opgegeven nadat ze ontdekten dat 23 van hun 47 aangepaste modules geen Drupal 10-equivalent hadden en volledig herschreven zouden moeten worden.

De echte berekening zag er als volgt uit:

Factor Drupal 10-migratie Next.js-herbouw
Geschatte tijdlijn 8-10 maanden 6 maanden
Aangepaste moduleherschrijvingen 23 modules N/B (herbouwd als API's/componenten)
Herscooling van content-editors Matig (nieuwe beheerdersinterface) Matig (nieuw CMS)
Prestatiesplafond Matige verbetering Dramatische verbetering
Hostingflexibiliteit Traditioneel LAMP/soortgelijk Edge-implementatie, CDN-first
Werving van ontwikkelaars Krimpend (Drupal-specialisten) Groeiend (React/Next.js)
Jaarlijkse onderhoudskosten ~$180K ~$95K

Het verschil in onderhoudskosten was de doorslag voor het bestuur. Drupal-ontwikkelaars met institutionele ervaring werden moeilijker te vinden en duurder om vast te houden. Het eigen IT-team van de universiteit had drie React-ontwikkelaars en nul Drupal-specialisten nadat hun senior Drupal-ontwikkelaar met pensioen ging.

We kozen Next.js specifiek (boven Gatsby, Remix of Astro) om verschillende redenen:

  1. Hybride rendering — programmaapagina's konden statisch gegenereerd worden, terwijl het studentenportaal server-side rendering met verificatie nodig had
  2. API-routes — we konden middleware voor de SIS-integratie bouwen zonder een aparte backend-service
  3. Incrementele statische regeneratie (ISR) — programmagevens veranderen wekelijks, niet elk uur. ISR met een 1-uurs revalidatievenster was perfect
  4. Het team van de universiteit kende React — ze zouden dit na aflevering onderhouden

Als u vergelijkbare opties weegt, behandelt onze Next.js-ontwikkelingspagina de technische details van wat we doorgaans bouwen.

Architectuurbeslissingen

Koppeloze CMS-selectie

We evalueerden vijf koppeloze CMS-opties tegen de vereisten van de universiteit: 80+ content-editors, complexe inhoudsrelaties, rolgebaseerde machtigingen en een redelijk prijsmodel per zetel.

We landden op Sanity voor dit project. De belangrijkste factoren:

  • GROQ-vragen hebben de complexe taxonomierelaties tussen programma's, afdelingen en faculteiten veel beter aangepakt dan GraphQL voor dit geval
  • Realtime samenwerking — meerdere redacteurs konden gelijktijdig werken zonder conflicten
  • Aangepaste invoercomponenten — we hebben een programmaprerequisattekaartierer rechtstreeks in de studio gebouwd
  • Prijzen — het Enterprise-plan op ~$949/maand lag goed binnen budget, en de kostprijs per gebruiker was voorspelbaar

De inhoudsmodellering nam ongeveer twee weken in beslag. We definieerden 14 documenttypen en 8 referentietypen. Het programmaschema had alleen al 34 velden, inclusief gestructureerde gegevens voor schema.org EducationalOrganization en Course opmaak.

Voor meer informatie over onze benadering van CMS-architectuur, zie onze koppeloze CMS-ontwikkelingspagina.

Infrastructuur

We hebben op Vercel ingezet voor de Next.js-frontend (het Enterprise-plan, vereist voor FERPA-naleving en SSO-vereisten). De geverifieerde routes van het studentenportaal gebruiken server-side rendering met sessiebeheer via de bestaande CAS (Central Authentication Service) SSO van de universiteit.

De gegevensstroom ziet er als volgt uit:

[Sanity CMS] → [Next.js op Vercel] → [CDN Edge]
                    ↕
           [University SIS API]
                    ↕
           [CAS SSO / LDAP]

Statische programmaapagina's worden vooraf gegenereerd bij het bouwen en elk uur opnieuw gevalideerd via ISR. De programmazoeker maakt gebruik van een combinatie van vooraf opgehaalde gegevens (geladen in de client bij het bouwen als een JSON-index) en realtimefiltering — geen serverronde-trip nodig voor zoekbewerkingen.

De API-laag

Het student information system (Ellucian Banner, als je nieuwsgierig bent — het is altijd Banner) stelde een SOAP API beschikbaar. Ja, in 2024. We hebben een vertaallaag gebouwd met Next.js API-routes die de SOAP-eindpunten gebruikten en schone REST-eindpunten naar onze frontend leverden:

// /app/api/programs/[programId]/route.ts
import { NextRequest, NextResponse } from 'next/server';
import { fetchFromBanner } from '@/lib/banner-client';
import { transformProgramData } from '@/lib/transforms';

export async function GET(
  request: NextRequest,
  { params }: { params: { programId: string } }
) {
  const bannerData = await fetchFromBanner(
    'PROGRAM_DETAIL',
    { programCode: params.programId }
  );
  
  const program = transformProgramData(bannerData);
  
  return NextResponse.json(program, {
    headers: {
      'Cache-Control': 'public, s-maxage=3600, stale-while-revalidate=86400',
    },
  });
}

Deze vertaallaag was een van de waardevolste stukken van het project. Het ontkoppelde de frontend van Banner's eigenaardigheden en gaf de universiteit een schone API die ze voor toekomstige projecten konden gebruiken (een mobiele app werd al besproken).

Case Study: Een universiteitsportaal migreren van Drupal naar Next.js - architectuur

De programmazoeker: De kernfunctie herbouwen

De programmazoeker was de belangrijkste pagina op de hele site. Analytics toonden aan dat het 34% van al het organische zoekverkeer vertegenwoordigde en de #1 ingangspunt voor toekomstige studenten was. Dit verkeerd doen was geen optie.

De oude benadering (en waarom het traag was)

De Drupal-versie gebruikte Views met geexponeerde filters. Elke filterwijziging veroorzaakte een volledige serverronde-trip, voerde de database opnieuw uit en renderde de hele pagina opnieuw. Met 200+ programma's en 6 taxonomiedimensies (graadniveau, faculteit, afdeling, afleveringsformaat, interessegebied en trefwoordzoeking) was de query duur.

De nieuwe benadering

We hebben vooraf een zoekindex gebouwd. Al 200+ programma's werden geserialiseerd in een ~180KB JSON-bestand (gzip naar ~22KB) dat met de pagina wordt verzonden. Filteren gebeurt volledig aan de clientzijde met behulp van een aangepaste haak:

// hooks/useProgramSearch.ts
import { useMemo, useState } from 'react';
import Fuse from 'fuse.js';
import { Program, ProgramFilters } from '@/types';

const fuseOptions = {
  keys: [
    { name: 'title', weight: 0.4 },
    { name: 'description', weight: 0.2 },
    { name: 'keywords', weight: 0.3 },
    { name: 'department', weight: 0.1 },
  ],
  threshold: 0.3,
};

export function useProgramSearch(programs: Program[]) {
  const [filters, setFilters] = useState<ProgramFilters>({});
  const fuse = useMemo(() => new Fuse(programs, fuseOptions), [programs]);

  const results = useMemo(() => {
    let filtered = programs;

    if (filters.degreeLevel) {
      filtered = filtered.filter(p => p.degreeLevel === filters.degreeLevel);
    }
    if (filters.college) {
      filtered = filtered.filter(p => p.college === filters.college);
    }
    if (filters.deliveryFormat) {
      filtered = filtered.filter(p => 
        p.deliveryFormats.includes(filters.deliveryFormat!)
      );
    }
    if (filters.searchQuery) {
      const fuseResults = fuse.search(filters.searchQuery);
      const fuseIds = new Set(fuseResults.map(r => r.item.id));
      filtered = filtered.filter(p => fuseIds.has(p.id));
    }

    return filtered;
  }, [programs, filters, fuse]);

  return { results, filters, setFilters };
}

We gebruikten Fuse.js voor fuzzy textzoeking en gewone JavaScript-filtering voor facetten. Het resultaat: zoekresultaten verschijnen in minder dan 50ms. Geen laadspinners. Geen serveroproepen. Gebruikers kunnen de filters zo snel aanvallen als ze willen.

Elk programmaresultaat linkt naar een statisch gegenereerde detailpagina met volledige schema.org-opmaak, wat het voorkomen van de universiteit in Google's onderwijsgerelateerde zoekfuncties drastisch verbeterde.

Studentenportaalmigratie

Het studentenportaal was het lastigste deel. Het vereiste verificatie, personalisatie en realtimegegevens van Banner. We konden niets ervan statisch genereren.

Verificatiestroom

De universiteit gebruikt CAS voor eenmalige aanmelding in alle institutionele systemen. We hebben CAS geïntegreerd met Next.js met behulp van een aangepaste verificatiestroom:

  1. Onverifieerde gebruiker raakt /portal → omgeleid naar CAS-login
  2. CAS stuurt terug met een servicebiljet
  3. Onze API-route valideert het biljet tegen de CAS-server
  4. We creëren een ondertekende JWT opgeslagen in een httpOnly-cookie
  5. Daaropvolgende aanvragen gebruiken de JWT voor sessiebeheer

We gebruikten next-auth (nu Auth.js) met een aangepaste CAS-provider die we helemaal van nul af aan hebben geschreven, omdat er op dat moment geen onderhouden CAS-provider bestond.

Portaalfuncties

Het studentenportaal bevatte:

  • Gepersonaliseerd dashboard met aankomende inschrijvingsdatums, bezittingen en adviseurinformatie
  • Samenvatting graadcontrole live uit Banner opgehaald
  • Snelkoppelingen naar het LMS (Canvas), e-mail en bibliotheeksystemen
  • Programmaspecifieke resources op basis van de aangegeven specialisatie van de student

Alle portaalpagina's gebruiken server-side rendering. We cachen Banner API-reacties agressief (30-seconden TTL voor de meeste eindpunten, 5-minuten TTL voor graadaudits) om te voorkomen dat hun systeem wordt overbelast.

Inhoudsmigratiestrategie

Het migreren van 12.000 inhoudsonderdelen van Drupal naar Sanity vereiste een systematische benadering. We hebben een aangepaste migratiepijplijn gebouwd:

# Vereenvoudigde migratiepijplijn
1. Drupal-onderdelen exporteren → JSON via aangepaste Drush-commando's
2. JSON transformeren → Sanity-documentformaat via Node.js-scripts
3. Mediabestanden verwerken → uploaden naar Sanity CDN
4. Documenten importeren → Sanity Migration API
5. Valideren → geautomatiseerde controles op verbroken verwijzingen

De mediamigratie was het meest vervelende gedeelte. Drupal's bestandsbeheer slaat bestanden op met interne paden en databaseverwijzingen. We hebben een script geschreven dat:

  1. Elk bestand uit de Drupal-bestanden directory downloadde
  2. Het naar Sanity's asset-pijplijn uploaddde
  3. Oude Drupal-bestands-ID's toewijzen aan nieuwe Sanity-asset-verwijzingen
  4. Alle rich-text-inhoud bijwerken om naar de nieuwe asset-verwijzingen te verwijzen

Dit script liep ongeveer 14 uur op de volledige dataset. We hebben het driemaal in het project gebruikt: eenmaal voor initieel testen, eenmaal op het halftijdpunt om staging te verversen, en eenmaal voor de definitieve overstap.

Inhoudsstopstrategie

We hebben een tweefasenstop geïmplementeerd:

  • Weken 1-20: Content-editors werken normaal in Drupal. We migreren wekelijks snapshots naar staging.
  • Weken 21-23: Dubbele invoer. Nieuwe inhoud gaat in zowel Drupal als Sanity. Redacteurs getraind op nieuw CMS.
  • Week 24: Volledig overstap. Drupal wordt alleen-lezen, dan offline.

De periode met dubbele invoer was pijnlijk maar nodig. We hadden 80+ redacteurs en ze hadden spierspanning nodig met Sanity voordat het hun enige optie was.

Het 6-maandentijdschema

Maand Fase Belangrijkste opbrengsten
Maand 1 Ontdekking & Architectuur Afstemming van belanghebbenden, CMS-selectie, infrastructuurinstelling, inhoudsmodellering
Maand 2 Kerneontwikkeling Designsysteem, paginasjablonen, programmadetailpagina's, navigatie
Maand 3 Programmazoeker & Zoeken Zoekindex, filter-UI, programmagegevenspijplijn, SEO-opmaak
Maand 4 Studentenportaal CAS-integratie, Banner API-laag, dashboard, weergave graadcontrole
Maand 5 Inhoudsmigratie & Training Migratiescripts, editortraining (6 sessies), staging QA
Maand 6 QA, prestaties, lancering Belastingtests, toegankelijkheidsaudit, inhoudsstop, DNS-overstap

Ons team bestond uit 4 ontwikkelaars, 1 ontwerper en 1 projectmanager. De universiteit leverde een toegewijde producteigenaar plus een IT-liaison voor het Banner/CAS-integratiewerk.

We liepen tegen twee grote haken aan:

  1. Maand 3: Banner's SOAP API had een niet-gedocumenteerde tariefbeperking van 100 verzoeken/minuut. Onze programmazoeker was ontworpen om alle programmagevens in één keer op te halen. We moesten een wachtrijsysteem implementeren en de build over meerdere batches spreiden.

  2. Maand 5: De toegankelijkheidsaudit vond 34 WCAG 2.1 AA-schendingen. De meeste erfden van het ontwerp (onvoldoende kleurcontrast op secundaire knoppen, ontbrekende focusaanduidingen op de programmazoekfilters). We hebben onvoorzien 8 dagen aan herstel besteed.

Prestatieresultaten

Hier is wat de nummers na de lancering zagen:

Metriek Drupal 7 (Voor) Next.js (Na) Verbetering
LCP 6,2s 1,1s 82% sneller
FID / INP 380ms 45ms 88% sneller
CLS 0,31 0,02 94% beter
TTFB 2,8s 0,12s 96% sneller
Programmazoeker laden 8,4s 0,8s 90% sneller
Lighthouse-score 34 97 +63 punten
Bouwtijd (volledig) N/B 4m 12s —
Maandelijkse hostingkosten ~$2.400 ~$1.100 54% lager

Maar de nummers die het meest belangrijk waren voor de universiteit waren deze:

  • Gebruik programmazoeker nam toe met 156% in het eerste semester na de lancering
  • Mobiel bounce-tarief daalde van 67% naar 31%
  • Organisch zoekverkeer naar programmaapagina's nam toe met 43% binnen 4 maanden (schema.org-opmaak + Core Web Vitals-verbeteringen)
  • Ondersteuningstickets met betrekking tot het portaal daalde met 62% — vooral omdat pagina's nu betrouwbaar laden
  • Nul downtime tijdens herfstinschrijving — de eerste keer in drie jaar

Geleerde lessen

1. Begin de CAS/SSO-integratie vroeg

We hebben de CAS-integratie voor maand 4 gepland. We hadden een proof of concept in maand 1 moeten starten. Universiteit IT-teams gaan voorzichtig (lees: langzaam) door veiligheidskeuringen. Het verkrijgen van goedkeuring voor de SSO-architectuur kostte drie weken heen en weer met hun beveiligingskantoor.

2. Inhoudsmodellering is architectuur

We besteedden twee volledige weken aan inhoudsmodellering voordat we frontend-code schreven. Dit voelde langzaam aan op het moment. Het was de beste investering die we deden. Als je 200+ programma's hebt met complexe relaties tussen afdelingen, faculteiten, graadniveaus, concentraties en afleveringsformaten, levert het krijgen van het schema goed vooraf honderden uren herstructurering op.

3. Train editors vroeg, niet net voor lancering

We hadden aanvankelijk editortraining voor maand 5 gepland. We hebben het naar maand 4 verplaatst na feedback van de producteigenaar. Dit gaf redacteurs zes weken de tijd om vertrouwd te raken met Sanity in plaats van twee. De kwaliteit van inhoud die tijdens de dubbele-invoerperiode werd ingevoerd, was aanzienlijk beter vanwege dit.

4. Banner is Banner

Als je met Ellucian Banner werkt (en als je in hoger onderwijs bent, doe je dat waarschijnlijk), budget extra tijd voor de API-integratie. De documentatie is schaars, de SOAP-eindpunten zijn inconsistent, en elke instelling heeft Banner anders aangepast. Onze vertaallaag was essentieel.

5. Budget voor toegankelijkheid vanaf dag één

Onze 34 WCAG-schendingen op maand 5 waren bijna volledig te voorkomen. We voeren nu axe-core-controles uit in onze CI-pijplijn bij elke pull-request. Als je voor een openbare universiteit bouwt, is WCAG 2.1 AA-compliance niet optioneel — het is een wettelijke eis onder Section 508.

Als u voor een vergelijkbare migratieuitdaging staat, helpen we graag bij het doorlopen van de details. Je kan direct contact met ons opnemen of onze prijspagina raadplegen voor hoe we meestal deze projecten omvangen.

Veelgestelde vragen

Hoe lang duurt het om een universiteitswebsite van Drupal naar Next.js te migreren? Voor een site van deze schaal — 12.000 inhoudsonderdelen, 200+ programma's, geverifieerd studentenportaal — zes maanden is realistisch met een toegewijdd team van 4-6 personen. Kleinere institutionele sites (onder 2.000 pagina's, geen portaal) kunnen vaak in 3-4 maanden worden gedaan. De tijdlijn wordt minder aangestuurd door het frontend-bouw en meer door inhoudsmigratie, afstemming van belanghebbenden en integratie met institutionele systemen zoals Banner of PeopleSoft.

Wat is het beste koppeloze CMS voor universiteitswebsites in hoger onderwijs? Het hangt af van de grootte en technische kracht van je redactieteam. We kozen Sanity voor dit project vanwege de realtime samenwerking, flexibele inhoudsmodellering en GROQ-querytaal. Contentful en Storyblok zijn ook sterke opties. Voor universiteiten met zeer grote contentteams (100+ redacteurs) kan Contentful's workflow en machtigingenmodel voordelig zijn. Voor kleinere teams die meer aanpassing willen, wint Sanity meestal.

Kan Next.js geverifieerde studentenportalen verwerken? Absoluut. Next.js ondersteunt server-side rendering voor geverifieerde pagina's, en de App Router's servercomponenten maken het eenvoudig om gebruikersspecifieke gegevens op te halen zonder deze in de clientbundel bloot te stellen. We hebben geïntegreerd met CAS (Central Authentication Service) met behulp van Auth.js met een aangepaste provider. Het portaal verwerkte 40.000 studenten zonder prestatieproblemen.

Hoeveel kost een Drupal naar Next.js migratie voor een universiteit? Een project van deze omvang — programmazoeker, studentenportaal, 200+ programma's, volledige inhoudsmigratie, CMS-instelling en training — ligt doorgaans tussen de $250.000 en $450.000, afhankelijk van complexiteit. De langetermijnbesparingen zijn echter aanzienlijk. Deze universiteit reduceerde hun jaarlijkse onderhoudskosten van ongeveer $180K naar $95K, wat betekent dat het project zich zelfs aan de hogere kant van het budgetbereik binnen 3-4 jaar terugbetaalt.

Wat gebeurt er met SEO tijdens een grootschalige CMS-migratie? Dit is een legitiem punt van zorg. We hebben een uitgebreid omleidingskaart geïmplementeerd (meer dan 2.400 301-omleidingen), bestaande URL-structuren waar mogelijk behouden en schema.org gestructureerde gegevens toegevoegd die de Drupal-site miste. Organisch verkeer daalde ongeveer 8% in de eerste twee weken na de lancering (normaal voor elke grote migratie), herstelde toen en overschreed de baseline binnen vier maanden met 43%.

Is Drupal 10 een betere keus dan headless voor universiteiten? Het kan zijn, afhankelijk van de situatie. Als je team sterke Drupal-expertise heeft, je aangepaste modules Drupal 10-compatibiliteit hebben, en je hebt geen behoefte aan de prestatiekenmerken van een statische/hybride site, is Drupal 10 een volkomen geldige weg. In ons geval had de universiteit hun Drupal-expertise verloren, had 23 incompatibele modules en had dramatische prestatiebevorderingen nodig. De koppeloze benadering was duidelijk de betere oplossing.

Hoe handle je inhoudsmigratie van Drupal naar een koppeloze CMS? We gebruiken aangepaste Node.js-scripts die Drupal-inhoud exporteren via Drush-commando's, de gegevens transformeren naar het nieuwe CMS-schema, mediabestandsmigratie afhandelen en alles importeren via de migratie-API van het CMS. Het proces wordt doorgaans 3 keer uitgevoerd: eenmaal voor initieel testen, eenmaal voor staging-verversing en eenmaal voor definitieve overstap. Rich-text-inhoud met ingebedde media is het moeilijkste — je moet elke interne bestandsverwijzing opnieuw toewijzen.

Kunt u Drupal en Next.js gelijktijdig uitvoeren tijdens migratie? Ja, en we bevelen het aan. Tijdens onze migratie bleef Drupal de productiesite serveren terwijl we de Next.js-versie bouwden en testten op een stagingdomein. We gebruikten een driewekse periode met dubbele invoer waarin inhoud in beide systemen ging. De definitieve overstap was een DNS-schakelaar die ongeveer 15 minuten duurde, met Drupal gedurende 30 dagen als terugval alleen-lezen.