En migrering uden afbrydelse betyder, at hver besked, der sendes til dit domæne, lander i en postkasse, og at hver medarbejder kan skrive til sine kontakter på skiftedagen. Det betyder ikke, at historikken, mobilerne og vanerne skifter, uden at nogen skal gøre noget.
To platforme kører parallelt.
Det klassiske hul opstår, når MX skiftes, mens en kopi er ufuldstændig, eller når en kopimaskine, et website eller et CRM stadig sender med det gamle login.
MX er en DNS-post: den fortæller afsendende servere, hvor post til dit domæne skal leveres. At skifte e-mailtjeneste er først og fremmest at ændre denne leveringsadresse. Resten (konti, historik, enheder) forberedes omkring det.
SMTP-protokollen tåler korte hændelser godt. En afsendende server, der modtager en midlertidig fejl, beholder beskeden i køen og prøver igen senere. En server, der kortvarigt ikke kan nås, medfører derfor ikke, at post går tabt. En permanent fejl (ukendt postkasse, afvist besked) sender derimod beskeden tilbage til afsenderen, og den besked kommer aldrig frem af sig selv. Den største risiko ved et skift er ikke nedbrud, men at den nye platform afviser en modtager, fordi et alias eller en liste ikke er blevet genoprettet.
TTL (time to live) bestemmer, hvor længe en DNS-resolver må gemme et svar i hukommelsen. I det tidsrum leverer en del af afsenderne stadig til den gamle platform. Det er normalt, og derfor skal den gamle kunne modtage post i overgangsperioden.
To uger før. Opgørelse over postkasser, aliaser, lister, delte postkasser og alle de applikationer, der sender mail. Sænkning af MX-postens DNS-TTL til en kort værdi (ofte 300 sekunder), så dagen D slår hurtigt igennem. Oprettelse af målkontiene. Første kopi af historikken.
TTL sænkes tidligt, fordi en resolver, der har læst den gamle værdi, beholder den, indtil den udløber: den korte TTL får først virkning, når den gamle cache er udløbet. Den første kopi er til gengæld den længste; ved at starte den tidligt er der tid til at opdage de postkasser, der giver problemer.
Nogle dage før. Kontrol af en stikprøve: antal beskeder, mapper eller etiketter, aftaler, kontakter. Metoden rettes, hvis stikprøven fejler. Forberedelse af vejledninger til mobil og Outlook. Afsendelsestest fra målplatformen til Gmail og Outlook.com, med SPF, DKIM og DMARC allerede gyldige på den nye platform. Disse poster kan publiceres før MX.
Konkret: én enkelt SPF-post, der godkender begge platforme i overgangsperioden (to separate SPF-poster får kontrollen til at fejle), en DKIM-nøgle fra den nye platform publiceret under sin egen selector ved siden af den gamle, og en gennemlæst DMARC-politik. DMARC kræver, at beskeden er godkendt via SPF eller DKIM i afsenderdomænets navn; hvis din politik er streng, og målplatformen endnu ikke er godkendt, afviser dine kontakter dine beskeder.
Dagen før. Anden kørsel: kopiér kun det, der er kommet siden den første kopi. Frys ændringer af aliaser og lister.
Dagen D. Skift af MX. Øjeblikkelig ekstern kontrol: en mail sendt fra en ekstern privat postkasse skal nå frem til den nye platform inden for TTL-tiden. Overvågning af køen. Omkonfiguration af de afsendende applikationer. Udpeget intern hotline med ret til at sætte MX tilbage, hvis et kritisk flow fejler.
Skift samtidig autodiscover-posten, hvis den findes: det er den, Outlook spørger for at finde sin server. Fjern også sekundære MX-poster, der stadig måtte pege på den gamle platform: en afsender, der ikke kan nå den primære MX, prøver de næste.
De følgende dage. Den gamle platform i læsetilstand. Indrapportering af afvigelser (en manglende mappe, en delt postkasse). Målrettet tredje kørsel om nødvendigt. Derefter lukkes afsendelse fra den gamle, så en medarbejder ikke længere svarer fra to steder.
Det sidste punkt har en teknisk årsag. Den gamle platform betragter stadig sig selv som ansvarlig for dit domæne: en besked sendt derfra til en kollega leveres lokalt uden opslag i MX. Kollegaen ser den aldrig i sin nye postkasse.
| Risiko | Hvad der sker | Modtræk |
|---|---|---|
| MX skiftet for tidligt | Ny post kommer frem, historikken mangler | Skift efter kontrol af stikprøven og anden kørsel |
| Glemt alias eller liste | Målplatformen afviser disse beskeder permanent | Opgørelse, frys af aliaser dagen før, test af fælles adresser |
| Ufuldstændig SPF, DKIM eller DMARC | Dine beskeder afvises eller havner som spam hos modtagerne | Publicér før dagen D, kontrollér på en rigtig besked |
| Applikation, der sender med den gamle konto | Fakturaer, alarmer eller scanninger sendes ikke længere | Liste over applikationer, ny SMTP-server konfigureret på dagen D |
| Afsendelse stadig åben på den gamle platform | Interne beskeder bliver i det gamle system | Luk afsendelse, så snart stikprøven er godkendt |
| Tilbagerulning ikke forberedt | MX sættes tilbage, men beskeder modtaget i mellemtiden bliver på målplatformen | Skriftlig plan, der omfatter overførsel af disse beskeder |
Lad os som illustration tage et rådgivningsfirma med 40 personer. Det vælger at skifte en torsdag sidst på dagen frem for en fredag: dagen efter er teamet til stede til at håndtere afvigelser, og den interne hotline har en hel arbejdsdag foran sig. Kopimaskinen i receptionen, der scanner til mail, omkonfigureres samme aften. Hvis to delte postkasser melder om en manglende mappe, supplerer en målrettet kørsel dem. I dette scenarie går ingen beskeder tabt, men flere medarbejdere skal oprette deres konto på telefonen igen: det er den synlige del, som skal meldes ud.
De skifter server i Outlook eller på mobilen. Den første indlæsning af en stor postkasse tager tid. Beskeder, der allerede ligger i cachen på telefonen, kan blive dubleret, hvis profilen ikke oprettes korrekt på ny. Planlæg proceduren “slet kontoen og opret den igen” frem for at fifle med serverindstillingerne.
Årsagen er den samme for Outlook: profilen har en lokal cache knyttet til den gamle server. En ny profil starter fra en ren tilstand; en ændret gammel profil blander de to verdener. På mobil skifter den anvendte protokol (Exchange ActiveSync eller IMAP afhængigt af målplatformen) nogle gange med platformen, hvilket er endnu en grund til at oprette kontoen igen.
Serverbaserede regler, centrale signaturer og delegeringsrettigheder skal sættes op igen. Meld det ud. Det er ikke en afbrydelse af posten. Det er administrationsarbejde.
Denne videresendelse kræver en eksplicit indstilling: den gamle platform, der stadig tror, at den hoster postkasserne, skal konfigureres til at videresende til den nye i stedet for at levere lokalt. Alternativt gør en målrettet opsamlingskørsel det samme arbejde.
De særlige forhold ved hvert udgangspunkt er beskrevet i migrering fra Microsoft 365 og migrering fra Google Workspace.
Så længe det tager at kontrollere, at intet flow længere bruger den gamle, og at de indrapporterede afvigelser er håndteret. Det afhænger af antallet af postkasser, de afsendende applikationer og tempoet i omkonfigurationen af arbejdsstationerne. Lukker man for tidligt, kan man ikke rette fejl; lukker man for sent, arbejder medarbejderne i to systemer.
Nej, hvis det er forberedt. I TTL-perioden leverer en del af afsenderne stadig til den gamle platform, resten til den nye. Begge modtager, og den næste kørsel samler de to. Post går kun tabt, hvis den afvises, og derfor er aliaser og lister så vigtige.
Som regel ikke: adresserne ændres ikke. Giv derimod besked til de partnere, der filtrerer dine beskeder strengt eller har tildelt dig en særlig regel, og til dem, der udveksler krypteret post med dig, hvis nøglerne ændres.
Ja, ved at sætte den gamle MX tilbage, forudsat at den gamle platform stadig er aktiv. Beskeder, som den nye har modtaget i mellemtiden, skal så kopieres tilbage eller forblive tilgængelige. Tilbagerulningsplanen angiver, hvem der beslutter, inden for hvilken tid, og hvordan disse beskeder overføres.
Spørg driftsleverandøren, hvad den garanterer: at beskederne kommer frem, at historikken overføres, eller begge dele. Det er forskellige forpligtelser. Bed også om tilbagerulningsplanen, skriftligt, med den person, der har ret til at aktivere den.
En garanti for, at beskeder kommer frem, gælder dagen D og de følgende dage. En garanti for historikken gælder kopieringen og kontrollen af den. En leverandør kan overholde den ene uden den anden; tilbuddet skal angive, hvilken den påtager sig, og hvordan den kontrolleres.
Hos Klytic er råd og forslag til forberedelse af migreringen af e-mailtjenesten gratis, og ingen mail går tabt. Migrering udført af Klytic sker efter tilbud. Abonnementerne står på siden Priser og faktureres separat. Fordelingen af omkostningsposterne findes i hvad koster en migrering fra Microsoft 365, og kontrollisten i tjeklisten. For at sammenligne målplatforme, se vælg en europæisk e-mailtjeneste.
Denne side beskriver en metode. Det faktiske forløb afhænger af dine flows, dine mængder og den platform, du forlader.
Gratis rådgivning, ingen mails går tabt. En migrering udført af Klytic prissættes efter en gennemgang.
Velkomsttilbud
Uforpligtende prøvetilbud. En rådgiver ringer dig op for at forstå dine behov og klargøre dit Klytic-miljø.
