Artikel naar Nederlands vertaald

Begin 2024 kwam een grote staatsuniversiteit naar ons toe met een probleem dat in het hoger onderwijs pijnlijk vaak voorkomt: hun Drupal 7-installatie naderde het einde van de levensduur, hun studentenportaal bezweek onder de last tijdens inschrijvingsperiodes, en hun programmazoeker — het belangrijkste conversie-instrument op hun website — had 8+ seconden nodig om zoekresultaten terug te geven. Ze hadden 40.000 actieve studenten, meer dan 200 academische programma's, en zes maanden voordat Drupal 7-beveiligingsondersteuning effectief zou eindigen. Geen druk.

Dit is het verhaal van hoe we het hele project naar Next.js migreerden met een headless CMS-backend, de paginalaadtijden met 73% reduceerden, en het op schema afleverde. Ik zal de architectuurkeuzes delen die we maakten (en de keuzes waarbij we bijna fout zaten), het daadwerkelijke migratieproces, prestatiesbenchmarks, en de lessen die van toepassing zijn op elke grote CMS-migratie.

Inhoudsopgave

Case Study: Migrating a University Portal from Drupal to Next.js

Het Startpunt: Waarmee We Werkten

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

  • ~12.000 content nodes verspreid over programma's, cursussen, faculteitsprofielen, nieuwsartikelen en evenementen
  • 200+ academische programmaapagina's elk met complexe taxonomierelaties (graadniveau, afdeling, faculteit, leveringsformat, accreditatieStatus)
  • Een aangepaste programmazoeker gebouwd als een Drupal Views-gebaseerde zoekopdracht met blootgestelde filters — functioneel maar langzaam
  • Een studentenportaal met geverifieerde toegang tot advieshulpmiddelen, graadaudits, registratiekoppelingen en gepersonaliseerde dashboards
  • 47 aangepaste Drupal-modules, waarvan 19 niet meer werden onderhouden
  • 3 verschillende themalagen gestapeld bovenop elkaar van opeenvolgende herzieningen

De site werd gehost op twee verouderde virtuele machines achter een instellingsloadbalancer. Tijdens piekperioden voor inschrijving (augustus en januari) zou de programmazoeker regelmatig uitvallen. Het marketingteam was gaan vertrouwen op het plaatsen van een PDF-lijst met programma's als backup. Dat zegt alles.

Core Web Vitals waren slecht:

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 Landschap van Belanghebbenden

Webprojecten van universiteiten zijn uniek uitdagend vanwege het aantal belanghebbenden. We werkten samen met:

  • Centrale IT — verantwoordelijk voor SSO-integratie, beveiligingscompliance en hosting
  • Marketing & Communicatie — eigenaar van merk, contentstrategie en analyses
  • Het Registratiebureau — eigenaar van programmagevens en het studenteninformatiesysteem (SIS)
  • Individuele Faculteiten & Afdelingen — elk met hun eigen content-editors (meer dan 80 personen met CMS-toegang)
  • Studentenvertegenwoordiging — die luidkeels pleitte voor mobile-first design (terecht)

Het verkrijgen van afstemming van al deze groepen kostte de eerste drie weken van het project. We voerden een designsprint uit om gedeelde prioriteiten en niet-onderhandelbare zaken vast te stellen.

Waarom Next.js (En Waarom Geen Drupal 10)

De voor de hand liggende vraag: waarom niet gewoon upgraden naar Drupal 10? Het IT-team van de universiteit was eigenlijk zes maanden voordat ze contact met ons opnamen al dat pad ingeslagen. Ze hadden het opgegeven nadat ze ontdekten dat 23 van hun 47 aangepaste modules geen Drupal 10-equivalent hadden en volledig opnieuw geschreven zouden moeten worden.

De echte berekening zag er als volgt uit:

Factor Drupal 10-Migratie Next.js Herbouw
Geschatte tijdslijn 8-10 maanden 6 maanden
Herschrijving van aangepaste modules 23 modules N/A (opnieuw gebouwd als API's/componenten)
Retraining content-editors Matig (nieuwe admin-interface) Matig (nieuw CMS)
Prestatiesledemak Matige verbetering Dramatische verbetering
Hostingflexibiliteit Traditioneel LAMP/vergelijkbaar Edge-implementatie, CDN-first
Werving van ontwikkelaars Krimpen (Drupal-specialisten) Groeien (React/Next.js)
Lange-termijn onderhoudskosten ~$180K/jaar ~$95K/jaar

Het verschil in onderhoudskosten was doorslaggevend voor de administratie. Drupal-ontwikkelaars met institutionele ervaring werden steeds moeilijker te vinden en duurder in onderhoud. 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 speciaal (boven Gatsby, Remix of Astro) om verschillende redenen:

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

Als u vergelijkbare opties weegt, bevat onze Next.js-ontwikkelingspagina de technische specifieke informatie over wat we meestal bouwen.

Architectuurkeuzes

Selectie van Headless CMS

We evalueerden vijf headless CMS-opties tegen de vereisten van de universiteit: 80+ content-editors, complexe content-relaties, op rollen gebaseerde machtigingen en een redelijk prijsmodel per gebruiker.

We kozen Sanity voor dit project. De sleutelfactoren:

  • GROQ-query's handelden de complexe taxonomierelaties tussen programma's, afdelingen en faculteiten veel beter af dan GraphQL voor dit geval
  • Samenwerking in real-time — meerdere editors konden tegelijk werken zonder conflicten
  • Aangepaste invoercomponenten — we bouwden een programmavereiste-mapper rechtstreeks in de studio
  • Prijzen — het Enterprise-plan voor ongeveer $949/maand lag goed binnen budget, en de kosten per gebruiker waren voorspelbaar

Het content modelleren kostte ongeveer twee weken. We definieerden 14 documenttypen en 8 referentietypen. Het programmaschema had alleen al 34 velden, inclusief gestructureerde gegevens voor schema.org EducationalOrganization en Course markup.

Zie onze headless CMS-ontwikkelingspagina voor meer informatie over onze benadering van CMS-architectuur.

Infrastructuur

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

De gegevensstroom ziet er als volgt uit:

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

Statische programmaapagina's worden vooraf gegenereerd op bouwmoment en elk uur opnieuw gevalideerd via ISR. De programmazoeker gebruikt een combinatie van vooraf opgehaalde gegevens (geladen in de client op bouwmoment als JSON-index) en real-time filtering — geen serverronde-trip nodig voor zoekopdrachten.

De API-laag

Het studenteninformatiesysteem (Ellucian Banner, als je het wilt weten — het is altijd Banner) stelde een SOAP-API bloot. Ja, in 2024. We bouwden een vertaalglaag met Next.js API-routes die de SOAP-eindpunten consumeerden en schone REST-eindpunten aan onze frontend blootstelden:

// /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 vertaalglaag was een van de meest waardevole onderdelen van het project. Het ontkoppelde de frontend van de eigenaardigheden van Banner en gaf de universiteit een schone API die ze voor toekomstige projecten konden gebruiken (een mobiele app werd al besproken).

Case Study: Migrating a University Portal from Drupal to Next.js - architecture

De Programmazoeker: Het Kernfeature Herbouwen

De programmazoeker was de belangrijkste pagina op de hele site. Analyses toonden aan dat het 34% van al het organische zoekverkeer opvangen en het #1 instaappunt voor potentiële studenten was. Dit fout doen was geen optie.

De Oude Benadering (En Waarom Het Langzaam Was)

De Drupal-versie gebruikte Views met blootgestelde filters. Elke filterwijziging veroorzaakte een volledige serverronde-trip, waarbij de database opnieuw werd bevraagd en de hele pagina opnieuw werd weergegeven. Met 200+ programma's en 6 taxonomiedimensies (graadniveau, faculteit, afdeling, leveringsformat, interessegebied en trefwoordzoeken), was de query duur.

De Nieuwe Benadering

We bouwden een zoekindex vooraf op bouwmoment. Alle 200+ programma's werden geserialiseerd in een ~180KB JSON-bestand (gecomprimeerd tot ~22KB) dat met de pagina wordt geleverd. Filteren gebeurt volledig aan de client-kant met behulp van een aangepaste hook:

// 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 tekstzoeken en eenvoudig JavaScript-filteren voor facetten. Het resultaat: zoekresultaten verschijnen in onder de 50ms. Geen laadschermen. Geen serveroproepen. Gebruikers kunnen filters zo snel aanslaan als ze willen.

Elk programmareultaat verwijst naar een statisch gegenereerde detailpagina met volledige schema.org markup, wat het verschijningsgebied van de universiteit in door Google gerelateerde onderwijszoekenfeatures dramatisch verbeterde.

Migratie Studentenportaal

Het studentenportaal was het lastigste deel. Het vereiste authenticatie, personalisatie en real-time gegevens uit Banner. We konden er geen van statisch genereren.

Verificatiestroom

De universiteit gebruikt CAS voor single sign-on in alle institutionele systemen. We integreerden CAS met Next.js met behulp van een aangepaste verificatiestroom:

  1. Niet-geverifieerde gebruiker bezoekt /portal → omgeleid naar CAS-login
  2. CAS leidt terug met een serviceticket
  3. Onze API-route valideert het ticket tegen de CAS-server
  4. We maken een ondertekende JWT aan opgeslagen in een httpOnly-cookie
  5. Volgende verzoeken gebruiken de JWT voor sessiebeheer

We gebruikten next-auth (nu Auth.js) met een aangepaste CAS-provider die we volledig zelf schreven, omdat er op dat moment geen onderhouden CAS-provider bestond.

Portaalfuncties

Het studentenportaal bevatte:

  • Gepersonaliseerd dashboard met volgende registratiedatums, wachten en adviseurinformatie
  • Graadaudit-samenvatting real-time opgehaald uit Banner
  • Snelkoppelingen naar het LMS (Canvas), e-mail en bibliotheeksystemen
  • Programmaspecifieke bronnen gebaseerd op de verklaard specialisatie van de student

Alle portaalpagina's gebruiken server-side rendering. We plaatsen Banner API-reacties aggressief in cache (30-seconden TTL voor meeste eindpunten, 5-minuten TTL voor graadaudits) om hun systeem niet te overbelasten.

Content Migratiestrategieën

Het migreren van 12.000 content nodes van Drupal naar Sanity vereiste een systematische benadering. We bouwden een aangepaste migratiepijplijn:

# Vereenvoudigde migratiepijplijn
1. Exporteer Drupal nodes → JSON via aangepaste Drush-opdrachten
2. Transform JSON → Sanity-documentformat via Node.js-scripts
3. Verwerk mediabestanden → upload naar Sanity CDN
4. Importeer documenten → Sanity Migratie-API
5. Valideer → geautomatiseerde controles voor verbroken referenties

De mediamigratie was het meeste vervelende deel. Drupal's bestandsbeheer slaat bestanden op met interne paden en databaseverwijzingen. We schreven een script dat:

  1. Elk bestand uit de Drupal-bestandenmap downloadde
  2. Het uploaddde naar de Sanity-assetpijplijn
  3. Oude Drupal-bestands-id's aan nieuwe Sanity-assetreferenties koppelde
  4. Alle rijke tekstinhoud bijwerkte zodat deze naar de nieuwe assetreferenties verwijst

Dit script liep ongeveer 14 uur op de volledige dataset. We voerden het drie keer uit tijdens het project: eenmaal voor initiële testen, eenmaal in het midden om staging te vernieuwen, en eenmaal voor de uiteindelijke cutover.

Content Freeze Strategie

We implementeerden een tweeefasige content freeze:

  • 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. Editors getraind op nieuw CMS.
  • Week 24: Volledige cutover. Drupal gaat alleen-lezen, daarna offline.

De dubbele-invoerperiode was pijnlijk maar nodig. We hadden 80+ editors en zij moesten spiergeheugen opbouwen met Sanity voordat het hun enige optie was.

De 6-Maanden Tijdslijn

Maand Fase Belangrijkste Resultaten
Maand 1 Ontdekking & Architectuur Afstemming belanghebbenden, CMS-selectie, infrastructuuropstelling, content-modellering
Maand 2 Kerneontwikkeling Designsysteem, paginasjablonen, programmadetailpagina's, navigatie
Maand 3 Programmazoeker & Zoeken Zoekindex, filterinterface, programmaatapijplijn, SEO-markup
Maand 4 Studentenportaal CAS-integratie, Banner API-laag, dashboard, graadaudit-weergave
Maand 5 Content-migratie & Training Migratiescripts, editor-training (6 sessies), staging QA
Maand 6 QA, Prestaties, Lancering Belastingstesting, toegankelijkheidaudit, content freeze, DNS cutover

Ons team bestond uit 4 ontwikkelaars, 1 designer en 1 projectmanager. De universiteit stelde een toegewijde product owner plus een IT-liaison ter beschikking voor het integratiewerk van Banner/CAS.

We liepen twee grote obstakels tegen:

  1. Maand 3: Banner's SOAP-API had een ongedocumenteerde snelheidslimiet van 100 verzoeken/minuut. Onze programmazoeker was ontworpen om alle programmagevens bij bouwmoment in batch op te halen. We moesten een queuing-systeem implementeren en het bouwwerk over meerdere batches spreiden.

  2. Maand 5: De toegankelijkheidaudit vond 34 WCAG 2.1 AA-schendingen. De meeste waren overgeërfd uit het ontwerp (onvoldoende kleurcontrast op secundaire knoppen, ontbrekende focusindicatoren op de programmazoekerfilters). We brachten een onvoorziene 8 dagen aan remediation door.

Prestatieresultaten

Hier zijn de getallen na lancering:

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
Buildtijd (volledig) N/A 4m 12s —
Maandelijkse hostingkosten ~$2.400 ~$1.100 54% lager

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

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

Lessen Geleerd

1. Start CAS/SSO-integratie Vroeg

We planieden de CAS-integratie voor Maand 4. We hadden een proof of concept in Maand 1 moeten starten. Universiteit IT-teams bewegen voorzichtig (lees: langzaam) door beveiligingsbeoordelingen. Het goedkeuren van de SSO-architectuur kostte drie weken heen-en-weer met hun veiligheidskantoor.

2. Content-modellering Is Architectuur

We brachten twee volledige weken door aan content-modellering voordat we enige frontend-code schreven. Dit voelde op dat moment langzaam. Het was de beste investering die we maakten. Wanneer u 200+ programma's met complexe relaties tussen afdelingen, faculteiten, graadniveaus, concentraties en leveringsformaten hebt, bespaart u zich honderden uren refactoring door de schema vanaf het begin correct te krijgen.

3. Train Editors Vroeg, Niet Alleen Voor Lancering

We planieden editor-training aanvankelijk voor Maand 5. We verplaatsten het naar Maand 4 na feedback van de product owner. Dit gaf editors zes weken om vertrouwd te raken met Sanity in plaats van twee. De kwaliteit van inhoud die tijdens de dubbele-invoerperiode werd ingevoerd was dramatisch beter vanwege dit.

4. Banner Is Banner

Als u met Ellucian Banner werkt (en in het hoger onderwijs waarschijnlijk wel), reserveer extra tijd voor de API-integratie. De documentatie is schaars, de SOAP-eindpunten zijn inconsistent, en elke instelling heeft haar Banner-instantie anders aangepast. Onze vertaalglaag was essentieel.

5. Budget voor Toegankelijkheid Van Dag Één

Onze 34 WCAG-schendingen in Maand 5 waren bijna volledig preventief. We voeren nu axe-core-controles in onze CI-pijplijn uit op elke pull-aanvraag. Als u een openbare universiteit bouwt, is WCAG 2.1 AA-compliance niet optioneel — het is een wettelijke vereiste onder Sectie 508.

Als u zich in een soortgelijke migratieuitdaging bevindt, helpen we u graag de specifieke onderdelen door. U kunt rechtstreeks contact met ons opnemen of onze prijzenpagina raadplegen voor hoe we deze projecten doorgaans bepalen.

Veelgestelde Vragen

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

Welk headless CMS is het beste voor websites van het hoger onderwijs? Het hangt af van de grootte en technische comfortabel van uw redactioneel team. We kozen Sanity voor dit project vanwege de samenwerking in real-time, flexibele content-modellering en GROQ-querytaal. Contentful en Storyblok zijn ook sterke opties. Voor universiteiten met zeer grote content-teams (100+ editors) kunnen het workflow- en machtigingsmodel van Contentful voordelig zijn. Voor kleinere teams die meer aanpassing willen, wint Sanity doorgaans.

Kan Next.js geverifieerde studentenportalen hanteren? 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 bloot te stellen aan de client-bundel. We integreerden met CAS (Central Authentication Service) met 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 content-migratie, CMS-instelling en training — ligt doorgaans tussen $250.000 en $450.000 afhankelijk van complexiteit. De langetermijnbesparen zijn echter aanzienlijk. Deze universiteit reduceerde haar jaarlijkse onderhoudskosten van ongeveer $180K naar $95K, wat betekent dat het project zichzelf in 3-4 jaar terugbetaalt, zelfs op het hogere uiteinde van het budgetbereik.

Wat gebeurt er met SEO tijdens een grootschalige CMS-migratie? Dit is een legitieme bezorgdheid. We implementeerden een uitgebreide omleidingskaart (meer dan 2.400 301-omleidingen), behielden waar mogelijk alle bestaande URL-structuren, en voegde schema.org-gestructureerde gegevens toe die de Drupal-site miste. Het organische verkeer daalde ongeveer 8% in de eerste twee weken na lancering (normaal voor elke grote migratie), herstelde zich vervolgens en overschreed de baseline met 43% binnen vier maanden.

Is Drupal 10 een betere keuze dan zonder kop gaan voor universiteiten? Het kan zijn, afhankelijk van de situatie. Als uw team sterke Drupal-expertise heeft, uw aangepaste modules Drupal 10-compatibiliteit hebben, en u niet de prestatiekenmerken van een statische/hybride site nodig hebt, is Drupal 10 een perfect geldig pad. In ons geval had de universiteit zijn Drupal-expertise verloren, had het 23 incompatibele modules, en had het dramatische prestatieverbeteringen nodig. De headless-benadering was duidelijk de betere pasvorm.

Hoe gaat u om met content-migratie van Drupal naar een headless CMS? We gebruiken aangepaste Node.js-scripts die Drupal-inhoud via Drush-opdrachten exporteren, de gegevens transformeren om te matchen met het schema van het nieuwe CMS, bestandsmigratiebestanden afhandelen en alles importeren via de migratie-API van het CMS. Het proces wordt doorgaans 3 keer uitgevoerd: eenmaal voor initiële testen, eenmaal voor staging-vernieuwing en eenmaal voor uiteindelijke cutover. Rijke tekstinhoud met ingesloten media is het lastigste — u moet elke interne bestandsverwijzing opnieuw toewijzen.

Kunt u Drupal en Next.js gelijktijdig uitvoeren tijdens migratie? Ja, en we raden het aan. Tijdens onze migratie bleef Drupal de productiesite bedienen terwijl we de Next.js-versie op een stagingdomein bouwden en testten. We gebruikten een drieweeks dubbele-invoerperiode waarin inhoud in beide systemen werd ingevoerd. De uiteindelijke cutover was een DNS-schakelaar die ongeveer 15 minuten kostte, met Drupal als alleen-lezen gehouden gedurende 30 dagen als terugval.