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.

Du är 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å blir många kvar långt längre än de borde, för ett byte känns som öppen hjärtkirurgi. I det gamla systemet ligger år av 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. Riskerna är kända, skyddsåtgärderna är kända och ordningen är tydlig. 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 göra för dig, och vad du gör om något går fel halvvägs.

En sak till innan vi börjar. Du behöver inte välja mellan att stå ut ett år till med det gamla systemet och en ombyggnad på sex månader. Så ser valet inte ut i verkligheten, och den bilden målas oftast upp av leverantörer vars plattformar faktiskt tar sex månader att få igång. Avgränsar du migreringen ärligt och får riktig hjälp av leverantören du flyttar till, kan den vara klar på några veckor.

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

Fem signaler är värda att ta på allvar, och ingen av dem handlar om en 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 förlorat.
• Deltagarna undviker det. Låga inloggningssiffror, kurser som påbörjas men aldrig avslutas, chefer som jagar genomföranden per mejl. Men titta noga på om felet sitter i systemet eller i hur det används, innan du skyller på plattformen. Vi har skrivit om precis den frågan i varför ditt LMS inte används. Har du rättat till innehåll, kommunikation och chefernas engagemang, och folk ändå ger upp i gränssnittet, är det plattformen som är problemet.
• Supporten har blivit ett svart hål. Du skickar ett ärende, väntar, eskalerar, väntar igen. När du inte får tag på en människa för något som är verksamhetskritiskt sitter du med en risk 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 överraskningsfakturor för funktioner som borde ingå från början.
• Utvecklingen har stannat av. Ett eller två år utan uppdateringar värda namnet betyder oftast att leverantören har blicken någon annanstans.

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

Känner du igen tre eller fler av tecknen? Då kan du sluta fråga ”ska vi byta?” och börja fråga ”hur byter vi säkert?”. Och när du väl kommer fram till valet, välj mer omsorgsfullt den här gången. En strukturerad kravprocess, med exitvillkor som garanterar att du får ut din data, är det som räddar dig från att 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.

Kärnfrågorna som checklistan täcker:

• 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: vad pratar med 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? Det är här certifikat och genomförandehistorik blir högriskdata (mer om det längre ned).
• Människor: vem behöver informeras, utbildas och vinnas över? Administratörer, chefer, deltagare, IT.
• Tidpunkt: finns det utbildningsdeadlines, revisioner eller onboarding-vågor som inte får störas?

Svarar du uppriktigt på de sex frågorna har du redan förberett dig bättre ä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 en så stor deltagarbas att en dålig lanseringsdag blir dyr.

Big bang innebär att du migrerar, validerar och byter på ett bestämt datum. Det är renare och billigare, och det tvingar fram beslut som annars gärna drar ut på tiden. Risken är i gengäld koncentrerad. Är något fel märker alla det samtidigt. Big bang passar dig som har en kompakt kurskatalog, låg pågående aktivitet (sommaren och årsskiftet är populära av goda skäl) 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. Du får ett tydligt ”nu har vi flyttat”-ögonblick, samtidigt som historiken finns kvar att slå upp i medan du kontrollerar att allt har landat rätt. Fråga leverantören du lämnar vad en skrivskyddad avvecklingsperiod kostar innan du utgår från att det går. Det är en förhandlingsfråga, och ännu ett skäl till att exitvillkoren ska stå i avtalet från dag ett.

Vad som faktiskt flyttar med dig: data, certifikat, innehåll, integrationer

Dela upp inventeringen i fyra kategorier, för de flyttas på olika sätt. ”Vi flyttar allt” är den plan som får projektet att bli mycket större än någon räknat med.

Användardata och historik. Konton, roller, gruppstrukturer, anmälningar, genomförandedata. Strukturen matchar sällan ett-till-ett mellan två plattformar, så räkna med en kartläggning. Det som ditt gamla system kallar ”lärväg” kan heta ”kursprogram” i det nya. Det är i kartläggningen felen gömmer sig, och det är ett arbete den nya leverantören ska 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 genomförande det mest värdefulla som finns 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 är ett komplett och välordnat arkiv ditt skydd.

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 det är där tid och budget spricker. En migrering är dessutom ett sällsynt tillfälle att lämna dött innehåll bakom sig, så ta det tillfället. Har ingen rört en kurs på två år, fråga dig om den förtjänar ett nytt liv eller ett värdigt arkiv.

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 innan lansering.

Medan du kartlägger datan bör du också ställa lagringsfrågan: var kommer din data fysiskt att lagras efter flytten? 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. Vilken leverantör du än väljer, be om svaret skriftligt.

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

Fem rutiner täcker det mesta av risken för dataförlust, och alla handlar om kopior och verifiering.

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. Ögonblicksbilden ä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? Små kontrollrundor fångar fel medan de fortfarande är billiga att rätta.
3. Frys ändringar under det sista migreringsfönstret. Välj ett kort fönster, kommunicera det tydligt och pausa administratörsändringar i det gamla systemet, så att du inte migrerar ett rörligt mål. Det behöver inte betyda driftstopp för deltagarna. Migrerar du i etapper handlar den tid systemet är otillgängligt ofta om 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å. Varje tvist om huruvida en post har migrerats rätt avgörs genom att titta i källan.

Inget av det här är tekniskt svårt. Det som krävs är rätt ordning och en ny leverantör som har gjort det förut. Det svåra är 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. Använd 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.

Några saker som konsekvent gör 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 chefer kan vidarebefordra, plus en punkt att ta upp på nästa teammöte, når längre än någon lanseringskampanj.
• 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 dag ett bekräftar varje skeptikers misstanke.

Håll också förväntningarna realistiska. Vissa saker blir annorlunda utan att bli bättre under den första veckan. 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 gifta dig med. 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. Det är därför vi på Learnifier sätter människor, med namn och telefonnummer, i centrum av onboardingen. Veckorna när du flyttar din data och bygger upp din nya miljö är precis de veckor då du behöver någon som svarar när du ringer.

Ställ alltså de obekväma frågorna redan i säljprocessen. Vem, med namn, hjälper oss att migrera? Hur många veckor tog er senaste migrering av en kund i vår storlek, i praktiken? Vad ingår, och vad faktureras? Skriv in svaren i avtalet.

Vilka är de vanligaste misstagen vid LMS-migrering?

Migreringar som misslyckas gör det på samma få sätt. De vanligaste först:

1. Att migrera allt. Tio år av föråldrade kurser och inaktiva konton mångdubblar arbetet och tar med sig röran som gjorde det gamla systemet outhärdligt. Migrera det som lever och arkivera resten.
2. Att hoppa över testmigreringen. Är den skarpa migreringen också din första upptäcker du kartläggningsfelen i produktion. Gör alltid en provkörning med en delmängd riktig data, och verifiera den innan hela flytten.
3. Att behandla certifikat som en bisak. Compliance-historiken klumpas ihop med ”data” och ingen kontrollerar den förrän en revision gör det. Ge den ett eget spår, en egen verifiering och ett eget arkiv.
4. Att underskatta integrationerna. LMS:et migrerar fint men SSO hänger inte med, och dag ett 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 trasig data har du bränt förtroende som du behöver i månader framöver.
6. Att sakna en rollback-plan. Det här är misstaget nästan ingen migreringsguide nämner, så vi reder ut det direkt.

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

En rollback-plan är det som gör att du kan gå vidare med lugn i magen. Den består av fyra delar.

• En återställningspunkt. Den fullständiga exporten du tog innan start (se ovan), plus det gamla systemet igång eller i skrivskyddat läge under övergången. Så länge de två finns går varje 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 de två skrivna i förväg blir en försening ett mejl att skicka.

I praktiken betyder en rollback sällan att migreringen överges. Oftast går du tillbaka till det gamla systemet i några dagar medan ett kartläggningsfel rättas, och byter sedan igen. Organisationer med en rollback-plan behandlar det som en liten försening. Organisationer utan plan behandlar det som en katastrof, för då har de ofta redan låtit det gamla avtalet 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

Två saker avslutar en migrering: 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. Inloggningar vecka ett och vecka tre. Vilka frågor supporten får oftast, för de visar exakt var det behövs en bättre guide eller en genomgång på fem minuter. Om cheferna hittar sitt teams framsteg utan att behöva fråga. Rätta småsakerna snabbt. Tidiga irritationer stelnar till ”det nya systemet är också dåligt” fortare än du tror.

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 en ny implementering, och det är ett projekt som förtjänar 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, när risken väl har fått ett namn, hamnat på en lista och fått en plan. En bra migrering är en lista med namngivna risker som betas av i ordning, med riktig hjälp från leverantören du flyttar till. Behöver du först fundera på vad en lärplattform över huvud taget ska göra för dig, börja där. Ta sedan checklistan ovan, gå igenom den med teamet och se hur mycket mindre projektet är än det ser ut utifrån.