Optimizely CMS 13 – det här förändras under huven

CMS 13 är inte en omskrivning. Det är ett arkitektonellt skifte – och skillnaden är viktig att förstå innan ni bestämmer när och hur ni migrerar. 

Den stora nyheten är inte Visual Builder eller Opal–agenterna. Den stora nyheten är att Optimizely Graph nu är en strukturell förutsättning för plattformen, inte ett tillval. Det förändrar hur ni planerar, driftsätter och förvaltar er lösning. 

Niklas Andersson
Publicerad: 13 mars 2026

Från .NET 8 till .NET 10 

Det första och mest konkreta steget i en CMS 13–migrering är att byta target framework från .NET 8 till .NET 10. I sig är det ett hanterbart steg – men det innebär att alla tredjepartspaket och egenutvecklade tillägg måste verifieras mot den nya versionen. 

Steget från CMS 11 till 12 var transformativt eftersom det innebar ett byte från .NET Framework till modern .NET. Steget från 12 till 13 är inkrementellt – men kräver ändå noggrann inventering av era beroenden. 

Optimizely Graph är inte längre ett val 

Graph ersätter Search & Navigation som indexerings– och leveransmotor. Det är inte längre ett komplement – det är den kanal genom vilken CMS 13 indexerar, förhandsgranskar och levererar innehåll. 

Att köra CMS 13 utan Graph är tekniskt möjligt, men i praktiken innebär det att ni kör CMS 12 kompilerat för .NET 10. Funktioner som Content Manager, Visual Builder i headless–läge och Opal–integration kräver samtliga att Graph är på plats. Frågan är alltså inte om ni ska adoptera Graph – utan när i er migreringstidslinje ni gör det. 

Sökimplementationer byggda på Search & Navigation (Find) stöds inte i CMS 13. Ni behöver antingen implementera sökning via GraphQL mot Optimizely Graph, eller integrera en tredjepartslösning. 

Nya API:er och obsoleta typer 

CMS 13 deprecerar ett antal API:er som är vanliga i äldre kodbaser. De mest frekventa: 

PageReference och PageData.PageLink är obsoleta. Förändringen speglar ett bredare skifte mot att behandla allt innehåll generiskt – sidor är inte längre en privilegierad innehållstyp. Compiler–varningarna fungerar som en vägkarta: gå igenom dem systematiskt i stället för att tysta dem. 

Identitetshanteringen är frikopplad från CMS–kärnan. EPiServer.CMS.UI.AspNetIdentity är nu ett separat paket och måste refereras explicit. Opti ID – Optimizelys SSO–lösning – ersätter per–produkt–login och är obligatorisk i CMS 13. 

Ny applikationsmodell – sites blir applications 

CMS 13 lånar arkitektur från SaaS-versionen och inför ett skifte från "sites" till "applications". Konkret innebär det två konfigurationstyper: 

Website representerar den traditionella in-process ASP.NET–applikationen. RemoteWebsite representerar en headless frontend kopplad till CMS via Graph. 

Det är en viktig distinktion vid migrering av befintliga site definitions – de behöver mappas om till rätt applikationstyp, annars uppstår 404–fel direkt efter databas–importen. 

On–premises och driftsättning 

CMS 13 pre–release stöder inte traditionell on–premises–driftsättning. Molnbaserade modeller rekommenderas, och Optimizely förordar sin egen molnhosting för CMS–lagret kombinerat med valfri frontend–hosting för headless–setuper. 

För organisationer med strikta krav på datalagring eller on–prem–arkitektur är det ett reellt hinder som bör utredas innan migreringsbeslut fattas. 

Vad innebär Preview 3 – och när kommer GA? 

CMS 13 befinner sig när vi skriver dethär i Preview 3 och är inte produktionsklar. GA är målsatt till sen mars 2026. Preview 3 är lämplig för utvärdering, experimentmiljöer och förberedelse av migreringsplaner – inte för produktion. 

Det som är stabilt nog att börja planera mot: Graph–integrationen, den nya applikationsmodellen och identitetshanteringen via Opti ID. Det som fortfarande förändras mellan previews: auto–save–beteende i Visual Builder, standardaktivering av Content Manager och Graph. 

Rätt timing för migrering 

Har ni en CMS 12–installation i bra skick är det ingen brådska. Fokusera på att kartlägga era Graph–beroenden, inventera tredjepartspaket mot .NET 10 och planera söklösningen. Det är där den tekniska risken sitter – inte i .NET–uppgraderingen i sig. 

Är ni fortfarande på CMS 11 är frågan en annan. Då är steget till 13 en arkitektonisk förändring som kräver mer planering, och en mellanlandning på 12 kan vara rätt väg beroende på komplexitet. 

Vill ni gå igenom vad en migrering innebär för just er lösning?

Vi på Precio Fishbone har erfarenhet av Optimizely–uppgraderingar på alla nivåer – hör av er så tittar vi på det tillsammans.  

Niklas Andersson

Optimizely Sales & Practice Lead

Niklas Andersson är Optimizely Practice Lead på Precio Fishbone och har över 8 års erfarenhet av ledande roller på Optimizely. Niklas har arbetat med kundsuccé, serviceutveckling och digital transformation, och brinner för att hjälpa företag och organisationer att skapa tillgängliga och användarvänliga webbplatser med hjälp av AI och moderna CMS-lösningar.

Meny