Bytte LMS: slik migrerer du uten å miste data

Leser du dette, er du sannsynligvis lei av LMS-et du har. Kanskje bruker administratorene dobbelt så lang tid som de burde på enkle oppgaver. Kanskje sluttet deltakerne å logge inn for flere måneder siden. Kanskje forsvinner supportsakene dine inn i en kø og kommer tilbake en uke senere med lenke til en hjelpeartikkel du allerede har lest.

Du er i godt selskap. I 2020 fant Brandon Hall Group at 42 % av bedriftene aktivt lette etter et nytt LMS.

De fleste organisasjoner vokser ut av læringsplattformen sin før eller siden, eller går rett og slett lei. Likevel blir mange værende lenge etter at de burde ha byttet, fordi selve byttet virker skremmende stort og risikabelt. I det gamle systemet ligger fullføringsdata, compliance-sertifikater, kursinnhold og integrasjoner fra mange år tilbake. Hva om noe blir borte på veien?

Frykten er forståelig, og den lar seg håndtere. En godt gjennomført LMS-migrering er ikke et sjansespill, men et prosjekt med kjente risikoer, kjente sikringstiltak og en tydelig rekkefølge. I denne guiden går vi gjennom hele løpet: hvordan du vet at det faktisk er på tide, hvilke data du må beskytte, om du bør kjøre begge systemene samtidig en periode, hva den nye leverandøren skal gjøre for deg, og hva du gjør hvis det går galt halvveis.

Før vi begynner, er det én ting du bør vite. Du trenger ikke velge mellom å holde ut ett år til med det gamle systemet og et ombyggingsprosjekt som tar et halvt år. Det valget er kunstig, og som regel stammer det fra leverandører som selv trenger seks måneder på jobben. Med et realistisk omfang og ordentlig hjelp fra leverandøren du flytter til, kan du gjennomføre hele byttet på noen uker.

Hva er tegnene på at det er på tide å bytte?

Det er fem signaler du bør ta på alvor, og ingen av dem skyldes bare en dårlig uke.

• Administratorene dine jobber utenfor systemet. Må teamet eksportere data til regneark for å svare på enkle spørsmål, eller har de bygd sin egen mappestruktur fordi det er håpløst å finne frem til innhold i LMS-et, har plattformen allerede spilt fallitt.
• Deltakerne holder seg unna. Lave innloggingstall, kurs som startes uten å bli fullført, ledere som purrer på fullføringer per e-post. Før du legger skylden på plattformen, bør du likevel se nøkternt på om problemet er systemet eller måten det brukes på. Vi har skrevet om akkurat det spørsmålet i hvorfor LMS-et ditt ikke blir brukt. Har du rettet opp innhold, kommunikasjon og ledernes engasjement, og folk likevel gir opp når de møter grensesnittet, ligger problemet i plattformen.
• Supporten har blitt et svart hull. Du sender inn saker, venter, eskalerer og venter igjen. Får du ikke tak i et menneske når noe kritisk for driften står på spill, tar du en risiko du aldri har valgt.
• Prisen står ikke lenger i forhold til bruken. Du betaler for lisenser ingen bruker, eller får uventede fakturaer for funksjoner som burde vært standard.
• Utviklingen har stoppet opp. Har det ikke kommet noen vesentlige oppdateringer på ett eller to år, er det som regel fordi leverandøren har oppmerksomheten et annet sted.

Ingenting av dette er nytt. Allerede i 2016 viste en undersøkelse fra Brandon Hall Group at 44 % av bedriftene med læringsteknologi var på jakt etter et nytt system. Den vanligste grunnen var behovet for en bedre brukeropplevelse, som 87 % oppga.

Kjenner du igjen tre eller flere av signalene, er spørsmålet ikke lenger «bør vi bytte?», men «hvordan bytter vi trygt?». Og når du skal velge ny plattform, lønner det seg å gjøre et grundigere forarbeid enn sist. Med en strukturert kravprosess og exit-vilkår som sikrer at du får dataene dine ut, slipper du å havne på akkurat samme sted om tre år. Hvordan du gjør det, står i vår guide til kravspesifikasjon for LMS.

Din sjekkliste for LMS-migrering: kjenn risikoene før du flytter

Kartlegg hva du faktisk tar med deg før du ser en eneste demo. De fleste skrekkhistorier om migrering handler om en avhengighet ingen oppdaget før etter byttet. Gå gjennom sjekklisten først, for alt annet i denne artikkelen bygger på den.

Dette er hovedspørsmålene i sjekklisten:

• Data: hva må flyttes, hva kan arkiveres, og hva kan bli igjen? Brukerkontoer, påmeldingshistorikk, fullføringsdata, sertifikater, prøveresultater.
• Innhold: hvilke kurs er faktisk i bruk? Hvilke formater ligger de i, og kan de eksporteres i en standard som SCORM, xAPI eller cmi5?
• Integrasjoner: hvilke systemer er koblet til LMS-et ditt i dag? HR-system, single sign-on, kalenderverktøy, rapportflyter. Hver kobling er en egen oppgave i migreringen.
• Compliance: hvilken dokumentasjon er du lovpålagt å oppbevare, og hvor lenge? Derfor regnes sertifikater og fullføringshistorikk som høyrisikodata (mer om det nedenfor).
• Mennesker: hvem skal informeres, læres opp og tas med på laget? Administratorer, ledere, deltakere, IT.
• Tidspunkt: finnes det opplæringsfrister, revisjoner eller onboarding-bølger du ikke kan forstyrre?

Svarer du ærlig på disse spørsmålene, er du allerede bedre forberedt enn de fleste organisasjonene som i etterkant skriver sinte innlegg om migreringen sin.

Parallelldrift eller big bang: hvilken migreringsstrategi passer deg?

Du har to grunnstrategier å velge mellom, og valget avgjør hele risikoprofilen din. Enten kjører du det gamle og det nye systemet side om side i en overgangsperiode, eller så setter du en dato og bytter alt på én gang.

Ingen av dem passer for alle.

Parallelldrift betyr at deltakerne fullfører kursene de holder på med i det gamle systemet, mens all ny aktivitet starter i det nye. Du har et sikkerhetsnett på plass, for det gamle systemet er fortsatt i drift hvis noe går i stykker. Men det har en pris. Du betaler doble lisenser så lenge begge systemene kjører, administratorene må vedlikeholde to systemer, og deltakerne kan bli usikre på hvor de skal logge inn. Parallelldrift passer hvis du har lange kurs som ikke kan avbrytes, strenge compliance-frister eller så mange deltakere at én dårlig lanseringsdag blir dyr.

Big bang betyr at du migrerer, validerer og bytter på en fastsatt dato. Det er ryddigere og billigere, og det tvinger frem beslutninger i stedet for at de trekker ut i tid. Til gjengjeld samles hele risikoen på én dag, og er noe feil, merker alle det samtidig. Big bang passer hvis du har en kompakt kurskatalog, lite pågående opplæring (sommeren og årsskiftet er populære av gode grunner) og en datamigrering du har validert grundig før byttet.

Mange lander på en praktisk mellomvei, nemlig big bang for plattformen og det gamle systemet i lesemodus noen uker etterpå. Da blir det tydelig for alle at dere har flyttet, samtidig som historikken er tilgjengelig mens du kontrollerer at alt har kommet riktig over. Spør leverandøren du forlater hva en periode i lesemodus koster, før du tar for gitt at det lar seg gjøre. Det er et forhandlingsspørsmål, og enda en grunn til at exit-vilkårene bør stå i avtalen fra første dag.

Hva flytter faktisk med deg: data, sertifikater, innhold, integrasjoner

Del kartleggingen inn i fire kategorier, fordi hver av dem flyttes på sin egen måte. Sier noen «vi flytter alt», kan du regne med at prosjektet vokser langt ut over estimatet.

Brukerdata og historikk. Kontoer, roller, gruppestrukturer, påmeldinger, fullføringsdata. Strukturen stemmer sjelden én til én mellom to plattformer, så regn med at feltene må kartlegges mot hverandre. Det som heter «læringssti» i det gamle systemet, kan hete «kursprogram» i det nye. Feilene gjemmer seg nettopp i denne kartleggingen, og den skal den nye leverandøren gjøre sammen med deg, ikke overlate til en mal.

Sertifikater og fullføringshistorikk: høyrisikodataene dine. Er opplæringen lovpålagt eller kreves for sertifisering (sikkerhetssertifiseringer, myndighetskrav, tillatelser til å drive virksomhet), er dokumentasjonen som beviser hvem som har fullført hva, det mest verdifulle du har i det gamle LMS-et. Mister du den, kan medarbeidere måtte ta obligatorisk opplæring på nytt, eller organisasjonen kan få avvik i en revisjon den ellers ville bestått. Behandle disse dataene som et eget delprosjekt. Eksporter dem tidlig, i et format en revisor godtar (datoer, versjoner, hvem som har fullført hva), og verifiser dem uavhengig av hovedmigreringen. Selv om den nye plattformen ikke kan importere hvert eneste historiske sertifikat, har du ryggen fri med et komplett og ryddig arkiv.

Kursinnhold. Innhold i standardformater lar seg flytte uten problemer. Spør begge leverandørene rett ut om de støtter SCORM, xAPI og cmi5 ved eksport og import, og test med et ekte kurs før du bestemmer deg. Innhold som er bygd i den gamle leverandørens egne verktøy, kan ofte ikke flyttes i det hele tatt, og nettopp her sprekker migreringer på tid og budsjett. En migrering gir dessuten en sjelden anledning til å rydde bort innhold ingen bruker lenger. Har ingen åpnet et kurs på to år, bør du spørre deg om det skal fornyes eller arkiveres.

Integrasjoner. Hvert system som er koblet til LMS-et ditt, må kobles om, konfigureres på nytt eller fases ut. List dem opp, utpek en ansvarlig for hver av dem, og test dem i det nye miljøet før lansering.

Når du først kartlegger dataene, bør du også finne ut hvor de fysisk skal lagres etter flyttingen. For europeiske organisasjoner er lagring innenfor EU/EØS stadig oftere et ufravikelig krav. Det er en av grunnene til at vi på Learnifier lagrer data på EU-servere og lar kunden velge svensk hosting hvis dataene skal bli i Sverige. Uansett hvilken leverandør du velger, bør du få svaret skriftlig.

Hvordan unngår du datatap og nedetid under en LMS-migrering?

Med fem rutiner har du dekket det meste av risikoen for datatap, og alle dreier seg om kopier og verifisering.

1. Ta en fullstendig eksport før du gjør noe annet. Hent ut en komplett eksport av brukere, fullføringer, sertifikater og innhold fra det gamle systemet før migreringsarbeidet starter, og lagre den et sted du selv har kontroll over. Dette øyeblikksbildet er forsikringen din og grunnlaget for en eventuell rollback (mer om det senere). Gjør det mens den gamle avtalen fortsatt garanterer deg tilgang.
2. Migrer i etapper, og verifiser hver etappe. Brukere først, så historikk, så innhold, så integrasjoner. Etter hver etappe kontrollerer du antall og tar stikkprøver. Stemmer antallet fullføringer i det nye systemet med eksporten? Har ti tilfeldig valgte deltakere riktig historikk? Små kontrollrunder fanger opp feil mens de fortsatt er billige å rette.
3. Frys endringer i det siste migreringsvinduet. Velg et kort tidsrom, gi tydelig beskjed om det og sett administratorendringer i det gamle systemet på pause, slik at dataene ikke endrer seg mens du flytter dem. Det trenger ikke bety nedetid for deltakerne. Migrerer du i etapper, er systemet ofte bare utilgjengelig i noen timer.
4. Beskytt pågående kurs. Ingen skal miste halve sertifiseringen sin på grunn av tidsplanen din. La enten pågående grupper gjøre seg ferdige i det gamle systemet (argumentet for parallelldrift), eller legg byttet til en naturlig rolig periode.
5. Behold det gamle systemet i lesemodus så lenge budsjettet tillater. Det er det billigste verifiseringsverktøyet du kan få. Er det tvil om en post ble migrert riktig, slår du bare opp i kilden.

Ingenting av dette er teknisk vanskelig. Det som kreves, er riktig rekkefølge og en ny leverandør som har gjort det før. Utfordringen ligger hos menneskene.

Endringsledelse: hvordan får du med deg folkene dine?

En teknisk feilfri migrering kan likevel mislykkes på lanseringsdagen hvis ingen har lyst til å logge inn. Systemet er nytt, men menneskene er de samme.

Å bytte LMS er lettere å selge inn enn de fleste IT-prosjekter, siden du som regel erstatter noe folk allerede misliker. Det kan du dra nytte av. Hvis du presenterer migreringen som «vi bytter system», bryr ingen seg. Fortell heller hva som blir enklere i hverdagen: færre klikk for å finne kurset sitt, sertifikater som faktisk lar seg laste ned, en plattform som fungerer på mobilen.

Noen grep som alltid gjør en forskjell:

• Informer administratorene først, og involver dem tidlig. De vet hvor skoen trykker i det gamle systemet, og det er de som kommer til å svare på alles spørsmål. Planlegger du migreringen uten superbrukerne, går du glipp av kunnskap bare de sitter på.
• Kommuniser datoer folk kan planlegge etter. «Fullfør pågående kurs innen den 15. Den nye plattformen åpner den 20. Det gamle systemet er i lesemodus ut måneden.» Mer trenger det ikke være.
• Gi lederne et budskap de kan bruke. Deltakere lytter mer til sin egen leder enn til en prosjektpostkasse. En kort melding lederne kan videresende og et punkt på agendaen til teammøtet når lenger enn en hvilken som helst lanseringskampanje.
• Gjør den første innloggingen verdt bryet. Det første folk ser i den nye plattformen, skal være relevant for dem: kurset deres, historikken deres, neste steg. Møter folk et tomt dashbord første dag, får skeptikerne rett i det de trodde.

Og vær ærlig om hva folk kan forvente. Noen ting blir annerledes uten å bli bedre den første uken. Si det på forhånd. Det koster ingenting, og folk har mer tålmodighet med det de er blitt advart om.

Hvilken støtte bør du kreve fra den nye leverandøren?

Altfor få kjøpere spør leverandøren rett ut: «Nøyaktig hva kommer dere til å gjøre for oss under migreringen, og hva koster det?»

Svarene varierer enormt fra leverandør til leverandør, og de sier mye om hvem du er i ferd med å binde deg til. Migreringsstøtte finnes på tre nivåer.

• Det som bør være gratis: en navngitt kontaktperson som har ansvaret for onboardingen din (ikke en supportkø), hjelp til å kartlegge datastrukturen din mot den nye plattformen, veiledning om eksportformater fra det gamle systemet, opplæring av administratorer, og klare svar om hva som ikke kan flyttes som det er. Tar en leverandør ekstra betalt for grunnleggende onboarding-hjelp, får du en forsmak på hvordan samarbeidet kommer til å bli.
• Det som det er rimelig å betale for: praktisk massemigrering av store innholdsbibliotek, spesialbygde integrasjoner, ombygging av kurs som sitter fast i et proprietært format, konvertering av historikk ut over standardimport. Dette er reelt prosjektarbeid, men omfang og pris skal stå i avtalen før du signerer, så du slipper overraskelser i måned to.
• Det som er en varsellampe: «dokumentasjonen vår dekker alt det der», ingen navngitt person, migreringstjenester bare via en tredjepart du aldri har møtt, eller en onboarding-prosess som forutsetter at du har en prosjektleder til overs.

Måten leverandøren oppfører seg på under migreringen, er det tydeligste forvarselet du får om supporten etterpå. En leverandør som er rask, menneskelig og raus mens den prøver å vinne deg som kunde, pleier å fortsette slik. En som er treg før du i det hele tatt har signert, blir ikke raskere etterpå. Derfor setter vi på Learnifier mennesker, med navn og telefonnummer, i sentrum av onboardingen. Nettopp i ukene da du flytter dataene og bygger opp det nye miljøet, trenger du noen som svarer når du ringer.

Still altså de ubehagelige spørsmålene i salgsprosessen. «Hva heter personen som skal hjelpe oss med migreringen? Hvor mange uker tok den siste migreringen dere gjorde for en kunde av vår størrelse, i praksis? Hva er inkludert, og hva faktureres?» Skriv svarene inn i avtalen.

Hva er de vanligste feilene ved LMS-migrering?

Når migreringer går galt, er det som regel av de samme grunnene. Her er de vanligste, omtrent i rekkefølge etter hvor ofte de forekommer:

1. Å migrere alt. Tar du med deg ti år med utdaterte kurs og inaktive kontoer, mangedobles arbeidet, og du flytter med deg rotet som gjorde det gamle systemet uutholdelig. Flytt det som er i bruk, og arkiver resten.
2. Å hoppe over testmigreringen. Er den ordentlige migreringen også den første du kjører, oppdager du kartleggingsfeilene først i produksjon. Gjør alltid en prøvekjøring med et utvalg ekte data, og verifiser før hele flyttingen.
3. Å behandle sertifikater som en bisak. Compliance-historikken havner i samme bunke som alle andre «data», og ingen kontrollerer den før revisoren gjør det. Gjør den til et eget delprosjekt med egen verifisering og eget arkiv.
4. Å undervurdere integrasjonene. Selve LMS-et kommer fint over, men SSO svikter, og ingen får logget inn første dag. Test hver kobling i det nye miljøet før byttet.
5. Å gå ut med nyheten før alt er validert. Forteller du hele organisasjonen «nå er vi i gang!» og så oppdager feil i dataene, mister du garantert tilliten du trenger i månedene fremover.
6. Å mangle en rollback-plan. Nesten ingen migreringsguider nevner denne feilen, så vi tar den for oss her.

Rollback-planen din: hva om det går galt halvveis?

Med en rollback-plan kan du gå videre med ro i magen. Den består av fire deler.

• Et gjenopprettingspunkt. Den fullstendige eksporten du tok før start (se over), og det gamle systemet i drift eller i lesemodus gjennom hele overgangen. Så lenge du har begge, kan alle feil rettes.
• Fastsatte stoppkriterier. Bestem på forhånd hva som skal til for at du tar en pause eller går tilbake: fullføringsdata som ikke stemmer, innloggingsfeil over et visst nivå, compliance-dokumentasjon du ikke får verifisert. Den beslutningen er mye lettere å ta på forhånd enn midt i flyttingen.
• En beslutningsansvarlig. Én navngitt person med mandat til å si «vi stopper, vi retter, vi prøver igjen neste uke». Må den beslutningen innom en komité, rekker mye å gå galt før noen sier stopp.
• En kommunikasjonsmal. To ferdigskrevne meldinger: «vi utsetter byttet, her er hvorfor og når» og «vi er midlertidig tilbake i det gamle systemet». Har du begge klare, holder det å sende en e-post hvis det blir forsinkelser.

I praksis betyr en rollback sjelden at migreringen skrinlegges. Som regel går du tilbake til det gamle systemet i noen dager mens en kartleggingsfeil rettes, og bytter så på nytt. For organisasjoner med en rollback-plan er det bare en liten forsinkelse. For dem uten blir det en katastrofe, fordi de ofte allerede har latt den gamle avtalen løpe ut. La oppsigelsen av det gamle systemet tre i kraft først etter at valideringen er gjennomført.

Etter migreringen: validering og de første ukene

En migrering er først ferdig når to ting er på plass: tallene stemmer, og folk jobber faktisk i den nye plattformen.

Valider før du feirer. Avstem tallene: antall brukere, antall fullføringer og antall sertifikater mot eksporten fra før migreringen. Ta stikkprøver av ekte poster, og la noen administratorer og ledere kontrollere dataene til sine egne team, for de oppdager ting ingen skript fanger opp. Test de viktigste flytene fra start til slutt: logg inn via SSO, meld deg på, fullfør et kurs, last ned et sertifikat og hent ut rapporten ledelsen spør etter hvert kvartal.

Se deretter på de menneskelige signalene. Innlogginger i uke én og uke tre. Hvilke spørsmål supporten får flest av, siden de viser nøyaktig hva som trenger en bedre veiledning eller en gjennomgang på fem minutter. Om lederne finner fremdriften til teamet sitt uten å måtte spørre. Rett de små irritasjonsmomentene raskt. Ellers fester inntrykket «det nye systemet er også dårlig» seg fortere enn du tror.

Og vær klar over én ting. Migreringen har fått dataene dine trygt over i den nye plattformen, men den har ennå ikke skapt nye rutiner, lansert nye programmer eller gitt resultatene som var grunnen til at du byttet. Etter migreringen begynner implementeringen, et eget prosjekt med sin egen oppskrift: sjekkliste for LMS-implementering.

Frykten som holder organisasjoner fast i et LMS de har vokst ut av, er nesten alltid større enn den reelle risikoen. Det ser du så snart hver risiko har fått et navn, en plass på listen og en plan. En god migrering handler om å liste opp risikoene og ta dem én etter én, med ordentlig hjelp fra leverandøren du flytter til. Vil du løfte blikket og tenke gjennom hva en læringsplattform egentlig skal gjøre for deg, bør du gjøre det før du begynner. Gå deretter gjennom sjekklisten ovenfor sammen med teamet, og se hvor mye mindre prosjektet er enn det ser ut til utenfra.