Datamigrering är processen att flytta data från ett system till ett annat på ett kontrollerat sätt. Den här guiden ger dig som är projektledare eller CTO en praktisk genomgång av processen, steg för steg, så att du kan planera bytet med full kontroll över er data.
Vad innebär datamigrering i praktiken?
När data flyttas vid ett affärssystembyte handlar det om att flytta befintlig data från den gamla till den nya miljön. Det kan röra sig om information kopplad till:
Kunder
Leverantörer
Artiklar
Fakturor
Kontoplan
Historik
Målet är att säkerställa att informationen är korrekt, fullständig och användbar när ni väl går live. Tänk på migration av data som att flytta. Varje föremål måste packas, märkas och placeras på rätt plats i det nya hemmet. Utan en tydlig strategi hamnar hälften av grejerna i fel rum.
Som Hallands äldsta IT företag har vi många gånger stött på system med eftersatt registervård. Ofta kommer vi till kunder som har underskattat hur komplex deras data faktiskt är. Först när de öppnar systemet inser de att kundregistret innehåller tre versioner av samma kund.
Vad är skillnaden mellan datamigrering och datakonvertering ?
Migrering innebär att flytta data mellan system. Konvertering innebär att omvandla data från ett format till ett annat. Vid ett affärssystemsbyte sker oftast båda. När ni flyttar kundregistret från ett äldre system till Pyramid affärssystem migreras informationen, men eftersom fältstrukturen skiljer sig åt konverteras datan samtidigt.
Vad händer rent praktiskt under en datamigrering?
Processen följer tre faser som IT-branschen kallar ETL:
Extract
Transform
Load
Data extraheras ur det gamla systemet, transformeras till rätt format och struktur, och laddas sedan in i det nya. Varje fas kräver rätt verktyg, rätt kompetens och tillräckligt med tid. Resten av den här guiden går igenom varje steg i detalj.
Steg 1 – Kartläggning: Förstå er data innan den flyttas
Kartläggningen är det viktigaste steget i hela projektet. Det är här eventuella problem uppstår och kan förebyggas. Innan data flyttas måste ni veta vad ni har.
Vad finns det för typer av data?
Er data delas in i tre kategorier med olika prioritet:
Masterdata: huvudregister som kunder, leverantörer, artiklar och kontoplan. Långlivad, förändras sällan. Ska alltid med.
Transaktionsdata: den löpande verksamheten. Hit kategoriseras fakturor, ordrar, betalningar och journalposter. Stora volymer. Ska oftast med.
Historik: tidigare räkenskapsår, arkiverade kunder och gamla projekt. Ska med selektivt.
Rätt prioritering sparar tid och resurser samtidigt som de sänker risken för att ni tar med er data ni inte behöver. Det blir som en vårstädning.
Vilken data måste ni enligt lag behålla?
Bokföringslagen (7 kap.) kräver att räkenskapsinformation sparas i 7 år efter det kalenderår då räkenskapsåret avslutades. Det påverkar direkt hur ni hanterar historiken vid ett ERP-systembyte.
Den praktiska konsekvensen är tydlig. De flesta företagen väljer att arkivera äldre räkenskapsår via export till SIE-fil eller PDF, snarare än att migrera in dem i det nya systemet. Det minskar projektets komplexitet och håller databasen snabb. Bokföringsnämnden (BFN) är den auktoritativa källan för frågor om arkiveringskrav.
Här vill vi av erfarenhet flagga en väldigt viktig detalj som bolag tenderar att missa. Om er bokföring ligger i molnet och ni byter leverantör måste ni säkerställa att räkenskapsinformationen exporteras och bevaras innan avtalet avslutas. Flera av de projekt vi kliver in i sent har just det problemet: data som låg på en server hos den gamla leverantören och riskerade att försvinna när avtalet sades upp.
Vad finns det för metoder för datamigrering?
Big bang: allt migreras vid ett och samma tillfälle, ofta över en helg. Det är snabbt men riskabelt. Passar mindre företag med enkel datamiljö.
Fasad migrering: moduler eller avdelningar migrerar en i taget. Lägre risk, längre projekttid. Passar mellanstora företag.
Parallell drift: gamla och nya systemet körs samtidigt under en period. Tryggast men resurskrävande. Passar större organisationer med komplex drift.
Valet av strategi beror på datamängd, hur kritisk den löpande driften är och er risktolerans. Givetvis kan vi på DH Solutions hjälpa er att välja den rätta strategin.
Frågor att besvara innan migreringen börjar
Svaren på dessa frågor styr hela projektet:
Vilken data är affärskritisk – och vilken är nice-to-have?
Vem i teamet äger datakvaliteten idag?
Vilka integrationer hämtar data från det gamla systemet?
Vilka anpassningar finns i det gamla systemet som inte syns i en standardexport?
Vilken historik måste ni behålla enligt bokföringslagen?
Vem godkänner den migrerade datan innan go-live?
Vad är er plan om något går fel?
Steg 2 – Datarensning: Flytta rätt data, inte all data
Garbage in, garbage out. Vi vet att dålig data gör att det nya systemet levererar dåliga rapporter från dag ett. Datamigreringen är det perfekta tillfället att städa, och den möjligheten bör ni ta.
Varför kvalitet går före kvantitet när data flyttas
Dålig data tar sig ofta formen av dubbletter, artiklar som inte säljs längre, leverantörer som inte funnits på fem år och kontoplaner med oanvända konton. Det är inte ovanligt att vi i kartläggningsfasen hittar kundregister där 30–40 procent av posterna är inaktiva eller dubbletter.
Det resulterar i två negativa saker. För det första försämras rapportkvaliten. Därutöver innebär skräpdata även högre licenskostnader i system som prissätter per registerpost eller aktiv användare.
Vad innebär dataminimering enligt GDPR?
Dataminimering är en av GDPR:s grundprinciper, fastställd i artikel 5.1 c i dataskyddsförordningen: personuppgifter ska vara adekvata, relevanta och begränsade till vad som är nödvändigt för ändamålet. Vid en datamigrering aktualiseras principen direkt.
Konkret innebär det att ni inte får migrera personuppgifter ”för säkerhets skull”. Inaktiva kundkontakter, gamla anställdas uppgifter och kontaktpersoner hos avslutade leverantörer ska som utgångspunkt inte följa med till det nya systemet. Integritetsskyddsmyndigheten (IMY) är tillsynsmyndighet och auktoritativ källa för frågor om GDPR-tillämpning i Sverige.
Praktiska steg för säker hantering av personuppgifter
Inventera vilka personuppgifter som finns i det gamla systemet
Bedöm vilka som är nödvändiga i det nya systemet utifrån ert faktiska behov
Radera eller anonymisera information ni inte behöver ta med
Dokumentera era beslut – GDPR:s ansvarsskyldighetsprincip (artikel 5.2) kräver att ni kan visa att ni hanterat datan korrekt
Säkerställ att migreringen sker på ett säkert sätt som skyddar informationen mot obehörig åtkomst
Uppdatera system- och registerdokumentationen
Steg 3 – Mappning: Definiera exakt hur data flyttas till rätt plats
Mappning är avgörande vid migration av data mellan affärssystem. Definiera exakt hur fält i det gamla systemet ska hanteras i det nya. Det är ett metodiskt arbete som kräver både systemkunskap och verksamhetsförståelse.
Vad ska en mappningstabell innehålla?
En mappningstabell specificerar källa, mål och transformationsregel för varje datafält. Till exempel: kundnummer i det gamla systemet är ett 5-siffrigt heltal, men i det nya är det ett alfanumeriskt fält med upp till 10 tecken. Transformationsregeln styr hur konverteringen sker.
Genom åren har vi bland annat sett följande problem med felaktiga mappningstabeller:
Fält som saknas i det nya systemet
Data i fel format
Obligatoriska fält som saknar värden i källsystemet
Inkonsekventa datavärden som blandat versaler, saknade postnummer och ofullständiga adresser.
Involvera mer än bara IT-teamet
Mappningsdokumentet ska granskas och godkännas av de som faktiskt arbetar i systemet. Det är ett mycket bra sätt att öka sannolikheten att produktivitetsvinster låses upp när ni väljer att implementera ett nytt affärssystem.
En säljare vet vilka kundkategorier som används i praktiken. Era lagermedarbetare vet vilka artikelattribut som är affärskritiska. Utan deras input riskerar ni att missa beroenden som inte syns i en export.
Det är en lärdom vi tagit med oss från projekt där mappningen gjorts enbart av IT. Tar man inte med alla användare i implementations- och planeringsstadierna dyker felen upp direkt när bolaget börjar arbeta operativt i det nya affärssystemet.
Steg 4 – Testning och validering: Kontrollera att data flyttas korrekt
Testning är det steg som sparar mest pengar. Tyvärr ser vi om och om igen att företag tidspressas och väljer att skära ner i det här steget av processen. Att migrera data direkt till produktionsmiljön utan att testa är ett av de vanligaste och mest kostsamma misstagen i hela processen.
Testa datakvalitén: så validerar ni att migreringen fungerar
Genomför minst två–tre testmigrationer innan go-live. Varje test validerar att datan är korrekt, fullständig och att beräkningar stämmer. Kontrollera bland annat att:
Kundregister, artikelregister och kontoplan är fullständiga
Öppna fakturor och obetalda poster stämmer mot det gamla systemet
Belopp, momskoder och valutainformation är korrekta
Integrationer mot externa system fungerar som förväntat
Den ekonomiansvarige ska signera valideringen av ekonomidata innan projektet tillåts gå vidare. Det är inte ett formkrav, det är en säkerhetsventil som fångar fel som annars syns först i månadsrapporten. För att effektivisera processen kan vi med fördel hjälpa er att använda smarta AI-system.
Steg 5 – Go-live: När data är på plats i det nya systemet
Go-live är inte slutet på projektet, det är början på stabiliseringsfasen.
Planera go-live och hantera eventuella problem snabbt
Ni vill inte gå live med ert nya affärssystem och migrera data när affärerna är som mest intensiva. Välj en period med låg affärsaktivitet.
Vår rekommendation är att ha en tydlig plan för rollback. Om något går allvarligt fel ska teamet veta exakt vad som krävs för att återgå till det gamla systemet och hur länge det alternativet är öppet.
De första 2–4 veckorna efter go-live kräver tätare support än normalt. Användare stöter på situationer som inte täckts i utbildningen. Integrationer beter sig annorlunda med riktiga datavolymer.
Vi har alltid en utsedd kontaktperson som kan svara snabbt under den här perioden. Våra kunder kommenterar ofta att det är något som gjorde stor skillnad i övergången till affärssystemet Pyramid under vår tillsyn.
Vanliga misstag som skapar problem vid datamigrering
De flesta migreringsprojekt som går fel, gör det av samma anledningar.
Hoppa över kartläggningen – data flyttas utan att teamet vet vad som finns. Resultatet blir kaos i det nya systemet från dag ett.
Underskatta registervården – tumregel: registervård tar 2–3 gånger längre tid än beräknat. Bygg in det i projekttiden.
Ta med allt – ”allt ska med”-mentaliteten fyller det nya systemet med 15 år av inaktiva kunder och oanvända artiklar. Var modig – radera.
Testa för lite – utan torra körningar vet ni inte vad som väntar vid go-live. Validering är inte valfritt.
Glömma integrationer – integrationer mot externa system som lön, e-handel och BI är ofta det som fallerar sist och kostar mest att laga.
Inte involvera operativa användare – de vet vilken data som faktiskt används. Involvera dem redan i kartläggningsfasen, inte bara i utbildningen.
Vi har även skapat en artikel där vi går igenom sju vanliga misstag vid byte av affärssystem. Vi rekommenderar att ni även läser den.
Så hjälper DH Solutions er med datamigreringen till Pyramid Business Studio
DH Solutions har sedan 1972 hjälpt företag i Halland och Sverige att genomföra affärssystemsbyten. Vår migreringsprocess är definierad i sju steg, från workshop för kartläggning till avslutsrapport, och bygger på erfarenheter från projekt i allt från tillverkande industri till tjänsteföretag.
Pyramid Business Studio hanterar standardimportformat som CSV, XML och SIE, vilket underlättar migreringen oavsett vilket äldre system ni kommer ifrån.
Vanliga frågor om datamigrering
Vad är datamigrering?
Datamigrering är processen att flytta data från ett affärssystem till ett annat på ett kontrollerat sätt. Det innefattar extrahering ur det gamla systemet, transformation till rätt format, och inläsning i det nya – med validering i varje steg.
Vilka är stegen i en datamigrering?
En datamigrering följer fem huvudsteg: kartläggning av befintlig data, registervård och dataminimering, mappning av fält mellan systemen, testning via torra körningar, och go-live med efterföljande stabilisering.
Hur lång tid tar en datamigrering vid byte av affärssystem?
Datamigreringen och registervården vid ett affärssystemsbyte har en betydande del av projektet för ett lyckat slutresultat. Det är viktigt att inte underskatta tiden!
Vad kostar en datamigrering?
För en typisk SMB ligger kostnaden på 20-30% av den totala projekttiden. Kostnaden styrs av datamängd, systemkomplexitet och vald migreringsmetod. Mycket av arbetet ligger direkt på kunden och det är deras insats som avgör stort vad migreringskostnaden landar på.
Vad är skillnaden mellan datamigrering och datakonvertering?
Datamigrering innebär att flytta data från ett system till ett annat. Datakonvertering innebär att omvandla data från ett format till ett annat. Vid ett affärssystembyte sker oftast båda samtidigt.
Är datamigrering säker?
Ja, om den planeras och testas. Riskerna är reella men hanterbara med rätt process: kartläggning, datarensning, mappning, testkörningar, validering och en tydlig plan för en eventuell rollback.
Vad är en migreringschecklista?
En migreringschecklista är en strukturerad lista över vad som måste vara klart före, under och efter migrationen. Den täcker kartläggning, datarensning, GDPR-granskning, mappning, testning, go-live-plan och hyper-care – och fungerar som projektets styrverktyg.
