Optimizely CMS 11 er ude af support — og det svære ved opgraderingen er ikke selve CMS'et

Jeg har arbejdet på mange Optimizely-opgraderinger gennem årene — fra EPiServer-tiden, gennem version 7-skiftet, ind i CMS 11-æraen, og nu et godt stykke inde i 12 og 13. De fleste går fint. Ingen af dem går hurtigt.

Så når en kunde spørger “hvor svært kan en CMS 11 til 13-opgradering egentlig være — det er stadig Optimizely, ikke?”, har jeg et lidt resigneret svar klar.

Selve CMS’et er ikke der, timerne ligger. Det er alt det, I har bygget omkring CMS’et, der tager tiden.

Hvad der ændrede sig i april 2026

Optimizely supporterer de to nyeste major-versioner af CMS. CMS 13 nåede general availability 31. marts 2026, og den 10. april 2026 annoncerede Optimizely formelt, at CMS 11 var ude af support. Det er ikke en diskretionær beslutning — det er policyen, der gør det, den altid gør, når en ny major lander: CMS 12 bliver i vinduet, CMS 11 ryger ud.

Supportophør betyder ingen flere fejlrettelser, ingen flere sikkerhedsopdateringer, ingen flere kompatibilitetsopdateringer mens resten af .NET-økosystemet bevæger sig videre. Jeres site kører videre, men ingen vedligeholder fundamentet længere.

Der er ingen håndhævet udløbsdato. Optimizely lukker ikke jeres installation ned. Men hver måned efter april skubber mere af stakken ud af leverandørens dækning: hosting, dependencies, integrationer. Næste år vedligeholder I et system, leverandøren ikke længere vedligeholder.

CMS 13’s GA og CMS 11’s supportophør er ikke separate beslutninger — den nye majors ankomst er det, der skubbede den ældre ud af vinduet, og 10. april-annonceringen var den formelle registrering af det. Optimizely har lagt rigtige platformsforbedringer bag det, hvilket er sådan, en policy af den slags er tænkt. Men det betyder også, at startbanen er den, en ny majors udgivelsesplan giver jer.

CMS-opgraderingen er dokumenteret. Jeres tilpasninger er ikke.

Selve CMS-opgraderingen følger en dokumenteret vej. Optimizely leverer migrationsværktøjer, breaking changes er listet, og platformens indholdsskema overlever stort set turen. 12-til-13-strækningen er primært en Graph-skema-opdatering og et sæt veldokumenterede breaking changes — håndterbar på sine egne ben. 11-til-12-strækningen er den tunge: det er der, .NET Framework til .NET Core-skiftet ligger, og platform-arbejdet er reelt, selv før I rører jeres egen kode.

Uanset hvad er platform-siden den del, der er dokumenteret.

Det svære ved en Optimizely CMS 11-opgradering er ikke Optimizely CMS.

Det svære er det årti af tilføjelser, der er stablet ovenpå: custom property types, planlagte jobs, indholdsimport-rør, integrationsendpoints til ERP’er og PIM’er og CRM’er, custom admin-værktøjer, EPiServer.Find-queries spredt på tværs af halvdelen af kodebasen, tredjeparts-add-ons af varierende livskraft, og en indholdsmodel, der har akkumuleret tre produktlanceringers redigeringer.

Det er der, ingeniørtimerne går. Og det er den del, ingen tager med, når de pitcher opgraderingen som “bare et version-bump”.

Runtime-skiftet er den største enkelte post — og det ligger i 11-til-12-strækningen

Det er den del, der overrasker teams mest.

CMS 11 kører på .NET Framework. CMS 12 flyttede til .NET Core; den supporterede smag er nu .NET 8. CMS 13 flytter igen til .NET 10, men det er et meget mindre spring end det oprindelige Framework-til-Core-skifte. Hovedparten af runtime-arbejdet i et CMS 11 → 13-forløb ligger i 11-til-12-strækningen.

Det har konsekvenser overalt. Hver eneste NuGet-pakke, I afhænger af, har enten et moderne .NET-build, eller også har den ikke. Hvis ikke, skal I enten erstatte den, forke den, eller skrive den del af systemet om. Alt der ligger på System.Web er på vej ud. Authentication flytter fra OWIN til den moderne hosting-model. Konfiguration skifter fra web.config til appsettings/options-mønstret. Dependency injection bliver default. Serializere, helpers, custom HttpModules — meget af det skal røres.

I et typisk CMS 11 → 13-projekt er runtime-arbejdet den største enkelte post af CMS-side-arbejdet, og næsten alt af det ligger i 11-til-12-strækningen. Større end indholdsmigreringen. Større end den visuelle ombygning. Det er stort set usynligt udefra, hvilket er grunden til, at det bliver underbudgetteret.

Find er væk. Søgning og navigation er nu Graph-opgaver.

Optimizely Find er ikke en del af CMS 13. Alt I har bygget på EPiServer.Find — søgeresultatsider, autocomplete, facetterede listninger, navigationsmenuer drevet af content-queries, related-content-widgets — skal genimplementeres på Optimizely Graph.

Den gode nyhed: Graph er et ordentligt moderne, GraphQL-baseret content-lag, og Optimizely.Graph.Cms.Query-SDK’en eksponerer et fluent C#-API, der ligger tæt op ad Find’s form. Filter bliver til Where, For bliver til SearchFor, Take bliver til Limit. Den mentale model overlever.

Den mindre gode nyhed: I skal stadig lave hver omskrivning i hånden, og Graph vil have jer til at tænke anderledes om jeres indekseringsmodel. Redaktører vant til Find’s næsten-øjeblikkelige indeksering skal briefes på Graph’s anden sync-adfærd. Alt der lavede smarte scoring-tricks i Find, skal have det tilsvarende regnet ud i Graph.

Hvis søgningen er central for jeres sites brugeroplevelse, fortjener den del sin egen scoping-samtale, ikke en fodnote i migrationsplanen.

Visual Builder belønner et strukturelt nytænk

CMS 13’s Visual Builder er den nye standard-redigeringsoplevelse, og den er virkelig god. Experiences og sections adskiller layout fra indhold på en måde, der giver redaktøren kontrollen over siden tilbage.

Men I får ikke værdien af Visual Builder ved at portere de gamle content types over uændret. Gevinsten kommer ved at gentænke indholdsmodellen — splitte monolitiske sidetyper op i komponerbare sektioner, løfte layout-beslutninger ud af side-skemaet, give redaktørerne rigtige byggeklodser i stedet for en lang formular med tredive felter.

Hvis I alligevel skal forstyrre indholdsmodellen, så gør det ordentligt. Alternativet er at sende CMS 13 i luften med et CMS 11-mindset: den nye redaktør oven på den gamle struktur, alle omkostningerne og ingen af gevinsterne.

Custom plugins skal næsten altid omskrives

De admin-UI’er og edit-mode-plugins, I byggede for fem år siden, kommer til at kræve arbejde. CMS 12 flyttede allerede redaktøren af sin Dojo-arv, og CMS 13 ændrer admin-side-integrationen yderligere — nye Tag Helpers, en anden shell-navigationsmodel. Custom property editors og dashboards bygget til CMS 11 overlever ikke turen uden genimplementering.

Det er irriterende, men det er også en audit-mulighed. Et overraskende antal interne plugins findes, fordi nogen havde brug for noget en tirsdag i 2020, og de er der stadig, fordi ingen har fjernet dem. Opgraderingen er et naturligt tidspunkt at spørge: hvilke af dem leverer faktisk værdi? Genimplementér dem der gør. Pension resten.

De mest generelt nyttige redaktør- og admin-værktøjer — dem næsten alle Optimizely-sites genopfinder på et tidspunkt — har vi allerede open-sourcet som Editor Power Tools, der dual-targetter CMS 12 og 13. Så det værste af det hjul ikke skal genopfindes på hver opgradering.

Sådan griber vi opgraderingerne an nu

Jeg har været med på flere CMS 11 → 13-opgraderinger, og nogle af dem har været agent-drevne ende til ende. Nogle ting er kommet ud af det:

• Agenter trænet på den specifikke opgraderingsvej. Faldgruberne i CMS 11 → 13 er et endeligt, veldefineret sæt. Når I har ramt dem nogle gange, er de agentvenlige — og vi har nu agenter, der genkender mønstrene: gammel IContentRepository-brug der skal blive async, EPiServer.Find-kald der skal oversættes til Graph, konfigurationssektioner uden et rent 1:1 i den nye verden.
• Et automatisk datamigrationssystem. Indholdsskemaer ændrer sig mellem versioner, og de fleste opgraderinger involverer alligevel noget omformning. Vi har et system, der kører migrationerne som en del af deploy-pipelinen, med validering og rollback, så redaktørerne ikke mærker noget under cutover.
• Samme projekt kan tage jer af on-prem. Hvis I hoster CMS 11 på jeres egen infrastruktur, er opgraderingen det rette tidspunkt at flytte over på Optimizely DXP med Graph-support — i stedet for at genopbygge on-prem-stakken på .NET 10 for så at migrere igen senere.

Det hele står på Optimizely Opgradering-tilbudssiden, hvis I vil have den formelle version.

Hvis I står på CMS 11, sådan ville jeg planlægge det

Klippekanten var i april. Prisen for ikke at gøre noget vokser nu. “Support stoppede” betyder ikke “site holdt op med at virke” — jeres installation kører stadig. Men hver måned forbi april driver jeres dependency-graf længere ud af det supporterede, og den planlægningsstartbane, I havde brug for, bliver lidt kortere.

Audit før I scoper. Den realistiske opgraderingspris er en funktion af det, der er omkring CMS’et, ikke af CMS’et. To dages audit — add-ons, custom kode, søgning, integrationer, plugins — giver jer et budget, I faktisk kan stole på.

Spike runtime-skiftet og Graph isoleret. Inden I forpligter jer til en fuld plan, så bevis de to mest risikable stykker på en flig af kodebasen. Tallene fra de spikes fortæller jer, om I skal direkte til 13 eller staget via 12.

Behandl indholdsmodellen som en del af opgraderingen. De strukturelle ændringer Visual Builder belønner, er nemmere at lave under opgraderings-scope end som et opfølgningsprojekt, ingen finder budget til.

Planlæg nu, og send det live. Selv en aggressiv tidsplan har gavn af en startbane. De teams der startede planlægningen for et kvartal siden, lander blødt. De teams der starter til efteråret, gør ikke.

Hvis I helst ikke vil tage opgraderingen alene, er det netop, hvad vores Optimizely Opgradering-tilbud er til — det samme forløb beskrevet ovenfor, ende til ende: vurdering, runtime-skift, indholdsmigrering, Find-til-Graph-omskrivning, cutover og post-launch-pleje.

CMS’et flytter sig, når I beder det. Det årti af tilføjelser omkring det er den del, der kræver planlægningen.