I slutten av august fikk jeg en melding fra en kunde som selger billetter til et stort arrangement. Ordresystemet deres, bygget rundt 2012 av en utvikler som ikke lenger var å få tak i, hadde sluttet å virke. Selgerne var midt i høysesong og hadde ingen steder å registrere salg.
Dette er en beskrivelse av hva jeg gjorde, skrevet fra min side av bordet. Ingen kundedata, ingen navn.
Det jeg fikk
En fil på 17 megabyte med endelsen .bak. Det er en sikkerhetskopi fra Microsoft SQL Server: hele databasen, alle tabeller og all historikk. Ingen dokumentasjon, ingen tilgang til det gamle systemet, ingen som kunne forklare hvordan det hang sammen.
I dette prosjektet ga sikkerhetskopien et mer komplett grunnlag enn en enkel eksport til Excel ville gjort.
Dag 1: forstå hva som lå der
Jeg startet SQL Server lokalt på maskinen min, gjenopprettet sikkerhetskopien, og kartla innholdet: 616 kunder, rundt 800 ordre, 1 200 ordrelinjer, 31 brukere, og et eget register over 500 skoler. Pluss alt et system samler på seg over 14 år: felter ingen brukte lenger, tre kunder fra 2015, en vare som het TESTVARE.
Det viktigste den dagen var ikke å flytte noe, men å lage kontrolltall. Antall ordre per år. Sum ordrebeløp per kull. Antall billetter totalt. Tall jeg kunne sjekke mot etter importen, ned til siste krone.
Dag 2: bestemme hva som skulle med
Det nye systemet var allerede bygget, med en ryddigere struktur for opplysningene. Jobben var å koble gammelt til nytt: hvilket felt tilsvarer hva, hvilke statuser blir til hvilke, hvilke fylkesnavn fra 2012 må oversettes til dagens.
Brukerne ble flyttet over, men ikke passordene. Hver bruker fikk et nytt passord i det nye systemet. Administrator satte dem selv, og selgerne kunne bytte passord i kontrollpanelet etterpå. De gamle passordene fra sikkerhetskopien ble ikke brukt.
Dag 3: importere og verifisere
Importskriptet ble skrevet så det kunne kjøres flere ganger uten å lage duplikater. Første kjøring lokalt. Så kontrolltallene: kunder per kull, ordre per år, sum per kull. Alt stemte eksakt.
Nesten. Mine egne kontrolltall hadde en feil: jeg hadde trukket fra tre kunder to ganger. Det tok en time å finne, og det er nøyaktig grunnen til at man lager kontrolltall før man flytter noe. Uten dem hadde jeg ikke visst om feilen lå i importen eller i regnestykket.
Dag 4: produksjon
Demodataene ut, ekte data inn, samme verifisering på nytt mot produksjonsdatabasen. Innlogginger til ledelsen. Selgerne lagt inn, klare til å aktiveres. Systemet var i bruk samme kveld.
Dag 5: det som ikke stemte
Den første tilbakemeldingen kom dagen etter: en selger mente det manglet billetter på ham. Det gjorde det ikke. Det gamle systemet regnet «denne uke» som de siste sju dagene, det nye regnet fra mandag. Salget hans fra fredagen var der, men i feil kolonne. Én liten endring i hvordan ukene beregnes, og tallene stemte igjen.
Én ordre manglet faktisk. Ordren var nyere enn sikkerhetskopien. Den ble kontrollert og lagt inn manuelt.
Hva jeg tar med meg
- Undersøk hvilke kilder som inneholder historikken dere trenger. En full sikkerhetskopi kan være nyttig, men bare nødvendige data skal flyttes.
- Lag kontrolltall før du flytter en eneste rad. De redder deg fra deg selv.
- Importer mindre enn du får. Gamle systemer har samlet på data ingen trenger. Det er ikke din jobb å flytte alt, det er din jobb å flytte det riktige.
- Regn med at noe ser feil ut første uke. Det er som regel en definisjon, ikke en manglende rad.
Selgerne fikk registrere salg igjen før helgen.
Har du et gammelt system som må erstattes? Fortell hva du bruker i dag og hva som ikke fungerer.