Spørgsmålet "skal vi have et nyt CMS?" kommer som regel før diagnosen. Nogen er blevet frustreret – redaktionen, udviklerne, ledelsen – og frustrationen bliver hurtigt oversat til et platformsspørgsmål, fordi det er det, der er lettest at handle på. Et nyt CMS er et projekt med en start og en slutning. At finde ud af, hvad der faktisk er galt, er sværere, og det bliver ofte sprunget over.
Først: hvad er det, der gør ondt?
Det, folk kalder "et CMS-problem", er som regel én af tre forskellige ting, og de kræver hver deres løsning.
- Et vedligeholdelsesproblem. Gamle plugins, ingen opdateringer, kode ingen tør røre, ingen versionsstyring. Det er ikke platformens skyld – det er otte år, hvor ingen har ryddet op. Løsningen er oprydning, ikke et nyt system.
- Et implementeringsproblem. Platformen er fin, men den konkrete løsning er bygget dårligt – en produktstruktur, der aldrig blev tænkt igennem, en integration limet sammen i sidste øjeblik, et indholdshierarki der gav mening for det første projekt og ikke for det, sitet er blevet til siden. Det løses ved at bygge om, ikke ved at skifte fundament.
- Et platformsproblem. Det er det sjældneste af de tre, og det stærkeste argument for et nyt CMS: platformens måde at modellere data og håndtere arbejdsgange på passer ikke længere til det, virksomheden har brug for. Ikke fordi nogen har implementeret det dårligt – men fordi det, virksomheden skal kunne, ikke passer ind i den måde, platformen tænker indhold på.
Et platformsproblem kan også være mere grundlæggende: at systemet ikke længere vedligeholdes eller sikkerhedsopdateres og derfor ikke er forsvarligt at blive på.
De tre bliver konstant blandet sammen, og det er dyrt. Et vedligeholdelsesproblem løst med en migration er penge brugt forkert – og et reelt platformsproblem, der bliver mødt med endnu en oprydning, er tid, der bare udskyder den samme samtale et år.
Når problemet ikke er CMS'et
De fleste "vi bør skifte CMS"-samtaler starter her, uden at nogen har opdaget det. Plugins der overlapper, fordi forskellige udviklere har løst det samme problem to gange over otte år. Et tema, ingen tør opdatere. Ingen versionsstyring, så ingen ved, hvad der faktisk er ændret siden sidst. Det er ikke tegn på, at platformen er forkert – det er tegn på, at systemet aldrig har fået den vedligeholdelse, det havde brug for. Jeg har skrevet den fulde liste i Kunsten at arve en WordPress-installation; den gentager jeg ikke her.
Når CMS'et faktisk er blevet problemet
Et reelt platformsproblem ser anderledes ud. Det opstår, når den måde, systemet organiserer indhold og data på, ikke længere passer til det, virksomheden skal kunne. Hvis en ny funktion hver gang kræver endnu en undtagelse, et ekstra lag eller den samme information gemt flere steder, er det værd at spørge, om problemet stadig kan løses inden for den eksisterende platform.
Det tekniske er kun den halve historie. Et system kan fungere upåklageligt teknisk og stadig være forkert, hvis redaktionen har udviklet sig væk fra det. Hvis en redaktør skal kende interne ID'er for at rette en side, kopiere det samme indhold ind tre forskellige steder, eller ringe til en udvikler for at oprette en ny indholdstype, er problemet ikke nødvendigvis performance eller gammel kode. Det er et tegn på, at systemets arbejdsgange ikke længere passer til den organisation, der arbejder i det hver dag. Om det kræver et nyt CMS eller en bedre implementering af det eksisterende, er netop det, der skal undersøges.
Hvad bliver faktisk bedre?
Før man beslutter sig for en migration, bør der være et konkret svar på: når vi er færdige, kan vi ___, som vi ikke kan i dag.
"Vi får en nyere kodebase" er ikke et svar, der bærer et projekt af den størrelse. "Redaktionen kan administrere flere markeder uden udviklerhjælp" er det. "Produktdata får én model i stedet for at leve tre forskellige steder på tre forskellige måder" er det også. Forskellen er, om svaret peger på noget, nogen konkret kan gøre bagefter – ikke om koden ser pænere ud.
Det, man efterlader
"Vi bygger det bare på ny" lyder enklere, end det er. Under overfladen ligger indhold, URL'er, redirects, metadata, strukturerede data, billeder og filer, brugere, integrationer, formularer, tracking, samtykke, historiske data, redaktionelle arbejdsgange, rettigheder og alt det, søgemaskinerne allerede ved om sitet.
Men der er også noget mindre synligt end listen.
Den gamle løsning indeholder otte års beslutninger.
Nogle af dem er dårlige. Nogle af dem løser problemer, ingen længere kan huske eksisterede – en undtagelse for én kunde, en workaround for et system, der ikke findes mere, en regel ingen længere kan forklare, men som stadig løser et reelt problem. Flyt ikke noget, før du ved, hvorfor det er der.
En migration er et projekt i sig selv
En migration er ikke installation af et andet system med det gamle indhold hældt ind. Det gamle system skal typisk fortsætte med at fungere, mens det nye bliver bygget, og ændringer i indhold og data stopper ikke imens.
Derfor skal en migration også have en plan for overgangen: hvad flyttes automatisk, hvad skal bygges om, hvad skal testes, og hvornår det nye system overtager. "Vi flytter bare indholdet over" viser sig ofte at være den mindste del af arbejdet.
Reparere eller skifte?
Ikke fordi systemet er gammelt. Ikke fordi koden er grim. Og heller ikke fordi et andet CMS ser bedre ud i en demo.
Skift, når det eksisterende system står i vejen for det, virksomheden eller redaktionen skal kunne – og når det er dyrere at blive ved med at arbejde rundt om begrænsningerne end at flytte.
Er problemet derimod plugins, manglende opdateringer og kode, ingen længere tør røre, har man måske ikke brug for et nyt CMS.
Man har brug for at få styr på det, man allerede har. Det er også den del af arbejdet med CMS-løsninger, jeg oftest bliver kaldt ind til.
