Migrering fra gammelt CMS til Enonic
Lær hvordan Direktoratet for byggkvalitet (DiBK) flyttet fra Optimizely til Enonic i denne detaljerte kundehistorien.
Intro
Direktoratet for byggkvalitet (DiBK) er et nasjonalt kompetansesenter på bygningsområdet. DiBK er underordnet Kommunal- og distriktsdepartementet og er en sentral myndighet på flere områder innenfor bygningsdelen av plan- og bygningsloven.
Direktoratets to hovedoppgaver er å 1) sikre trygge, miljøvennlige og tilgjengelige boliger og bygninger, og 2) bidra til å etablere forutsigbare regler for effektiv ressursbruk i byggeprosessen.
Etter å ha vært en kunde av Episerver (nå Optimizely) i mange år, kjørte DiBK på en gammel, utdatert og snart usupportert versjon av publiseringssystemet. Med fare for å sitte fast med en løsning uten teknisk støtte, bestemte DiBK seg for enten å oppdatere den eksisterende løsningen eller anskaffe en ny.
En offentlig anskaffelsesprosess ble satt i gang, som startet med en kartleggingsfase der behov og visjoner ble identifisert. DiBK utlyste deretter en offentlig anbudskonkurranse i mars 2022, med en prekvalifiseringsrunde som varte i to uker for å raskt luke ut uaktuelle kandidater.
Etter å ha evaluert de mange tilbudene, ble det opprettet en utvalgsliste basert på relevante kriterier. Neste steg var forhandlingsrunder med relevante kandidater i løpet av våren 2022. Det norske systemintegratorbyrået 99x ble valgt i juni 2022, med et tilbud som inkluderte implementering av Enonic-plattformen.
Planlegging og arbeid startet i løpet av sommeren og tidlig høst 2022. Den nye, migrerte siden for Direktoratet for byggkvalitet ble lansert i februar 2023.
Utfordring
Via den digitale plattformen er DiBKs kjerneoppgaver å digitalisere byggesaker og gi veiledning om bygningsteknisk forskrift. Forskriftene må derfor være digitalt tilgjengelige og kunne integreres med andre systemer. Målet er ikke bare å gjøre forskriftene tilgjengelige, men å forenkle bruken for alle interessenter.
Med en utdatert versjon av Optimizely som nærmet seg slutten av sin støtteperiode, sto DiBK ved et veiskille. Skulle de oppgradere til en ny versjon eller gå over til et helt nytt CMS?
Ønsket var et fremtidsrettet CMS som kunne integreres sømløst med internt utviklede løsninger og eksterne API-er. Dette markerte starten på et omfattende migrasjonsprosjekt ledet av 99x.
Før migrasjonen hadde DiBK allerede lagt grunnlaget ved å fullføre et redesignprosjekt som etablerte en ny innholdsmodell og struktur. DiBK skisserte videre fire hovedmål for migrasjonen:
- Effektiv publisering av digitale veiledere
- Mulighet til fleksibel testing av brukersentrerte konsepter
- Enkel justering av innhold og design av interne brukere
- Generelt enklere og mer effektiv drift
De viktigste utfordringene med det gamle CMS-et som måtte håndteres var:
Slutt på støtte
DiBKs CMS-versjon nærmet seg slutten av sin støtteperiode. For å sikre fortsatt teknisk støtte og systemsikkerhet var det derfor nødvendig med en endring.
Krevende innholdsforvaltningsprosess
Innholdsforvaltningsprosessen i DiBKs spesifikke oppsett krevde omfattende manuelt arbeid. Systemet hadde utviklet et omfattende utvalg av maler over tid, noe som potensielt kunne være overveldende for nye redaktører og generelt ineffektivt.
Kompleks strukturell løsning
Den gamle CMS-løsningen var strukturelt tungvinn, noe som førte til utfordringer med navigasjon og innholdsforvaltning i systemet.
Omfattende og uklart innholdstre
DiBK sto overfor vanskeligheter med et altfor omfattende og uintuitivt innholdstre, noe som vanskeliggjorde organisering og gjenbruk av innhold.
Treg søkefunksjonalitet for innhold
Søkefunksjonaliteten i CMS-et var tregere enn optimalt, noe som påvirket effektiviteten av å finne og forvalte innhold.
Blandet teknologi
DiBKs digitale infrastruktur var bygget på en blanding av teknologier, inkludert ulike MVC-rammeverk, .NET og Web Forms, noe som førte til kompatibilitetsproblemer med nyere versjoner av Optimizely.
Lange lastetider
Den eldre versjonen av CMS-et opplevde lengre lastetider, noe som påvirket brukeropplevelsen for redaktører.
Høy kostnad for utvikling av maler
Utvikling og vedlikehold av egendefinerte maler på den utdaterte plattformen var både kostbart og tidkrevende, noe som bidro til de operasjonelle utfordringene.
Mangel på fremtidsretting
Det eksisterende oppsettet manglet nødvendig fleksibilitet for fremtidige utvidelser, spesielt når det gjaldt enkel integrering og forvaltning av nye systemer eller komponenter.
***
Når det gjelder implementeringspartneren 99x, var det en sentral utfordring å omforme og implementere DiBKs eksterne struktur, innhold og tjenester nøyaktig slik de var (med bedre ytelse), men innenfor det nye Enonic-miljøet.
Løsning
Redaksjonsteamet hos DiBK var klare for noe nytt. De var på utkikk etter et CMS som tilbød brukervennlighet og effektivitet i publisering av veiledere og håndtering av innhold, samt fleksibilitet i å bygge egendefinerte sider.
Samtidig måtte den nye løsningen følge en headless-arkitektur for fremtidige krav. Den interne portalen skulle også redesignes.
For DiBK virket Enonic-løsningen fra 99x forslag som en fleksibel og intuitiv samt kostnadseffektiv plattform.
Migrasjon: Steg for steg
99x sto overfor oppgaven med å migrere den gamle løsningen i et 1:1-forhold til en ny løsning, en prosess som involverte manuell kartlegging av parts, makroer, mixins og innholdstyper. Denne nøye tilnærmingen ble hjulpet av et Excel-ark for alle nødvendige felt. 99x utviklet også plugins som gjorde det mulig å trekke ut innhold fra Optimizely for import til Enonic.
Den formelle migrasjonsprosessen ble organisert som følger:
- Gå gjennom løsningen og kartlegg alle felt og innholdstyper.
- Gå gjennom de øverste nodene i Optimizelys innholds-API, og bestem hvilke sider som skal inkluderes og hvilke som ikke skal det.
- Opprett tjenester: a) Hent ressurser, b) hent gammelt innhold
- Importer alle bilder og filer (innholds-API-et inkluderte unike ID-er som koblet media med objekter)
Innholdsmodell
I stedet for å lage en ny blokk for hver nye veileder eller redaksjonelle behov, kan DiBK nå ha én blokk med flere redigeringsmuligheter. For DiBK gir Enonic-konseptene med makroer og parts større fleksibilitet til å bygge sider slik de ønsker med ulike elementer, i stedet for å arbeide innenfor en fast mal. Migrasjonen gjorde det derfor mulig for DiBK å redusere antall maler med halvparten.
I stedet for å ha mange innholdstyper, ble innholdstreet grunnere – spesielt med tanke på TEK17-innhold. Nå er det enklere for redaktører å opprette nytt innhold.
Ved import mente 99x at det var unødvendig å ha separate innholdstyper på det laveste nivået i veiledningene – som paragraf og ledd. Disse ble derfor kombinert i den endelige innholdsstrukturen.
Alt som ble importert fra innholds-API-et, ble lagret i et x-data-felt, som ID og ID-er for underobjekter. Disse dataene ble brukt til å slå sammen innholdsobjekter ved den første importen.
Innholdstyper
En av de vanligste innholdstypene for DiBK er "veileder," som spesifiserer forskrifter, råd og prosesser for byggeprosjekter.
Innholdstypen "veileder" har flere felt, hvorav et er "item set" for å lage én til flere veiledningstekster. Disse kan deretter settes inn i hovedfeltet. Dette skjer via en makro som lister opp veiledningstekstene som er opprettet inne i den spesifikke veiledningen.
Innholdstypen "best bet" er en del av en søkefunksjonalitet som måtte gjenskapes i Enonic. Her gis visse nøkkelord prioritet og fremmes i nettstedets søkefunksjon. For eksempel er "best bet" satt opp til alltid å prioritere innhold fra TEK17-standarden i søkeforespørsler.
Innholdstypen "høringer" kombinerer visning i front-end med lenking til eksterne nettsteder for å kunne svare på en høring.
“Smartere oppussing” er en tjeneste med informasjon om oppussing. I denne innholdstypen kan DiBK fastslå koordinater hvor komponenter skal plasseres på et hus i front-end.
Komponenter
En sentral komponent på det nye DiBK-nettstedet er en integrasjon med service-deskløsningen Pureservice. Redaktører kan opprette skjemaer i Pureservice gjennom deres avanserte skjemadefinisjoner, mens et API publiserer spesifikasjonene til skjemaene. Utforming og logikk kommer fra Pureservices egen skjemabygger, der kundeservice setter opp logikk og flyt. I Enonic kan redaktørene berike skjemaet før det gjengis i front-end.
Høringer fra Hoering.no integreres gjennom et API fra Utdanningsdirektoratet (UDIR). Når en DiBK-redaktør oppretter en høring, er det en arbeidsflyt i Enonic hvor man kan se status, respons osv. i front-end. Denne komponenten brukes også andre steder.
"Boligdugnaden" er en søketjeneste for boliger til flyktninger. Den ble raskt opprettet av 99x, og suksessen ble til og med nevnt av media.
Admin-verktøy og widgets
DiBK har benyttet seg av 99x' Nynorskoversetter-app. I Norge er det et krav at offentlige nettsteder må ha minst 25 prosent av språket på nynorsk, noe denne appen gjorde enklere. Appen og den tilhørende widgeten drives av Totaltekst gjennom et API, og man kan oversette manuelt eller automatisk rett i Content Studio. Redaktører kan oversette en innholdsnode med ett klikk, inkludert tekst i layouter og parts.
