Drupal 10 slutt på støtte 9. desember 2026: oppgradere til 11 eller migrere?

Drupal 10 når slutten av levetiden 9. desember 2026, seks uker etter at denne artikkelen ble publisert. Drupal 12 kommer samme uke. Kjører nettstedet ditt på Drupal 10, har du i praksis tre valg: oppgradere til Drupal 11 nå og planlegge 12 senere, kjøpe deg tid med en minimal oppgradering, eller flytte til en annen plattform. Jeg utvikler og drifter nettsteder både i Drupal og i WordPress, så her får du begge retningene. Ofte er det riktig å bli på Drupal; unntakene er stort sett små nettsteder med få redaktører.

Artikkelen bygger på drupal.org og Lovdata slik de så ut 28. oktober 2026. Datoene i utgivelsesplanen for Drupal kan endres, så sjekk kildene før du binder et budsjett.

#Drupal 10 end of life: hva er datoen?

Utgivelsesplanen på drupal.org sier det rett ut: Drupal 10 når slutten av levetiden 9. desember 2026, og det kommer ingen nye utgivelser av Drupal 10 etter den datoen. Drupal 10.6.0 er den siste mindre versjonen i 10-serien. Drupal 12 er planlagt i uken som starter 7. desember 2026.

Vinduet har allerede krympet. Da Drupal 11.4.0 kom i uken fra 29. juni 2026, sluttet sikkerhetsstøtten for 11.2.x og 10.5.x. Nå er det bare 11.4.x, 11.3.x og 10.6.x som får sikkerhetsrettelser. De siste utgivelsene i hver gren kom 21. oktober 2026, ifølge utgivelsesstrømmen for kjernen: Drupal 10.6.20, 11.4.11 og 11.3.20.

Rytmen følger en fast regel. Ifølge oversikten over utgivelsesprosessen kommer en ny hovedversjon hvert annet år og nye mindre versjoner i juni og desember. Hver hovedversjon støttes i minst fire år, til to nye hovedversjoner er utgitt. Drupal.org har ikke publisert noen fast sluttdato for Drupal 11, så jeg oppgir ingen dato for den.

#Hva skjer med et Drupal 10-nettsted etter fristen?

Nettstedet fortsetter å virke etter 9. desember, men kjernen får ikke lenger sikkerhets- og feilrettinger. Drupal-prosjektets sikkerhetsteam skriver at bare støttede versjoner av Drupal får hjelp fra teamet, og ber deg oppgradere hvis du bruker en versjon uten støtte.

For en nettstedseier betyr det tre ting i praksis:

1. Når en sårbarhet i kjernen blir kjent etter desember, peker varselet på rettede utgivelser av Drupal 11 og 12. Det kommer ingen Drupal 10-utgivelse å installere.
2. Bidragsmodulene følger kjernen. Når vedlikeholderne fjerner Drupal 10 fra versjonskravene, blir nettstedet ditt stående på eldre modulversjoner, også eldre sikkerhetsrettelser.
3. Revisjoner, spørreskjemaer fra forsikringsselskaper og leverandørkrav spør ofte om publiseringsløsningen har støtte. Svaret blir nei.

Har nettstedet innlogging, betaling eller personopplysninger, regner jeg desember som en absolutt frist. Et enkelt informasjonsnettsted uten skjemaer har lavere risiko, men modulproblemet i punkt 2 vokser hver måned.

#Drupal 10 til 11 eller WordPress: hva passer ditt nettsted?

De fleste Drupal-nettstedene jeg ser, bør oppgraderes. Drupal er sterkt der WordPress trenger utvidelser og egen kode: detaljerte roller og tilganger, redaksjonell godkjenningsflyt, strukturert innhold med referanser mellom enheter, flere nettsteder på én kodebase og flerspråklig innhold i kjernen. Å bygge alt dette på nytt et annet sted koster som regel mer enn oppgraderingen.

Overgang lønner seg når nettstedet ikke lenger trenger det Drupal ble valgt for, eller aldri gjorde det. Dette er tabellen jeg bruker i første samtale.

Vil du ha et bredere bilde før du bestemmer deg, sammenligner jeg Drupal med WordPress, TYPO3 og hodeløse løsninger i oversikten over beste CMS for store bedriftsnettsider. Skal nettstedet bli på Drupal, viser siden om Drupal-utvikling hvordan jeg tar på meg en oppgradering: først en gjennomgang av kopien, deretter en fast plan.

#Drupal 10 til 11 oppgradering steg for steg

Den offisielle veiledningen, How to upgrade from Drupal 10 to Drupal 11, lister forutsetningene: nettstedet må kjøre Drupal 10.3.0 eller nyere, serveren trenger PHP 8.3.0 eller nyere, og du trenger kommandolinje med Composer og Drush. Under er rekkefølgen jeg følger. Ingenting av dette gjøres i produksjon.

#Steg 1: lag en arbeidskopi

Jeg kopierer kode, database og filmappen til en testserver med samme webserver og database som produksjon. Alle de neste stegene skjer på kopien. Bruker nettstedet konfigurasjonsstyring, sjekker jeg først at eksportert konfigurasjon stemmer med databasen. Avvik som dukker opp midt i en oppgradering, er vanskelige å skille fra oppgraderingsfeil.

#Steg 2: oppdater til siste Drupal 10

Jeg tar kjernen til siste 10.6-utgivelse og oppdaterer hver bidragsmodul til nyeste versjon som støtter Drupal 10. Mange moduler har en utgivelse som støtter både 10 og 11. Installerer du den på Drupal 10 først, forsvinner en stor del av arbeidet senere.

#Steg 3: sjekk serveren mot kravene til Drupal 11

Drupal 11 krever mer enn PHP 8.3. Databasekravene er MySQL 8.0+, MariaDB 10.6+, PostgreSQL 16+ eller SQLite 3.45+. For webserveren krever drupal.org Apache 2.4.7 eller nyere eller Nginx 1.1 eller nyere, og Drupal 11.0.0 støtter ikke lenger Microsoft IIS. Gamle webhotellavtaler og Windows-servere i kommunale driftsmiljøer dukker opp oftere enn mange tror, så dette sjekker jeg først.

#Steg 4: kjør Upgrade Status

Upgrade Status er en bidragsmodul som vurderer hvor klart miljøet og komponentene er for en ny hovedversjon. Jeg installerer den på Drupal 10-kopien, skanner alle bidragsmoduler og egne moduler og lagrer rapporten. Den viser hvilke moduler som har en Drupal 11-utgivelse, hvilke som må oppdateres, og hvilken egen kode som bruker avviklede API-er.

#Steg 5: rett egen kode med Drupal Rector og drupal-check

Drupal Rector retter avviklet Drupal-kode automatisk, og README-filen oppgir dekning av avviklinger fra Drupal 10.0 til 11.4. Jeg kjører den på egne moduler og temaer, leser gjennom hver endring og lagrer i små steg. Deretter kjører jeg drupal-check, et verktøy for statisk analyse bygget på PHPStan, for å finne det Rector ikke klarer å skrive om selv. Veiledningen på drupal.org nevner Rector og Upgrade Status; drupal-check er mitt eget tillegg.

#Steg 6: erstatt moduler som er fjernet fra kjernen

Seks moduler forsvant fra kjernen i Drupal 11. Les mer i neste del. Bruker nettstedet noen av dem, legger jeg inn bidragsversjonen med Composer mens nettstedet fortsatt står på Drupal 10, slik at bytte av kjerne ikke fjerner en modul som holder data.

#Steg 7: løs opp bidragsmoduler som bare mangler versjonskrav

Av og til fungerer en bidragsmodul på Drupal 11, men vedlikeholderen har ikke merket en ny utgivelse. Composer Drupal Lenient lar deg installere Drupal-utvidelser selv om de ikke er merket som kompatible med installert drupal/core. Den skriver om kjernekravet for pakker du lister i extra.drupal-lenient.allowed-list. Jeg legger til én pakke om gangen, bruker kompatibilitetspatchen fra modulens saksliste og skriver i depotet hvorfor hver oppføring finnes. Den offisielle veiledningen nevner denne veien for moduler som trenger patcher.

#Steg 8: bytt kjerne og test

Når Upgrade Status er grønn, krever jeg Drupal 11 med Composer, kjører databaseoppdateringer med Drush, eksporterer konfigurasjon og kjører testene. Så tester redaktørene kopien: opprette og endre innhold, laste opp medier, menyer, skjemaer, søk og hvert trinn i godkjenningsflyten. Først når de har godkjent, planlegger jeg produksjonssettingen.

#Hvilke kjernemoduler forsvant i Drupal 11?

Seks moduler ble fjernet fra kjernen med Drupal 11.0. Alle finnes videre som bidragsprosjekter, ifølge oversikten over avviklede og utgåtte moduler.

Samme side minner om at integrasjonen med CKEditor 4 allerede ble fjernet fra kjernen i Drupal 10, og at CKEditor 4 ikke lenger har støtte. Ligger det gammel CKEditor 4-konfigurasjon igjen, må overgangen til CKEditor 5 gjøres ferdig før du går videre.

#Drupal 12 og PHP 8.5: hva bør du planlegge nå?

Drupal 12.0 hever kravene til serveren kraftig. Tabellen over PHP-krav viser PHP 8.5 som eneste støttede versjon for Drupal 12.0, og PHP bør fra 12.0 være kompilert med argon2-støtte for passordhashing. Minstekravene til databasen blir MariaDB 10.11+, MySQL 8.0+ eller PostgreSQL 18+. Drupal 11.3 og nyere kjører allerede på PHP 8.5. Den praktiske veien er derfor å komme over på Drupal 11 og så bytte serveren til PHP 8.5 mens du fortsatt står på 11.

Neste runde med fjerninger er også kunngjort. Ban, Contact, Field Layout, History, Telephone, Search, Settings Tray og Shortcut er avviklet i 11.x og fjernes i 12.0. Verktøylinjen (Toolbar) er fjernet fra kjernen i 12.0.0. Administrasjonstemaet Claro og frontendtemaet Olivero er avviklet i 11.5.0 og fjernes i 12.0.0, og drupal.org anbefaler å planlegge for det nye Default Admin-temaet. Begge temaene finnes videre som bidragstemaer. Er temaet ditt bygget som undertema av Olivero, ville jeg satt det på listen for 2027 allerede nå.

Du kan ikke hoppe over en hovedversjon. Upgrade Status kjøres på Drupal 10 for å forberede 11, og på Drupal 11 for å forberede 12. Et Drupal 10-nettsted går altså til 11 først uansett.

#Drupal 7 i 2026: siste vei via Drupal 11

Drupal 7 står dårligere enn Drupal 10. Siden om Drupal 7 end of life slår fast at sikkerhetsstøtten for Drupal 7 sluttet 5. januar 2025. Siden da får du sikkerhetsrettelser bare gjennom en betalt partner for utvidet støtte, og drupal.org oppgir HeroDevs og Tag1 Consulting på partnerlisten.

Det største problemet er migreringsveien. Et Drupal 7-nettsted oppgraderes ikke på stedet; innholdet flyttes inn i en ny installasjon med modulen Migrate Drupal. Ifølge oversikten over avviklede moduler ble Migrate Drupal UI avviklet i Drupal 11.3.0, og Migrate Drupal er avviklet i 11.x-serien. Begge fjernes i Drupal 12.0, og ingen av dem flyttes til et bidragsprosjekt. Saken om å fjerne Migrate Drupal er lukket som løst.

Slik jeg leser dette: vil du bruke kjerneverktøyene for migrering fra Drupal 7, må migreringen kjøres på Drupal 11. Når Drupal 12 er eneste valg, er kildene for Drupal 6 og 7 borte fra kjernen, og da trengs egen migreringskode. For et Drupal 7-nettsted er valget mellom moderne Drupal og WordPress derfor reelt, fordi begge veier betyr nytt tema og innholdsmigrering.

#Utvidet støtte for Drupal 10: finnes det?

Jeg har ikke funnet noe bekreftet tilbud. Per 28. oktober 2026 oppgir drupal.org partnere for utvidet støtte bare for Drupal 7. HeroDevs sin side om Drupal beskriver erstatninger for Drupal 7.x og nevner ikke Drupal 10. Tag1 sin Drupal-side ga tilgangsfeil da jeg sjekket, så jeg kan ikke si hva de tilbyr.

Å kjøpe tid betyr derfor noe annet for et Drupal 10-nettsted. Jeg gjør den minste oppgraderingen som får nettstedet over på Drupal 11 med støtte: erstatninger for fjernede kjernemoduler, bidragsmoduler på Drupal 11-utgivelser, Lenient-pluginen for de få modulene som venter på en merket utgivelse, og Rector-rettelser i egen kode. Nytt design, nye funksjoner og forberedelsen til Drupal 12 venter til etter desember. Da kommer sikkerhetsrettelsene fortsatt, og de store beslutningene flyttes til neste budsjettår.

#Feil ved oppgradering til Drupal 11 og hvordan jeg løser dem

Dette er problemene jeg oftest finner i Drupal 10-nettsteder, og hva jeg gjør med dem.

#Fra Drupal til WordPress: hva blir med, og hva bygges på nytt?

Når WordPress er riktig valg, er flyttingen av innholdet den enkle delen. Det vanlige verktøyet er utvidelsen FG Drupal to WordPress. Siden på wordpress.org oppgir at den er testet med Drupal 4 til 11 og nyeste WordPress, og da jeg skrev dette var den i versjon 3.95.7 med over 700 aktive installasjoner.

Gratisversjonen flytter ifølge utvidelsessiden artikler, enkle sider, kategorier, stikkord og bilder, retter interne lenker og fungerer med Drupal-databaser i MySQL, PostgreSQL og SQLite. Premiumversjonen legger til kommentarer, brukere, egne innholdstyper, egne taksonomier, egne felt, navigasjonsmenyer, Drupal-medier, omdirigering fra gamle Drupal-adresser til nye WordPress-adresser og import fra WP-CLI. WP-CLI har selv ingen Drupal-import; kommandoen wp import leser bare WXR-filer.

Dette flytter ingen importør for deg, etter min erfaring:

• Views. Lister, filtre, søkeskjemaer og RSS-strømmer bygget i Views blir maler, spørringer eller blokkmønstre i WordPress, bygget for hånd.
• Roller og tilganger. Tilgangsmatrisen i Drupal har ingen direkte motpart; jeg kobler hver rolle til roller og rettigheter i WordPress og tester med ekte redaktørkontoer.
• Godkjenningsflyt. Tilstander og overganger fra Content Moderation trenger en utvidelse eller egen kode i WordPress.
• Flerspråklig innhold. Drupal lagrer oversettelser i kjernen; i WordPress avhenger strukturen av hvilken språkutvidelse du velger, og importen må planlegges etter den.
• Paragraphs og oppsett. Strukturerte sideseksjoner blir som regel blokker, og utformingen av blokkene er nytt arbeid.

På WordPress-siden er anbefalte krav til server PHP 8.3 eller nyere, MariaDB 10.11 eller MySQL 8.0 eller nyere, og HTTPS. Jeg har skrevet en egen veiledning om å migrere TYPO3 til WordPress, og det meste om innholdsmodell og opplæring av redaktører der gjelder også for Drupal. Vil du gå gjennom ditt eget nettsted strukturert, stiller vurderingen av WordPress-migrering de samme spørsmålene som jeg stiller i en første samtale.

Til sammenligning: ifølge W3Techs, per 28. oktober 2026, kjører WordPress 39,5 % av alle nettsteder (58,3 % av nettstedene med kjent publiseringsløsning), og Drupal 0,6 % (0,9 % av markedet). Forskjellen påvirker først og fremst hvor mange utviklere og byråer du kan velge mellom.

#Kommuner og offentlige virksomheter: universell utforming og anskaffelse

Kommuner, fylkeskommuner, statlige etater og høyskoler er typiske Drupal-brukere. I Norge gjelder forskrift om universell utforming av IKT-løsninger (FOR-2013-06-21-732), sist endret 1. februar 2023. Forskriften gjelder også private virksomheter. Etter § 4 skal private virksomheters nettløsninger minst følge WCAG 2.0 på nivå A og AA, med noen unntak for tidsbaserte medier. Etter § 4b oppfyller offentlige virksomheter kravet når nettløsningene samsvarer med EN 301 549 V3.2.1, og offentlige virksomheter skal også ha tilgjengelighetserklæring og tilbakemeldingsfunksjon etter § 4e.

Forskriften viser til direktiv (EU) 2016/2102 om tilgjengelighet på offentlige nettsteder gjennom EØS-avtalen. I EU gjelder i tillegg tilgjengelighetsdirektivet, direktiv (EU) 2019/882, for enkelte forbrukertjenester som ytes etter 28. juni 2025, blant annet netthandel og banktjenester. Den norske forskriften viser ikke til dette direktivet i sine EØS-henvisninger.

En publiseringsløsning uten støtte og en utdatert tilgjengelighetserklæring dukker gjerne opp i samme tilsyn. Oppgraderingen er også et godt tidspunkt å teste på nytt. Drupal 12 erstatter Claro med et nytt Default Admin-tema og fjerner Olivero fra kjernen, så tilpasninger gjort for tilgjengelighet i disse temaene må sjekkes igjen etter byttet. På siden om nettsider for offentlige etater beskriver jeg hvordan jeg tester universell utforming for offentlige nettsteder.

Om anskaffelse: en kommune kan sjelden bestille en oppgradering på telefon. Krever rammeavtalen et nytt avrop eller en konkurranse med eget konkurransegrunnlag, er seks uker før 9. desember kort tid. Jeg ville kjørt den minimale Drupal 11-oppgraderingen gjennom den raskeste veien den eksisterende vedlikeholdsavtalen tillater, og beskrevet det større arbeidet, Drupal 12 eller migrering, som en egen anskaffelse for neste budsjettår.

#Sjekkliste: denne uken og denne måneden

Denne uken:

• Noter nøyaktig Drupal-versjon fra statusrapporten eller med composer show drupal/core.
• Be driftsleverandøren skriftlig om hvilke PHP- og databaseversjoner avtalen gir, og om PHP 8.3 er tilgjengelig i dag.
• Lag en liste over bidragsmoduler og temaer, og merk egen kode.
• Sjekk om Book, Forum, Statistics, Tour, Actions UI eller Activity Tracker er slått på.
• Finn ut hvem som godkjenner utgiften, og om oppgraderingen passer inn i dagens vedlikeholdsavtale.

Denne måneden:

• Sett opp en testkopi og kjør Upgrade Status på den.
• Oppdater til siste Drupal 10.6-utgivelse og nyeste bidragsmoduler som støtter Drupal 10.
• Kjør Drupal Rector og drupal-check på egen kode.
• Velg vei: oppgradering, minimal oppgradering nå og mer arbeid senere, eller migrering.
• Sett av tid til at redaktørene tester kopien før 9. desember.
• For offentlige virksomheter: planlegg ny test av universell utforming og oppdater tilgjengelighetserklæringen etter produksjonssettingen.

Vil du heller overlate dette, send meg svarene fra den første listen via siden om Drupal-utvikling, så svarer jeg med en oppgraderingsplan for ditt nettsted. Vurderer du WordPress, forklarer siden om WordPress-utvikler hvordan jeg tar på meg migreringer.