Byta LMS: så migrerar du utan att förlora data

Läser du det här har du förmodligen fått nog av ditt nuvarande LMS. Administrationen tar dubbelt så lång tid som den borde. Deltagarna slutade logga in för flera månader sedan. Supportärendena försvinner in i en kö och dyker upp igen en vecka senare, med en länk till en hjälpartikel du redan har läst. Kanske känner du igen ett av problemen, kanske alla tre.

Där är du inte ensam. När Brandon Hall Group undersökte saken 2020 letade 42 % av företagen aktivt efter ett nytt LMS.

De flesta organisationer växer förr eller senare ur sin lärplattform, eller tröttnar helt enkelt på den. Ändå stannar många kvar alldeles för länge, eftersom ett byte känns som ett stort och riskabelt ingrepp. I det gamla systemet ligger flera års genomförandedata, compliance-certifikat, kursinnehåll och integrationer. Tänk om något försvinner på vägen?

Rädslan är befogad, men den går att hantera. En väl planerad LMS-migrering är långt ifrån en chansning. Både riskerna och skyddsåtgärderna är kända, och det finns en tydlig ordning att följa. I den här guiden går vi igenom hur du vet att det verkligen är dags, vilka data du måste skydda, om du ska köra båda systemen parallellt en tid, vad den nya leverantören ska hjälpa dig med och vad du gör om något går fel mitt i flytten.

En sak till innan vi börjar. Du behöver inte välja mellan att härda ut ett år till i det gamla systemet och att lägga sex månader på att bygga upp ett nytt. I verkligheten ser valet inte ut så. Den bilden målas oftast upp av leverantörer vars egna plattformar faktiskt tar sex månader att få igång. Avgränsar du migreringen realistiskt och får ordentlig hjälp av den nya leverantören kan den vara klar på några veckor.

Vilka är tecknen på att det är dags att byta?

Det finns fem signaler du bör ta på allvar, och ingen av dem handlar om en enstaka dålig vecka.

• Dina administratörer har slutat jobba i systemet. Exporterar teamet till kalkylark för att kunna svara på enkla frågor? Har de byggt en egen mappstruktur för att det är hopplöst att hitta innehåll i LMS:et? Då har plattformen redan spelat ut sin roll.
• Deltagarna undviker plattformen. Låga inloggningssiffror, kurser som påbörjas men aldrig avslutas, chefer som jagar genomföranden per mejl. Innan du skyller på plattformen bör du ändå titta noga på om felet sitter i systemet eller i hur det används. Vi har skrivit om precis den frågan i varför ditt LMS inte används. Har du redan rättat till innehållet, kommunikationen och chefernas engagemang och folk ändå ger upp när de möter gränssnittet, då ligger problemet i plattformen.
• Supporten har blivit ett svart hål. Du skickar ett ärende, väntar, eskalerar, väntar igen. Kan du inte nå en människa när något verksamhetskritiskt strular har du fått en risk på halsen som du aldrig bett om.
• Priset stämmer inte längre med hur systemet används. Du betalar för licenser ingen använder, eller får oväntade fakturor för funktioner som borde ha ingått från början.
• Utvecklingen har stannat av. Har det gått ett eller två år utan några uppdateringar värda namnet har leverantören oftast fokus på annat.

Inget av det här är nytt. Redan 2016 visade en undersökning från Brandon Hall Group att 44 % av företagen som använde lärteknik letade efter ett nytt system. Det vanligaste skälet, som 87 % angav, var att de ville ha en bättre användarupplevelse.

Känner du igen tre eller fler av tecknen? Då är frågan inte längre ”ska vi byta?” utan ”hur byter vi säkert?”. Och när du väl ska välja ny plattform, gör det mer noggrant den här gången. Med en strukturerad kravprocess och exitvillkor som garanterar att du får ut din data slipper du stå på exakt samma ställe om tre år. Hur du lägger upp den hittar du i vår guide till kravspecifikation för LMS.

Din checklista för LMS-migrering: ha koll på riskerna innan du flyttar

Kartlägg vad du faktiskt tar med dig innan du tittar på en enda demo. De flesta skräckhistorier om migreringar handlar om ett beroende som ingen upptäckte förrän efter bytet. Gå igenom checklistan först. Allt annat i den här artikeln bygger på den.

Checklistan bygger på sex frågor:

• Data: vad måste flyttas, vad kan arkiveras och vad kan lämnas kvar? Användarkonton, anmälningshistorik, genomförandedata, certifikat, provresultat.
• Innehåll: vilka kurser används aktivt? I vilka format finns de, och går de att exportera i ett standardformat som SCORM, xAPI eller cmi5?
• Integrationer: vilka system är kopplade till ditt LMS i dag? HR-system, single sign-on, kalenderverktyg, rapportflöden. Varje koppling är en egen migreringsuppgift.
• Compliance: vilka underlag är du skyldig enligt lag att spara, och hur länge? Här räknas certifikat och genomförandehistorik som högriskdata (mer om det längre ned).
• Människor: vem behöver informeras, utbildas och övertygas? Administratörer, chefer, deltagare, IT.
• Tidpunkt: finns det utbildningsdeadlines, revisioner eller onboarding-vågor som inte får störas?

Svarar du ärligt på de sex frågorna är du redan bättre förberedd än de flesta organisationer som i efterhand skriver upprörda inlägg om sin migrering.

Parallelldrift eller big bang: vilken migreringsstrategi passar dig?

Du har två grundstrategier att välja mellan, och valet avgör hela riskbilden. Antingen kör du det gamla och det nya systemet sida vid sida under en övergångsperiod, eller så väljer du ett datum och byter allt på en gång. Ingen av strategierna passar alla.

Parallelldrift innebär att deltagarna gör klart pågående kurser i det gamla systemet medan all ny aktivitet startar i det nya. Skyddsnätet är inbyggt, för går något sönder är det gamla systemet fortfarande igång. Men det kostar. Du betalar dubbla licenser under överlappet, administratörerna underhåller två system samtidigt, och deltagarna kan bli osäkra på var de ska logga in. Parallelldrift passar dig som har långa kurser som inte kan avbrytas, strikta compliance-deadlines eller så många deltagare att en dålig lanseringsdag blir dyr.

Big bang innebär att du migrerar, validerar och byter på ett bestämt datum. Det är enklare och billigare, och det tvingar fram beslut som annars gärna skjuts upp. I gengäld samlas hela risken till en enda dag: är något fel märker alla det samtidigt. Big bang passar dig som har en liten kurskatalog, få pågående kurser (det är inte för inte som sommaren och årsskiftet är populära) och en datamigrering du har hunnit validera ordentligt före bytet.

Många landar i en praktisk mellanväg: big bang för själva plattformen, men det gamla systemet kvar i skrivskyddat läge några veckor. Alla vet exakt när flytten sker, och historiken finns kvar att slå upp i medan du kontrollerar att allt har kommit över rätt. Ta inte för givet att det går, utan fråga först leverantören du lämnar vad en skrivskyddad avvecklingsperiod kostar. Det går att förhandla om, och det är ytterligare ett skäl att skriva in exitvillkoren i avtalet redan från början.

Vad följer faktiskt med i flytten: data, certifikat, innehåll, integrationer

Dela upp inventeringen i fyra kategorier, för de flyttas på olika sätt. Planen ”vi flyttar allt” är det säkraste sättet att få projektet att växa långt över vad någon räknat med.

Användardata och historik. Konton, roller, gruppstrukturer, anmälningar, genomförandedata. Två plattformar är sällan uppbyggda på exakt samma sätt, så räkna med att strukturerna måste kartläggas mot varandra. Det som ditt gamla system kallar ”lärväg” kan heta ”kursprogram” i det nya. Felen gömmer sig i kartläggningen, och den ska den nya leverantören göra tillsammans med dig i stället för att skicka över en mall som du får fylla i själv.

Certifikat och genomförandehistorik: din högriskdata. Är utbildningen lagstadgad eller ett krav för certifiering (säkerhetscertifieringar, myndighetskrav, tillstånd att bedriva verksamhet) är underlagen som bevisar att utbildningen har genomförts det mest värdefulla du har i ditt gamla LMS. Försvinner de kan medarbetare tvingas göra om obligatorisk utbildning, eller så underkänns organisationen i en revision den annars hade klarat. Behandla den datan som ett eget delprojekt. Exportera tidigt, i ett format som en revisor accepterar (datum, versioner, vem som genomfört vad), och verifiera exporten oberoende av huvudmigreringen. Även om den nya plattformen inte kan importera vartenda historiskt certifikat har du då ett komplett och välordnat arkiv att luta dig mot.

Kursinnehåll. Innehåll i standardformat går att flytta utan större bekymmer. Fråga båda leverantörerna uttryckligen om SCORM, xAPI och cmi5 för export och import, och testa med en riktig kurs innan du bestämmer dig. Innehåll som byggts i den gamla leverantörens egna verktyg går däremot ofta inte att flytta alls, och där brukar både tidsplan och budget spricka. En migrering är dessutom ett sällsynt tillfälle att rensa bort innehåll som ingen använder, så passa på. Har ingen öppnat en kurs på två år kan du fråga dig om den ska få leva vidare eller arkiveras.

Integrationer. Varje system som är kopplat till ditt LMS måste kopplas om, konfigureras om eller avvecklas. Lista dem, utse en ansvarig för var och en och testa dem i den nya miljön före lanseringen.

Passa också på att ta reda på var din data fysiskt kommer att lagras efter flytten, medan du ändå kartlägger den. För europeiska organisationer är lagring inom EU allt oftare ett absolut krav. Det är ett av skälen till att vi på Learnifier lagrar data på EU-servrar och låter dig välja svensk hosting om datan ska stanna i Sverige. Be att få svaret skriftligt, oavsett vilken leverantör du väljer.

Hur undviker du dataförlust och driftstopp under en LMS-migrering?

Med fem rutiner har du täckt in det mesta av risken för dataförlust, och alla handlar om att ta kopior och kontrollera resultatet.

1. Ta en fullständig export innan du gör något annat. Hämta en komplett export av användare, genomföranden, certifikat och innehåll från det gamla systemet innan migreringsarbetet börjar, och lagra den på ett ställe du själv kontrollerar. Exporten är din försäkring och grunden för en eventuell rollback (mer om det längre ned). Gör det medan det gamla avtalet fortfarande garanterar dig åtkomst.
2. Migrera i etapper och verifiera varje etapp. Användare först, sedan historik, sedan innehåll, sist integrationer. Efter varje etapp kontrollerar du antalen och gör stickprov. Stämmer antalet genomföranden i det nya systemet med exporten? Har tio slumpvis valda deltagare rätt historik? Med små kontrollrundor hittar du felen medan de fortfarande är billiga att rätta.
3. Frys ändringar under det sista migreringsfönstret. Välj en kort period, meddela den tydligt och pausa administratörsändringar i det gamla systemet, så att datan inte ändras medan du flyttar den. Det behöver inte betyda driftstopp för deltagarna. Migrerar du i etapper är systemet ofta bara otillgängligt i några timmar.
4. Skydda pågående kurser. Ingen ska tappa halva sin certifiering bara för att det passade din tidsplan. Låt antingen pågående grupper bli klara i det gamla systemet (argumentet för parallelldrift), eller lägg bytet vid en naturlig svacka i aktiviteten.
5. Behåll det gamla systemet skrivskyddat så länge budgeten tillåter. Det är det billigaste verifieringsverktyg du kan få. Blir det tvist om en post har migrerats rätt räcker det att titta i källan.

Inget av det här är tekniskt svårt. Det kräver bara att du gör saker i rätt ordning och har en ny leverantör som har gjort det förut. Det svåra är att få med sig människorna.

Förändringsledning: hur får du med dig människorna?

En tekniskt felfri migrering kan ändå gå i stöpet på lanseringsdagen, om ingen vill logga in.

Att byta LMS är lättare att sälja in än de flesta IT-projekt, eftersom du oftast ersätter något folk redan ogillar. Utnyttja det. Rubriken ”vi byter system” bryr sig ingen om. Berätta hellre vad som kommer att sluta skava: färre klick för att hitta sin kurs, certifikat som faktiskt går att ladda ner, en plattform som fungerar i mobilen.

Det här brukar göra skillnad:

• Informera administratörerna först och ta med dem tidigt. De vet var liken ligger begravda i det gamla systemet, och det är de som kommer att få svara på allas frågor. En migrering som planeras utan superanvändarna missar sådant som bara de känner till.
• Kommunicera datum som folk kan planera efter. ”Avsluta pågående kurser senast den 15:e. Den nya plattformen öppnar den 20:e. Det gamla systemet går att läsa i till månadsskiftet.” Tre rader räcker.
• Ge cheferna något att säga. Deltagare lyssnar mer på sin egen chef än på en projektbrevlåda. Ett kort meddelande som cheferna kan vidarebefordra och en punkt att ta upp på nästa teammöte når längre än vilken lanseringskampanj som helst.
• Se till att första inloggningen ger något direkt. Det första folk ser i den nya plattformen ska vara relevant för just dem: deras kurs, deras historik, deras nästa steg. En tom startsida första dagen ger alla skeptiker rätt.

Håll också förväntningarna realistiska. Den första veckan blir en del saker annorlunda utan att bli bättre. Säg det i förväg. Det kostar ingenting, och folk har mer tålamod med sådant de har blivit varnade för.

Vilket stöd ska du kräva av din nya leverantör?

Alldeles för få köpare ställer den raka frågan till leverantören: ”Exakt vad kommer ni att göra för oss under migreringen, och vad kostar det?”

Svaren skiljer sig enormt åt, och de säger mycket om vem du är på väg att binda dig till. Migreringsstöd kan delas in i tre nivåer.

• Det som borde vara gratis: en namngiven kontaktperson som ansvarar för din onboarding (inte en ärendekö), hjälp att kartlägga din datastruktur mot den nya plattformen, vägledning om exportformat från det gamla systemet, utbildning för administratörerna, och raka besked om vad som inte går att flytta rakt av. Tar en leverantör extra betalt för grundläggande onboarding-hjälp har du fått en försmak av relationen.
• Det som rimligen kostar: praktisk bulkmigrering av stora innehållsbibliotek, specialbyggda integrationer, ombyggnad av kurser som sitter fast i ett proprietärt format, omvandling av historik utöver standardimporten. Det är riktigt projektarbete och rimligt att betala för, men omfattning och pris ska stå i avtalet innan du skriver på, så att inget dyker upp som en överraskning i månad två.
• Det som är en varningssignal: ”vår dokumentation täcker allt det där”, ingen namngiven person, migreringstjänster enbart via en tredjepartspartner du aldrig har träffat, eller en onboarding-process som förutsätter att du har en projektledare som har tid över.

Hur leverantören beter sig under migreringen säger mer om supporten efteråt än något säljmöte gör. En leverantör som är snabb, mänsklig och generös medan den försöker vinna dig som kund brukar förbli det. En som är långsam innan du ens har skrivit på blir inte snabbare sedan. Därför bygger vi på Learnifier onboardingen kring människor med namn och telefonnummer. Medan du flyttar din data och bygger upp den nya miljön behöver du mer än någonsin någon som svarar när du ringer.

Ställ alltså de obekväma frågorna redan i säljprocessen. Vem hjälper oss med migreringen, och vad heter personen? Hur många veckor tog det i praktiken när ni senast migrerade en kund i vår storlek? Vad ingår, och vad faktureras? Skriv in svaren i avtalet.

Vilka är de vanligaste misstagen vid LMS-migrering?

Misslyckade migreringar går nästan alltid snett på samma sätt. Här är de vanligaste misstagen, med det vanligaste först:

1. Att migrera allt. Tio års föråldrade kurser och inaktiva konton mångdubblar arbetet, och du får med dig röran som gjorde det gamla systemet outhärdligt. Flytta det som används och arkivera resten.
2. Att hoppa över testmigreringen. Är den skarpa migreringen samtidigt din första upptäcker du kartläggningsfelen först i produktion. Gör alltid en provkörning med en del av den riktiga datan och kontrollera resultatet innan du flyttar allt.
3. Att behandla certifikat som en bisak. Compliance-historiken hamnar i samma hög som all annan data, och ingen kontrollerar den förrän revisorn gör det. Hantera den för sig, med egen verifiering och eget arkiv.
4. Att underskatta integrationerna. Själva LMS:et flyttas utan problem, men SSO hänger inte med och första dagen kan ingen logga in. Testa varje koppling i den nya miljön före bytet.
5. Att gå ut med nyheten innan allt är validerat. Berättar du för hela organisationen att ”nu är vi igång!” och sedan hittar fel i datan har du förbrukat förtroende som du kommer att behöva i flera månader.
6. Att sakna en rollback-plan. Nästan ingen migreringsguide tar upp det här misstaget, så vi reder ut det direkt.

Din rollback-plan: tänk om det går fel halvvägs?

Med en rollback-plan kan du gå vidare med lugn i magen. Den består av fyra delar.

• En återställningspunkt. Den fullständiga exporten du tog innan du började (se ovan) och det gamla systemet, igång eller i skrivskyddat läge, under övergången. Så länge du har båda går alla misstag att rätta.
• Bestämda stoppkriterier. Bestäm i förväg vad som får dig att pausa eller backa: genomförandedata som inte stämmer, inloggningsfel över en viss nivå, ett compliance-underlag du inte kan verifiera. Det beslutet är mycket lättare att fatta innan det behövs.
• En beslutsansvarig. En namngiven person med mandat att säga ”vi stoppar, vi rättar och vi försöker igen nästa vecka”. Ska det beslutet gå via en kommitté hinner mycket gå snett innan någon säger stopp.
• En kommunikationsmall. Två färdigskrivna meddelanden: ”vi skjuter upp bytet, här är varför och när” och ”vi är tillfälligt tillbaka i det gamla systemet”. Har du dem färdiga i förväg räcker det att skicka ett mejl om bytet blir försenat.

I praktiken betyder en rollback sällan att du ger upp migreringen. Oftast går du tillbaka till det gamla systemet i några dagar medan du rättar ett kartläggningsfel, och byter sedan igen. Har organisationen en rollback-plan blir det en liten försening. Utan plan blir det en katastrof, eftersom det gamla avtalet då ofta redan har fått löpa ut. Låt uppsägningen av det gamla systemet träda i kraft först när valideringen är klar.

Efter migreringen: validering och de första veckorna

En migrering är klar först när två saker gäller: siffrorna stämmer och folk jobbar faktiskt i den nya plattformen.

Validera innan du firar. Stäm av antal användare, antal genomföranden och antal certifikat mot exporten du tog före migreringen. Gör stickprov på riktiga poster, och låt några administratörer och chefer kontrollera sina egna teams data. De hittar sådant som inget skript hittar. Testa de viktigaste flödena från början till slut: logga in via SSO, anmäl dig till en kurs, genomför den, ladda ner certifikatet och ta fram rapporten som ledningen frågar efter varje kvartal.

Titta sedan på hur användarna reagerar. Hur många loggar in vecka ett och vecka tre? Vilka frågor får supporten oftast? De visar exakt var det behövs en bättre guide eller en genomgång på fem minuter. Hittar cheferna sitt teams framsteg utan att behöva fråga? Rätta småsakerna snabbt. Små irritationsmoment i början växer fortare än du tror till en känsla av att ”det nya systemet är lika dåligt”.

Ha också en sak klar för dig. Migreringen har flyttat din data säkert, men den har ännu inte byggt några nya rutiner, lanserat några nya program eller gett de resultat som var skälet till bytet. Efter migreringen börjar implementeringen, och den behöver en egen plan. Den hittar du i vår checklista för LMS-implementering.

Rädslan som håller organisationer kvar i ett LMS de har vuxit ur är nästan alltid större än den verkliga risken, i alla fall när riskerna väl är listade och har en plan. En bra migrering handlar om att beta av kända risker i tur och ordning, med ordentlig hjälp från den nya leverantören. Behöver du först fundera på vad en lärplattform över huvud taget ska göra för dig? Börja i så fall där. Gå sedan igenom checklistan ovan med teamet, så ser du hur mycket mindre projektet är än det verkar.