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 føles som en operasjon på åpent hjerte. År med fullføringsdata, compliance-sertifikater, kursinnhold og integrasjoner ligger i det gamle systemet. 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.

Én ting før vi begynner. Du trenger ikke velge mellom å lide et år til med det gamle systemet og en ombygging som tar et halvt år. Det er en falsk motsetning, og den kommer som regel fra leverandører som selv trenger seks måneder. Avgrenser du migreringen ærlig og får ordentlig hjelp fra leverandøren du flytter til, kan hele byttet gjøres på noen uker.

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

Fem signaler er verdt å ta på alvor, og ingen av dem handler om 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 tapt.
• 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. Hvis du har rettet opp innhold, kommunikasjon og ledernes engasjement, og folk fortsatt gir opp i grensesnittet, er det plattformen som er problemet.
• Supporten har blitt et svart hull. Du sender inn saker, venter, eskalerer og venter igjen. Når du ikke får tak i et menneske om noe som er kritisk for driften, løper du en risiko du aldri ba om.
• 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. Ingen oppdateringer av betydning på ett eller to år betyr som regel at leverandøren har oppmerksomheten sin 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, og den vanligste grunnen, oppgitt av 87 %, var behovet for en bedre brukeropplevelse.

Kjenner du igjen tre eller flere av signalene, kan du slutte å spørre «bør vi bytte?» og begynne å spørre «hvordan bytter vi trygt?». Og når du kommer til valget av ny plattform, bør du velge med mer omhu denne gangen. En strukturert kravprosess, med exit-vilkår som sikrer at du får dataene dine ut, sparer deg for å 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.

Kjernespørsmålene sjekklisten dekker:

• 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: hva snakker med 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? Dette er grunnen til at sertifikater og fullføringshistorikk er 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 oppriktig på disse spørsmålene, er du allerede bedre forberedt enn de fleste organisasjoner som i ettertid skriver sinte innlegg om migreringen sin.

Parallelldrift eller big bang: hvilken migreringsstrategi passer deg?

Du har to grunnstrategier å velge mellom, og valget former 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 er riktig 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. Sikkerhetsnettet er innebygd, siden det gamle systemet fortsatt er i drift hvis noe går i stykker. Men det har en pris. Doble lisenser så lenge begge systemene kjører, administratorer som vedlikeholder to systemer, og deltakere som kan bli usikre på hvor de skal logge inn. Parallelldrift passer deg som 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. Ryddigere, billigere, og det tvinger frem beslutninger i stedet for å la dem dra ut i tid. Risikoen er konsentrert, for er noe feil, merker alle det samtidig. Big bang passer deg som har en kompakt kurskatalog, lite pågående aktivitet (sommeren og årsskiftet er populære av gode grunner) og en datamigrering du har validert grundig før byttet.

En praktisk mellomvei mange ender opp med, er big bang for plattformen, med det gamle systemet i lesemodus i noen uker etterpå. Da får du et tydelig «nå har vi flyttet»-øyeblikk, samtidig som historikken er tilgjengelig mens du kontrollerer at alt har landet riktig. 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 opp i fire kategorier, for de flytter på hver sin måte. «Vi flytter alt» er setningen som får prosjektet til å vokse langt forbi estimatet.

Brukerdata og historikk. Kontoer, roller, gruppestrukturer, påmeldinger, fullføringsdata. Strukturen stemmer sjelden én til én mellom to plattformer, så regn med en kartlegging. Det som heter «læringssti» i det gamle systemet, kan hete «kursprogram» i det nye. Det er i kartleggingen feilene gjemmer seg, og det er en jobb den nye leverandøren skal gjøre sammen med deg, ikke delegere 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, er du beskyttet av et komplett og ryddig arkiv.

Kursinnhold. Innhold i standardformater lar seg flytte uten problemer. Spør begge leverandørene direkte om SCORM, xAPI og cmi5 for eksport og import, og test med et ekte kurs før du bestemmer deg. Innhold bygd i den gamle leverandørens egne verktøy kan ofte ikke flyttes i det hele tatt, og det er her migreringer sprekker på tid og budsjett. En migrering er dessuten en sjelden anledning til å legge dødt innhold bak seg, så bruk den. Har ingen rørt et kurs på to år, bør du spørre om det fortjener et nytt liv eller et verdig arkiv.

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.

Mens du kartlegger dataene: hvor kommer de til å bli lagret fysisk etter flyttingen? For europeiske organisasjoner er lagring innenfor EU/EØS stadig oftere et absolutt 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?

Fem rutiner dekker det meste av risikoen for datatap, og alle handler 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 vindu, kommuniser det tydelig og sett administratorendringer i det gamle systemet på pause, slik at du ikke migrerer et bevegelig mål. Det trenger ikke bety nedetid for deltakerne. Med migrering i etapper er vinduet der systemet er utilgjengelig ofte et spørsmål om 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å. Hver eneste diskusjon om hvorvidt en post ble migrert riktig, avgjøres ved å slå 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. Den vanskelige delen er 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. Bruk det. 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 gjør forskjell hver gang:

• 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. En migrering som planlegges uten superbrukerne dine, går glipp av det bare de kjenner til.
• 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 noe å si. Deltakere lytter mer til sin egen leder enn til en prosjektpostkasse. En kort melding lederne kan videresende, pluss ett punkt til teammøtet, når lenger enn noen 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. Et tomt dashbord på dag én bekrefter det hver skeptiker mistenkte.

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 relasjonen 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 ekte prosjektarbeid, men omfang og pris skal stå i avtalen før du signerer, slik at ingenting dukker opp som en overraskelse 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 å forbli det. 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. Det er nettopp i ukene når du flytter dataene og bygger opp det nye miljøet, at du trenger noen som tar telefonen.

Still altså de ubehagelige spørsmålene i salgsprosessen. «Hvem, med navn, hjelper oss med å migrere? Hvor mange uker tok deres siste migrering for en kunde på 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?

Migreringer som går galt, går som regel galt på de samme måtene. I omtrentlig rekkefølge etter hvor ofte de skjer:

1. Å migrere alt. Ti år med utdaterte kurs og inaktive kontoer mangedobler arbeidet og importerer rotet som gjorde det gamle systemet uutholdelig. Migrer det som lever, og arkiver resten.
2. Å hoppe over testmigreringen. Er den reelle migreringen også den første du kjører, oppdager du kartleggingsfeil 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 klumpes sammen med «data», og ingen kontrollerer den før en revisjon gjør det. Gi den et eget spor, egen verifisering og eget arkiv.
4. Å undervurdere integrasjonene. LMS-et migrerer fint, SSO gjør det ikke, og ingen får logget inn på dag én. Test hver kobling i det nye miljøet før byttet.
5. Å gå ut med nyheten før alt er validert. Å fortelle hele organisasjonen «nå er vi i gang!» og så oppdage feil i dataene, koster deg garantert tilliten du trenger i månedsvis fremover.
6. Å mangle en rollback-plan. Dette er feilen nesten ingen migreringsguider nevner, så la oss rette på det nå.

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

En rollback-plan er det som lar deg gå videre med ro i magen. Den består av fire deler.

• Et gjenopprettingspunkt. Den fullstendige eksporten du tok før start (se over), pluss det gamle systemet i drift eller i lesemodus gjennom overgangen. Så lenge de to finnes, kan alle feil rettes.
• Fastsatte stoppkriterier. Bestem på forhånd hva som får deg til å sette på pause eller gå 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, er en forsinkelse bare en e-post.

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. Organisasjoner med en rollback-plan behandler det som en liten forsinkelse. Organisasjoner uten behandler det som en katastrofe, for da har de ofte allerede 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

To ting avslutter en migrering. 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 finner ting ingen skript gjør. 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, for tidlige irritasjoner setter seg fast som «det nye systemet er også dårlig» fortere enn du tror.

Og ha én ting klart for deg. 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 starter en ny implementering, og det er et 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, så snart risikoen har fått et navn, en plass på en liste og en plan. En god migrering er en navngitt liste over risikoer, tatt unna i rekkefølge, med ordentlig hjelp fra leverandøren du flytter til. Vil du først løfte blikket og tenke gjennom hva en læringsplattform i det hele tatt skal gjøre for deg, så gjør det før du begynner. Ta deretter sjekklisten ovenfor, gå gjennom den med teamet, og se hvor mye mindre prosjektet er enn det ser ut utenfra.