Omstillingen er det tidsrum, hvor et system holder op med at køre det gamle sted og begynder at køre det nye. Den skal planlægges, så nedetiden er kendt og godkendt på forhånd, så navne og adresser peger det rigtige sted hen, når systemet åbner igen, og så der er en vej tilbage, hvis noget går galt.
Her står det tekniske forløb for infrastrukturen.
Før natten
Nedetiden. Hvor længe må systemet stå stille? Det svar skal komme fra forretningen, og det skal være skrevet ned. Med det svar vælges metoden for den sidste overførsel. Kan data ikke nå over inden for vinduet, skal det meste være synkroniseret i forvejen. Læs store datamængder.
DNS. Navneopslag kan mellemlagres. Hvert svar har en levetid, TTL, der siger, hvor mange sekunder en anden server må gemme svaret, før den skal spørge igen. Står TTL højt, vil brugere og systemer blive ved med at finde den gamle adresse i lang tid efter omstillingen. Sænk derfor TTL på de navne, der skal ændres, i god tid, så den gamle, høje værdi er udløbet, når I ændrer adressen. Nogle resolvere kan holde fast i svar længere, end TTL siger, så regn med en hale af trafik til den gamle adresse.
Faste adresser. Har kunder, banker, leverandører eller myndigheder åbnet deres firewalls for jeres nuværende IP-adresser, skal de have de nye i god tid. Det samme gælder systemer, der sender mail, hvor de nye adresser skal ind i jeres egne poster for afsendere. Lav en liste over, hvem der skal have besked, og hvornår.
Certifikater og hemmeligheder. Certifikater, nøgler og adgangskoder, som systemet bruger, skal være på plads i det nye miljø og være afprøvet.
Ændringsstop. Fra et aftalt tidspunkt laves der ingen ændringer i systemet, ud over dem omstillingen kræver. Det gør det muligt at vide, hvad der skal overføres, og at gå tilbage til en kendt tilstand.
Natten
Skriv forløbet som en liste med tidspunkter, ansvarlige og et kontrolpunkt efter hvert trin. Et typisk forløb ser sådan ud:
Systemet lukkes for brugere, og skrivning til data stoppes. Den sidste overførsel køres. Optælling og kontrolsummer sammenlignes. Systemet startes i det nye miljø og testes af applikationsejeren efter en testliste skrevet på forhånd. DNS og eventuelle adresser i load balancere og firewalls ændres. Brugerne lukkes ind, og overvågningen følges tæt.
Hvert kontrolpunkt har et kriterium. Er det ikke nået, går forløbet ikke videre, og den ansvarlige for natten beslutter, om der skal ventes, rettes eller gås tilbage.
Tilbagefald
Tilbagefaldet er planen for at vende tilbage til det gamle miljø, hvis det nye ikke virker. Det skal være beskrevet og helst prøvet, før natten.
Det vigtigste punkt er det tidspunkt, hvor tilbagefald ikke længere er muligt uden tab. Så længe der ikke er skrevet nye data i det nye miljø, kan I gå tilbage ved at pege DNS og adresser på det gamle. Når brugerne har arbejdet i det nye, skal de nye data med tilbage, og det er en flytning i sig selv. Sæt derfor en grænse: hvis testen ikke er bestået inden et bestemt klokkeslæt, går I tilbage.
Kriterierne for tilbagefald skrives ned før natten. Midt om natten, efter mange timers arbejde, er det svært at træffe beslutningen om at opgive. Når kriteriet står skrevet, er det en kontrol. Hvornår det gamle miljø må lukkes helt, står på exit-plan.dk under vejen tilbage.
Efter natten
De første dage skal både det nye og det gamle miljø være til stede. Det gamle står slukket for brugere og klar til tilbagefald. Overvågningen følger svartider, fejl og trafik til den gamle adresse. Når trafikken til den gamle adresse er stoppet, og systemet har kørt gennem en normal arbejdsperiode, kan I begynde at afvikle det gamle. Læs test og de første 90 dage.
Hvad det kræver, og hvad det koster at lade være
En omstilling kræver en plan på papir, en ansvarlig for natten, infrastrukturfolk, applikationsejeren til test, en, der kan ændre DNS og firewalls, og en kanal til brugerne. Forberedelsen tager længere tid end natten. Sæt dage på hver rolle som interval, og planlæg en ekstra nat i reserve.
Uden plan bliver natten længere end vinduet. Brugere finder den gamle adresse i dagevis, kunder kan ikke nå jer, fordi de ikke har åbnet for de nye adresser, og beslutningen om at gå tilbage træffes for sent. Det koster i nedetid, i genopretning af data skrevet to steder, og i tillid hos de brugere, der skal arbejde i det nye miljø.
Det skal I lade være med
- At sænke TTL samme aften · den gamle værdi skal være udløbet, før adressen ændres.
- At gå videre uden et bestået kontrolpunkt · fejl, der føres med, er sværere at rette senere på natten.
- At beslutte tilbagefaldet undervejs · kriteriet og klokkeslættet skal stå skrevet før natten.
Det skal valget kunne vise
- ☐ Nedetid godkendt af forretningen.
- ☐ En liste over dem, der skal have de nye adresser, med dato for besked.
- ☐ Forløbet for natten med tidspunkter, ansvarlige og kontrolpunkter.
- ☐ Kriterier og sidste klokkeslæt for tilbagefald.
Kilder
- RFC 1035, Domain names, implementation and specification: afsnit 3.2.1 om TTL.
- RFC 2181, Clarifications to the DNS specification: afsnit 8.
Senest gennemgået: november 2026.
Næste skridt
Skriv forløbet for natten for ét system, også selv om flytningen ligger langt ude. Det viser, hvad der mangler i forberedelsen.
Læs også: DNS, CDN og DDoS-beskyttelse · Rækkefølgen i infrastrukturen
→ Kontakt · Tlf. 70 13 63 23 · Exit-plan og exit-rådgivning hos Nielco IT
