Når en virksomhed vil flytte sin email til en ny platform, er det sjældent selve flytningen, der skaber problemer. Det er rækkefølgen, der gør forskellen.
Mange mister ikke mails, fordi systemerne er dårlige. De mister mails, fordi maildata ikke er kopieret færdigt, før mailflowet bliver sendt et nyt sted hen. Hvis MX-records ændres for tidligt, kan nye beskeder begynde at lande på den nye platform, mens gamle beskeder stadig ligger på den gamle. Resultatet bliver hurtigt rod i mapper, usikre brugere og en supportopgave, der kunne være undgået.
Den mest sikre tilgang er enkel: migrér først indholdet, kontroller at synkroniseringen er korrekt, og skift derefter MX-records. Den model går igen i officielle vejledninger fra blandt andet Microsoft og passer godt til den måde, virksomheder typisk arbejder med email i praksis.
Virksomhedens email er sjældent kun én postkasse. Der er ofte flere brugere, historiske mapper, gamle arkiver, mobile enheder og mailprogrammer, som er sat op forskelligt. Når man ser datatab ved en flytning, handler det tit om én af to ting: enten er der brugt den forkerte migreringsmetode, eller også er DNS blevet ændret, før nogen reelt har tjekket resultatet.
En anden klassisk fejl er at antage, at alle mails ligger på serveren. Det gør de ikke altid. Hvis enkelte brugere i årevis har hentet mail via POP, kan en del af historikken ligge lokalt på en computer i stedet for på den gamle mailserver. Så kan en ellers velplanlagt flytning stadig ende med manglende beskeder.
Mailflytning er også et godt eksempel på, at hjemmeside og email skal behandles som to forskellige ting. En virksomhed kan sagtens flytte sit webhotel, sin WordPress-løsning eller sin WooCommerce-shop uden at skifte email samme dag. Det giver ofte mere ro at holde de to processer adskilt.
Når målet er at flytte virksomhedens email uden at miste beskeder, er forskellen mellem IMAP og POP helt central. IMAP arbejder med mails, som ligger på serveren, mens POP typisk henter mails ned lokalt og i nogle opsætninger fjerner dem fra serveren bagefter.
Det er en af grundene til, at IMAP normalt er det rigtige udgangspunkt for en sikker mailmigrering. Microsoft anbefaler også IMAP til migrering, når kildesystemet understøtter det. Hvis flere medarbejdere bruger både mobil, laptop og desktop, passer IMAP også bedre til daglig drift efter flytningen.
| Punkt | IMAP | POP |
|---|---|---|
| Hvor ligger hovedkopien af mailen? | På serveren | Ofte lokalt i mailprogrammet |
| Egnet til flere enheder | Ja | Begrænset |
| Velegnet til migrering | Ja, som hovedregel | Ofte risikabelt |
| Risiko for skjult lokal historik | Lavere | Højere |
| Typisk problem ved flytning | Mapper skal verificeres | Gamle mails findes kun på én pc |
Før man sætter en migrering i gang, er det derfor klogt at undersøge, om virksomheden har gamle POP-opsætninger i omløb. Det gælder især ældre Outlook-profiler og maskiner, som ingen rigtigt har rørt ved i flere år.
Selve arbejdsgangen behøver ikke være kompliceret, men den skal være disciplineret. Start med at kopiere mailindholdet fra den gamle platform til den nye via IMAP, hvis kildesystemet understøtter det. Derefter skal synkroniseringen kontrolleres grundigt. Først når det er bekræftet, at postkasserne er flyttet korrekt, giver det mening at ændre MX-records.
Den rækkefølge mindsker risikoen for, at der opstår et hul mellem gammelt og nyt system. Nye mails bliver ved med at komme ind det gamle sted, indtil mailflowet aktivt peges om. Det giver tid til at kontrollere, om mapper, datoer og indhold ser rigtige ud.
En rolig flytning følger ofte denne model:
Hvis virksomheden bruger en platform, hvor migrering foregår via batches eller lignende værktøjer, bør den teknisk ansvarlige stadig holde fast i samme princip. Værktøjet kan være forskelligt, men rækkefølgen ændrer sig ikke.
En MX-record bestemmer, hvilken mailserver der skal modtage email for domænet. Når den bliver ændret, begynder nye beskeder gradvist at blive sendt til den nye platform i stedet for den gamle. Det er derfor, MX-records ikke bør skiftes først.
MX-records bruger prioritetstal, hvor det laveste tal har højeste prioritet. Samtidig skal en MX-record pege korrekt på en mailserver og ikke sættes op tilfældigt. Hvis DNS håndteres forkert, kan virksomheden opleve afviste mails eller beskeder, der går det forkerte sted hen.
DNS-ændringer kan også tage tid om at slå helt igennem. I nogle miljøer kan overgangen vare op til 72 timer, før alt er konsekvent. I den periode er det ekstra vigtigt at kontrollere, hvor nye beskeder faktisk lander.
Hvis ingen internt har ansvar for DNS, bør ændringen håndteres af den person eller partner, som har det tekniske ejerskab. Det er ikke her, man bør gætte sig frem.
Mange springer denne del over, fordi migreringsværktøjet melder succes. Det er ikke nok. En teknisk vellykket kopi er ikke det samme som en praktisk vellykket flytning.
Det relevante spørgsmål er, om medarbejderne kan finde deres mails, som de forventer. Derfor bør kontrollen ske både på kontoniveau og i rigtige mailprogrammer. Kig ikke kun på indbakken. Kig også på sendte elementer, arkiverede mapper og ældre datoer.
En god verificering kan omfatte følgende:
Det kan også være nyttigt at bede et par nøglebrugere teste deres egne konti, før resten af organisationen flyttes helt. De opdager ofte hurtigere, hvis en vigtig mappe mangler, eller hvis noget ser forkert ud.
Selv med en god plan er backup et vigtigt sikkerhedsnet. Ikke fordi fejl er uundgåelige, men fordi email er forretningskritisk. Hvis en konto bliver slettet ved en fejl, en mappe ikke synkroniserer korrekt, eller en bruger rydder op på det forkerte tidspunkt, kan backup være forskellen på et mindre bump og et reelt tab.
Det er især værdifuldt, hvis hostingpartneren kan hjælpe med gendannelse af emails og ikke kun generel drift. I Hostious’ indhold om fejlfinding og drift fremgår det, at backupmuligheder kan bruges til gendannelse af blandt andet emails. Det giver et ekstra lag tryghed i perioden omkring flytningen.
Samtidig er det vigtigt at skelne mellem email hosting og andre løsninger. Backup af en WordPress-side eller et webhotel er ikke det samme som gendannelse af en mailkonto. Hvis virksomheden flytter email, bør man derfor sikre sig, at backup og gendannelse dækker netop maildelen.
Vil man læse mere om opsætning og relaterede vejledninger, kan man starte her: Hostious fejlfinding og mailvejledninger
Når postkasserne er flyttet, slutter arbejdet ikke nødvendigvis. Mange virksomheder bruger stadig lokale mailprogrammer, hvor kontoen enten skal opdateres eller oprettes på ny. Her sker en stor del af den forvirring, som brugerne oplever efter selve migreringen.
Det vigtigste råd er enkelt: slet ikke den gamle kontoopsætning, før den nye er testet. Hvis en bruger har lokal historik, gamle mapper eller særlige regler, kan de oplysninger være nyttige under kontrollen. Især Outlook-profiler kan gemme på data, som ikke umiddelbart ses i serverens mappeoversigt.
Hostious har vejledninger til manuel opsætning af mail i blandt andet Outlook og Apple Mail, hvilket er relevant efter et platformsskifte, hvor brugerne skal forbindes korrekt til den nye mailtjeneste.
Nogle mailflytninger er enkle. Andre bør ikke klares mellem to møder en tirsdag formiddag. Hvis virksomheden har mange brugere, uklare gamle opsætninger eller forretningskritiske postkasser, er det klogt at lade en teknisk ansvarlig stå for plan, kontrol og DNS-skift.
Det gælder især, når flere forhold optræder samtidig:
Hvis virksomheden samtidig overvejer nyt webhotel, WordPress-hosting eller en ny webshop, er det en god idé at planlægge email som et selvstændigt spor. Det giver bedre kontrol og mindre pres på brugerne.
På Hostious.io kan man orientere sig om email hosting og relevante driftsområder, hvis målet er en løsning, hvor mailhåndtering, opsætning og gendannelse tænkes ind fra starten. Det er ofte her, en mailflytning går fra at være usikker til at blive en kontrolleret overgang, hvor beskederne følger med.
Opret postkasserne på den nye platform, synkronisér alt indhold via IMAP, verificér at det er komplet – og skift FØRST derefter MX-records. Mailflowet må aldrig flyttes før indholdet.
Nej – mailservere prøver igen i timevis, hvis en levering fejler. Med begge platforme aktive under overgangen og en sidste synkronisering bagefter går intet tabt.
Ja, mailprogrammerne skal pege på den nye server – typisk bare nyt servernavn og adgangskode i Outlook eller Apple Mail. Send en kort vejledning på forhånd, så tager det få minutter pr. enhed.
