Två datum och tre alternativ
Den ordinarie supporten för Umbraco 13 upphör den 14 december 2026 – 90 dagar från den dag den här texten publicerades.
Texten vänder sig till den som äger beslutet om en Umbraco 13-webbplats: tekniskt ansvarig, eller den som godkänner budgeten. Den förutsätter att ni redan vet vad End of Life innebär. Om inte finns den delen beskriven här.
Här går vi igenom de två datum som ramar in beslutet, tre frågor att inleda en kartläggning med, och tre alternativ – åtskilda av om arbetet ryms inom den tid ni har kvar.
Två datum, inte ett
Det mesta som skrivs om det här behandlar den 14 december som datumet. Det finns två, och de får olika konsekvenser.
10 november 2026 – supporten för .NET 8 upphör. Umbraco 13 kör på .NET 8. När Microsofts support tar slut slutar plattformen under CMS:et att få rättningar, en månad före Umbracos eget datum.
14 december 2026 – supporten för Umbraco 13 upphör. Inga fler säkerhetsuppdateringar för själva CMS:et.
Hur mycket tid ni faktiskt har
Nittio kalenderdagar är ungefär tretton arbetsveckor, och ni kommer inte att få tretton. Tre saker äter veckor i båda ändar innan en enda rad kod är skriven.
Marginal för driftsättning. "Live före deadline" och "driftsatt på deadline" är två olika planer. Lämna utrymme för det som visar sig efter lansering.
Budgetbeslut. Är arbetet oplanerat startar den klockan före utvecklingsklockan.
Er egen releasekalender. Har organisationen ett driftstopp kring årsskiftet tidigarelägger det er sista möjliga driftsättning med hela sin längd. Värt fem minuters kontroll i stället för ett antagande åt något håll.
Dra bort det från tretton veckor, så har ni er tidsram. Det är den siffran – inte nittio dagar – som resten av beslutet vilar på.
Skriv ner vilket datum tidsramen slutar vid, och varför. Det är den mest användbara raden i hela planen, eftersom vart och ett av alternativen nedan väljs genom att ställa det kartlagda arbetet mot just den.
Tre frågor att inleda kartläggningen med
De här tre storleksbedömer inte projektet. De visar vad som behöver kartläggas ordentligt och lyfter fram de uppenbara hindren tidigt – skillnaden mellan ett möte och en riktig inventering, som tar ungefär en eftermiddag.
Besvara dem mot själva lösningen, inte ur minnet.
Vilka tredjepartspaket finns i lösningen, och vilka har en v17-release? Varje paket utan release tvingar fram ett beslut – ersätta, forka, eller ta bort funktionen – och de besluten för med sig eget arbete.
Finns det egna backoffice-anpassningar? Property editors, dashboards, egna träd, content apps. Det som är byggt i AngularJS följer inte med: backoffice byggdes om i v14 och det finns inget kompatibilitetslager för den gamla modellen, så det arbetet är en omskrivning.
Hur mycket äldre innehållsarkitektur ligger i era content types? Nested Content, gamla Grid, macros, XPath-baserade pickers, den gamla Media Pickern. Var och en har en migreringsväg, och kostnaden beror på hur mycket innehåll som ligger bakom den och hur innehållet renderas och kontrolleras efteråt.
Hela checklistan för uppgraderingen finns i Uppgradera Umbraco 13 till 17: vad som faktiskt går sönder.
Det som kommer ut är en uppskattning av arbetsinsatsen. Ställd mot tidsramen ni räknade fram är det den uppskattningen som avgör alternativet.
En ombyggnad behöver inte börja från noll
Jag har utvecklat KindbergCo Platform som en återanvändbar grund för Umbraco-projekt. Plattformen samlar innehållsblock, redaktionella verktyg och inbyggt stöd för prestanda, tillgänglighet, SEO och flerspråkigt innehåll. Den är byggd utifrån beprövade metoder och praktisk erfarenhet från verkliga projekt, och driver även min egen webbplats.
Där plattformen matchar era krav minskar den arbetsinsatsen som krävs för en ombyggnad. Därmed kan en större del av budgeten läggas på innehåll, integrationer och specifika affärsbehov.
Detta är värt att väga in i jämförelsen: ställ en uppgradering mot en ombyggnad baserad på denna plattformen, där både innehållsmigrering och projektspecifik utveckling har räknats in i båda kostnadsuppskattningarna.
Alternativ 1: uppgradera före supportslutet
Förutsättning: det kartlagda arbetet ryms inom tidsramen, inklusive test och marginal.
Ta uppgraderingen stegvis i stället för i ett hopp – 13 till 14 till 15 till 16 till 17, med en fungerande och testad build i varje steg. Det tar längre tid än ett enda hopp och det förvandlar "något gick sönder någonstans över fem major-versioner" till ett fel ni kan lokalisera.
Räkna in ledtiden hos den som ska utföra arbetet när ni bedömer om det ryms. Ska uppgraderingen till ett externt team är deras tillgänglighet en del av tidsramen, inte något vid sidan av.
Alternativ 2: planera uppgraderingen och köp tillfällig support
Förutsättning: uppgraderingen är genomförbar, men ryms inte inom tidsramen.
Bestäm uppgraderingsdatumet först och köp sedan support som täcker glappet – i den ordningen, så att täckningen dimensioneras av en plan i stället för att planen formas av den täckning ni råkade köpa.
Vad XLTS omfattar. Umbraco anger perioder om 6, 12 och 24 månader, enbart säkerhetsuppdateringar, med start dagen efter den 14 december och krav på att perioderna löper sammanhängande.
Vad som inte publiceras. Pris och eventuell sista beställningsdag. Stäm av båda direkt med Umbraco, och gör det i tid nog att svaret fortfarande kan ändra er plan.
Vad det inte löser. Luckan kring .NET 8 står öppen under hela perioden. Skriv ut det i en säkerhets- eller leverantörsgranskning i stället för att låta det upptäckas där.
Kostnadsjämförelsen mellan förlängd support och uppgradering finns i Umbraco 13 XLTS eller uppgradering.
Alternativ 3: jämför en ombyggnad med uppgraderingen
Förutsättning: förändringarna som krävs är så omfattande att det är värt kartläggningsarbetet att jämföra migrering med ombyggnad.
Det här alternativet är en jämförelse, inte ett beslut. Ni kostnadsbedömer uppgraderingen och ombyggnaden mot samma krav och väg kostnader och förbättringar. Tre saker tenderar att starkt påverka denna kalkyl är:
Backoffice-anpassningar som ändå måste skrivas om. Ska AngularJS-editorer byggas om oavsett, öppnas frågan om vad mer som kan ändras i samma veva.
En innehållsmodell som redan görs om. Ändras era content types av redaktionella skäl och inte bara tekniska konkurrerar migreringen och omarbetningen om samma arbete.
Paket utan v17-väg och utan direkt ersättare. Att ersätta en central funktion är ett byggprojekt oavsett vilken väg ni väljer.
En sak som inte i sig motiverar en ombyggnad: omfattande integrationer. Ett affärssystem, ett PIM och en e-handelsplattform kopplade till CMS:et innebär oftast mer samordning, fler miljöer och mer regressionstest – vilket förlänger uppgraderingen snarare än underkänner den.
En ombyggnad hinner inte bli klar före december, så det här alternativet kräver tillfällig support också. Själva jämförelsen är värd att göra tidigt: den är underlaget till 2027 års budget oavsett hur det slutar.
Umbraco 18 finns ute, men 17 är målet
Umbraco 18 släpptes den 25 juni 2026 och är därmed den senaste versionen på listan när ni tittar. Det är en Standard-term Support-release: fas med enbart säkerhetsuppdateringar (säkerhetsfasen) från den 25 mars 2027 och supportslut den 25 juni 2027.
Umbraco 17 är Long-term Support-versionen. Säkerhetsfasen från den 27 november 2027 och supportslut den 27 november 2028 – sjutton månader senare än 18.
Att gå från 13 till 18 köper alltså ungefär nio månader innan samma beslut kommer tillbaka. Är skälet till flytten att supporten tog slut: flytta till den version som har mest support kvar framför sig. Umbraco 18 är rätt mål om ni specifikt behöver något som finns där och inte i 17; annars är destinationen 17.
Det här ska vara nedskrivet den här veckan
Paketinventeringen, med v17-status för varje rad.
Tidsramen: vilket datum den räknas bakåt från, vilket av de två datumen den siktar på, och vad som dragits bort på vägen.
Alternativet, skriftligt överenskommet med den som äger budgeten såväl som den som äger koden.
Om alternativ 2 eller 3: frågorna om pris och sista beställningsdag ställda till Umbraco.
En rad i 2027 års budget. Att skjuta upp beslutet flyttar kostnaden; det tar inte bort den.
Att köra programvara utan support kan vara en försvarbar hållning när den är dokumenterad, riskbedömd och har ett datum kopplat till åtgärden. Hållningen som är svår att försvara i en säkerhetsgranskning eller en leverantörsbedömning är att inte ha något svar. Skillnaden mellan de två är ett beslut någon fattade med avsikt.
Vill ni ha kartläggningen gjord mot er faktiska lösning är det vad en uppgraderingsanalys är: en inventering paket för paket, identifierade anpassningar och hinder i backoffice och innehållsmodellen, och ett rekommenderat alternativ med en uppskattning av arbetsinsatsen – skriftligt, så att det kan gå direkt till den som håller i budgeten.
Versions- och supportdatum kontrollerade mot Umbracos dokumentation för LTS och End-of-Life samt Microsofts supportpolicy för .NET den 15 september 2026. XLTS-priser och köpvillkor publiceras inte fullt ut och ändras över tid – stäm av aktuella villkor med Umbraco innan ni förlitar er på dem.