Modul 3 · 3.3
En migrationsplan: rækkefølge, risici og tilbagefald
Modul 3: Kortlægning og planlægning · Læsetid: 12 minutter
Læringsmål: Efter denne lektion kan du udarbejde en migrationsplan med faser i den rigtige rækkefølge, en risikoliste, et go/no-go-tidspunkt og en tilbagefaldsplan.
Nøglebegreber: migrationsplan, fase, pilot, big bang, trinvis overgang, afhængighed, TTL, fryse-tidspunkt, overgangsperiode, risikoliste (sandsynlighed og konsekvens), go/no-go, tilbagefaldsplan (rollback), opsigelse
Hvorfor en plan?
Med din kortlægning (lektion 3.1) og dine tal (lektion 3.2) ved du, hvad der skal ske. En migrationsplan fortæller i hvilken rækkefølge, hvornår, af hvem, og hvad du gør, hvis noget går galt. Den forebygger de to klassiske fejl: at gøre tingene i forkert rækkefølge (at ændre MX, før de nye postkasser findes) og at opsige den gamle tjeneste for tidligt.
Big bang eller trinvis?
Der er to hovedruter.
| Rute | Hvad det er | Egnet til | Risiko |
|---|---|---|---|
| Big bang | Alt flyttes på ét tidspunkt, for eksempel i en weekend | Mindre organisationer med få koblinger | Hvis noget går galt, går det galt alle steder på én gang |
| Trinvis | Flyttes del for del eller gruppe for gruppe, fordelt over uger | Større organisationer eller mange koblinger | I en periode kører to systemer ved siden af hinanden; folk bliver forvirrede |
For de fleste mindre organisationer fungerer en trinvis overgang pr. del godt: først filer, derefter kalender og kontakter, så mail, og til sidst resten. Mail flyttes samlet for alle på én gang, fordi domænet kun kan pege ét sted ad gangen.
Begynd altid med en pilot: én eller to personer, der allerede bruger den nye tjeneste til alt, i en uge eller to. De finder problemerne, så du kan justere planen, før resten følger efter.
Faserne
En migration har fem faser.
1. Forberedelse
- Kortlægning og tal på plads (lektion 3.1 og 3.2).
- Ny tjeneste valgt, kontrakt og databehandleraftale underskrevet (lektion 2.4, 9.2).
- Eksport eller backup af alt fra den gamle tjeneste, før du ændrer noget. Det er dit sikkerhedsnet.
- Ryddet op i det, der kan fjernes.
- Brugere og administratorer oprettet i den nye tjeneste, totrinsbekræftelse (2FA) slået til (lektion 7.3).
- TTL'en for dine MX-poster er sat ned, for eksempel til 300 sekunder. Gør det mindst én gammel TTL-periode før skiftet. Stod TTL'en på 86400 sekunder (et døgn), så sæt den ned mindst et døgn i forvejen (DNS-kursus lektion 6.1 og 6.3).
2. Pilot
- Én eller to personer går over.
- Du tester de sværeste dokumenter, telefon-apps og koblinger.
- Du skriver snydeseddel og forklaring til resten (lektion 9.1).
3. Overflytning
- Filer kopieres; mapper og delinger indrettes på ny (lektion 6.1, 6.2).
- Kalendere og kontakter eksporteres og importeres (lektion 5.2, 5.3).
- Postkasser kopieres en første gang, mens den gamle postkasse stadig modtager mail som normalt (lektion 4.2).
- Koblinger ændres: hjemmeside, scanner, kasseapparat, software.
4. Overgang
- På det aftalte tidspunkt: MX-posterne ændres, SPF, DKIM og DMARC opdateres (lektion 4.3).
- Kort efter, og igen en dag senere: postkasserne kopieres endnu en gang, så mail der i mellemtiden er kommet ind hos den gamle tjeneste, også følger med (lektion 4.4).
- Alles enheder omstilles; gamle synkroniserings-apps slukkes (lektion 7.2).
- Et fryse-tidspunkt for filer: fra det tidspunkt arbejder ingen længere i det gamle lager.
5. Afslutning
- Kontrol: optælling af mapper, filer, aftaler, kontakter og mail.
- Lad begge systemer eksistere ved siden af hinanden i et par uger, det gamle kun som læsning hvis muligt.
- Først derefter opsiges den gamle tjeneste, og du beder om bekræftelse på, at dine data slettes dér (lektion 9.3).
- Fortegnelse over behandlingsaktiviteter og privatlivspolitik opdateres (lektion 9.3).
Afhængigheder du ikke må bytte om
Nogle trin skal virkelig ske i rækkefølge. Det er de faste regler:
- Eksport eller backup af den gamle tjeneste sker før enhver ændring.
- Pilotten sker før udrulningen til alle.
- Postkasserne i den nye tjeneste findes før du ændrer MX. Ellers afviser den nye server mailen.
- TTL'en er sat ned mindst én gammel TTL-periode før MX-skiftet.
- Den første kopi af mailen er lavet før MX-skiftet; den anden kopi efter MX-skiftet.
- Kalenderne er importeret før du kobler telefonerne til. Ellers synkroniserer telefonen midt i en import, og du får dubletter.
- Den gamle tjeneste opsiges til sidst, efter kontrollen.
Opgave A3.3 lader dig selv lave denne rækkefølge og kontrollerer den.
Risici: sandsynlighed gange konsekvens
En risikoliste opstiller, hvad der kan gå galt, hvor sandsynligt det er, og hvor alvorligt det er. Scor sandsynlighed og konsekvens for eksempel fra 1 til 3 og gang dem sammen. Alt med en score på 6 eller 9 får en foranstaltning.
| Risiko | Sandsynlighed | Konsekvens | Score | Foranstaltning |
|---|---|---|---|---|
| Mail kommer ikke frem under skiftet | 2 | 3 | 6 | TTL sat ned i forvejen, skifte uden for spidsbelastning, anden synkronisering |
| Dokumenter med makroer virker ikke | 3 | 2 | 6 | Testsæt i pilotten (lektion 6.5), Excel kører midlertidigt ved siden af |
| Kolleger fortsætter med at arbejde i det gamle lager | 3 | 2 | 6 | Fryse-tidspunkt, gammelt lager kun læsbart, forklaring |
| Telefon viser alt dobbelt | 2 | 1 | 2 | Først importere, derefter koble til; gammel konto slukket |
| Kasseapparat virker ikke efter nedlukning af konti | 2 | 3 | 6 | Eget login før nedlukning (lektion 2.3) |
| Kontrakten med den gamle tjeneste fortsætter automatisk | 2 | 2 | 4 | Opsigelsesdato i kalenderen |
Go/no-go og tilbagefaldsplan
Aftal på forhånd hvem, der beslutter på tidspunktet for MX-skiftet, og på hvilket grundlag. Et go/no-go-tidspunkt med en kort tjekliste: alle postkasser oprettet og testet, første kopi klar, TTL lav, pilot uden store problemer, kolleger informeret. Er bare ét af disse punkter ikke grønt: gå ikke videre, og vælg en ny dato. Det føler sig som et nederlag, men det er præcis det, tidspunktet er til for.
En tilbagefaldsplan (rollback) beskriver, hvordan du går tilbage, hvis det alligevel går galt efter skiftet. Ved mail er det forholdsvis enkelt, så længe den gamle tjeneste stadig findes: sæt MX-posterne tilbage til de gamle værdier (dem har du noteret på forhånd, eller du har lavet en DNS-backup), og kopiér den mail, der i mellemtiden er kommet ind hos den nye tjeneste, tilbage. Det kan kun lade sig gøre, hvis du ikke allerede har opsagt den gamle tjeneste. Derfor opsiger du den til sidst.
Planlægning i tid
Et eksempel for bageriet, med tolv personer:
| Uge | Hvad |
|---|---|
| 1 | Kortlægning, tal, valg, kontrakt; eksport fra gammel tjeneste |
| 2 | Oprettelse af brugere, 2FA, pilot med to personer; TTL sat ned ved ugens slutning |
| 3 | Filer og kalendere flyttes; første mailkopi; koblinger ændres |
| 4 | Mandag morgen tidligt: MX-skifte; samme dag og tirsdag anden kopi; enheder omstilles |
| 5 | Kontrol, spørgetimer |
| 6 til 8 | Begge ved siden af hinanden; derefter opsigelse af gammel tjeneste, opdatering af fortegnelse |
Vælg bevidst tidspunktet for skiftet. Ikke lige før en travl periode (for et bageri ikke ugen før helligdagene), ikke når administratoren tager på ferie, og med tid til at løse problemer dagen efter.
I praksis: sådan ser det ud hos en udbyder
Vejledningen til WebOké Nextcloud angiver en fast rækkefølge: først oprette brugere og gøre kontoen sikker, så filer, så kalendere og kontakter, derefter først apps, og den gamle tjeneste opsiges først, når alt er på plads. Til mail bruger Værktøj til flytning af e-mail en første kopi før og en anden kopi efter MX-skiftet. Andre europæiske udbydere anbefaler stort set samme rækkefølge, fordi den følger af, hvordan mail og synkronisering fungerer.
Opsummering
- En migrationsplan fastlægger rækkefølge, tid, ansvarlige og tilbagefald.
- Trinvis pr. del, med en pilot i forvejen, fungerer for de fleste mindre organisationer; mail flyttes for alle på én gang.
- Fast rækkefølge: eksport først, pilot før udrulning, postkasser og lav TTL før MX-skiftet, anden kopi derefter, import før kobling, opsigelse til sidst.
- En risikoliste med sandsynlighed og konsekvens viser, hvor du har brug for foranstaltninger.
- Et go/no-go-tidspunkt og en tilbagefaldsplan gør det trygt også at sige "endnu ikke".
Quiz
Opgave
Opgave A3.3: Sæt trinene i den rigtige rækkefølge. Du får atten trin fra en migration i tilfældig rækkefølge. Sæt dem i en rækkefølge, der fungerer. Programmet kontrollerer de faste regler fra denne lektion og fortæller præcis, hvilken regel du bryder.
Opgave E3.3: Din egen migreringsplan. Lav med skabelonen en migrationsplan for din egen organisation: faser med datoer, ansvarlige, en risikoliste med mindst fem risici, en go/no-go-tjekliste og en tilbagefaldsplan.
Opgave E3.3: Din egen migreringsplan
Udfyld skabelonen ud fra din oversigt (A3.1/E3.1) og dine tal (E3.2), og få en kollega til at læse den igennem.
Dine afkrydsninger og noter forbliver kun i denne browser; vi sender dem ingen steder hen. Er du logget ind, gemmer vi kun i Mine kurser, at du har udført opgaven.
Læs mere
Trinene i disse artikler gælder for WebOkés tjenester; hos andre udbydere fungerer det på lignende vis.
- Nextcloud-vejledning 13.1: Forberedelse: hvad tager du med, og i hvilken rækkefølge
- Nextcloud-vejledning 13.6: Fra Microsoft 365 til WebOké: filer, dokumenter, mail og kalender
- Flyt domæne, hjemmeside og e-mail samlet uden afbrydelser: trin for trin-planen
- DirectAdmin vejledning 10.1: Flyt din e-mail: mulighederne
- WebOké vejledning 5.7: DNS gendannelse og oprettelse af DNS-backup
- Gratis DNS-kursus 6.1: TTL og cache
- Gratis DNS-kursus 6.3: DNS ved en flytning