Den gode datakonvertering

Overordnede principper:

1. Konverteringer køres først på testmiljøerne så disse følger de normale udviklingstrin
2. Konverteringer skal kunne køres i chunks
3. Konverteringer skal som udgangspunkt kunne køres på produktionsmiljøet ved release, dvs. at konverteringen skal kunne køre på under en time.
   1. => Konverteringer der tager tængere tid skal planlægges til at kunne køre efter release
4. Konverteringer skal varsles til de eksterne parter, disse beskrives overordnet som led i en Epic og i detaljer via Konverteringsdrejebog
5. Tidligere data flyttes til anden database, så disse fjernes fra produktionsdatabasen

Følgende problematikker skal overvejes:

1. Er der eksterne parter der bliver ramt af konverteringen?
   1. => Skal der foretages en fælles test?
   2. => Skal der modtages data fra eksterne før/efter konverteringen?
2. Skal der udsendes WSRM'er?
   1. => Skal det være en programmeret konvertering (eller kan SQL scripts klare opgaven?)
3. Backup af tidligere data?
4. Oprydning efter konvertering?
5. Mapning mellem nye og gamle nøgler
   1. => Hvordan mapper de eksterne aftagere?
6. Skal der etableres et særskilt konverterings-testmiljø?
7. Skal der kunne udsendes kontrollister til Jobcentre / A-kasser?
8. Hvordan testes konverteringen?
   1. => Stikprøver?
   2. => Optællinger?

Leverance til SF for konverteringsopgaven:

1. Konverteringsdrejebog
   1. => Skal deles med de eksterne parter
2. Konverteringsscripts / programmer
3. Beskrivelse af berørte data (berørte tabeller)
4. Hvordan foretages backup?
5. Køretid for konverteringen

Implementeringsovervejelser:

1. Hvis et clustred index skal udvides, er det performancemæssigt bedre at oprette en skyggetabel og kopiere data over i denne end at konvertere modertabellen
2. Tilføjes der ekstra kolonner, skal det overvejes om der er behov for indeksering af disse
3. Bulk inserts kan overvejes hvis konvertering kan klares via sql-scripts.