Skip to main content

Flytte e-post til Microsoft 365: sjekk dette før migrering

Skal bedriften flytte e-post til Microsoft 365? Sjekk DNS, gamle postbokser, videresending, IMAP, backup og testplan før dere endrer MX.

Å flytte e-post til Microsoft 365 høres ofte ut som én DNS-endring. I praksis er det sjelden så enkelt. For en liten bedrift kan e-post være knyttet til postbokser, aliaser, gamle webhotell, skannere, kontaktskjema, regnskapssystem og mobiltelefoner som har vært satt opp litt forskjellig over flere år.

Derfor bør en e-postmigrering planlegges som en liten driftsendring, ikke som en rask knapp i adminpanelet. Målet er ikke å gjøre prosjektet større enn nødvendig. Målet er å unngå at viktig e-post stopper, havner feil sted eller blir liggende igjen i en gammel postkasse ingen følger med på.

Start med å finne ut hvor e-posten faktisk går i dag

Før dere endrer noe, bør dere vite hvilken løsning som mottar e-post i dag. Det er ikke alltid det samme som der nettsiden ligger, eller der domenet er kjøpt.

Sjekk særlig:

  • hvem som styrer DNS for domenet
  • hvilken MX-post som mottar e-post
  • om det finnes gamle postbokser på webhotell eller mailserver
  • om noen bruker webmail, Outlook, Thunderbird eller mobil direkte mot gammel server
  • om domenet har aliaser, videresendinger eller delte postbokser
  • om kontaktskjema, skrivere, skannere eller fagsystemer sender e-post via gammel løsning
  • om det finnes spamfilter, gateway eller connector mellom flere systemer

Dette er ofte der små feil oppstår. En bedrift kan ha Microsoft 365 for noen brukere, men fortsatt ha en gammel postboks, videresending eller SMTP-oppsett et annet sted. Da kan en tilsynelatende enkel MX-endring få uventede følger.

Ikke begynn med MX-posten

MX-posten bestemmer hvor ny innkommende e-post for domenet sendes. Når den endres til Microsoft 365, begynner ny e-post å gå dit. Eksisterende e-post hos tidligere leverandør flytter seg ikke automatisk.

Microsoft beskriver dette tydelig i domenedokumentasjonen sin: brukere og postbokser bør være opprettet før MX endres, slik at e-post ikke stopper under overgangen. Det betyr at MX-endringen bør komme etter kartlegging, oppretting av brukere, test og plan for migrering.

En god tommelfingerregel er: ikke pek domenet til Microsoft 365 før dere vet at riktig postboks finnes for alle adresser som skal motta e-post.

Avklar hva som faktisk skal flyttes

En migrering handler ikke bare om “all e-post”. Dere bør vite hva som skal tas med, hva som kan arkiveres, og hva som ikke skal flyttes.

Avklar dette før migreringen:

  • hvilke brukere som skal ha Microsoft 365-postboks
  • hvilke delte adresser som skal være shared mailbox, distribusjonsliste eller alias
  • om gamle videresendinger fortsatt trengs
  • hvor langt tilbake historisk e-post skal flyttes
  • om kalender, kontakter og regler må håndteres separat
  • hvem som kan godkjenne rydding eller sletting
  • hvilke kontoer som må testes ekstra fordi de brukes av ledelse, økonomi eller kundemottak

Ved IMAP-migrering er det spesielt viktig å være presis. IMAP egner seg til å flytte e-post fra mange eldre eller enklere e-postløsninger, men det løser ikke alt rundt kalender, kontakter, klientprofiler, regler og gammel lokal data. Slike ting må vurderes ved siden av.

Rydd i adresser før de flyttes

Mange små virksomheter har adresser som er laget over tid: en info-adresse, gamle ansatte, midlertidige aliaser, leverandøradresser, prosjektadresser og videresendinger som ingen helt husker hvorfor finnes.

Før migrering bør dere gå gjennom listen og merke:

  • skal beholdes som egen bruker
  • skal være delt postboks
  • skal være alias
  • skal videresendes
  • skal stenges eller arkiveres

Dette sparer lisenser, reduserer rot og gjør det enklere å dokumentere hvem som har tilgang til hva. Det er også et godt tidspunkt å slå på tofaktor og rydde i administratorrettigheter.

DNS må behandles som drift, ikke pynt

For Microsoft 365-e-post er de viktigste DNS-postene normalt MX, Autodiscover og SPF. I tillegg bør DKIM og DMARC vurderes for bedre e-postautentisering og mindre risiko for misbruk av domenet.

Det viktigste er ikke å kopiere et eksempel fra nettet. Verdiene må hentes fra riktig Microsoft 365-tenant og riktig domene. Feil MX-verdi, gammel SPF-post eller manglende autodiscover kan gi problemer som først oppdages når brukerne skal sende, motta eller sette opp Outlook.

Hvis DNS styres hos en annen leverandør enn webhotellet, må dere vite hvor endringen faktisk skal gjøres. Ikke anta at Plesk, Domeneshop, Cloudflare, Microsoft og nettsideleverandøren styrer samme del av domenet.

Se etter gamle systemer som fortsatt sender e-post

Et vanlig migreringsproblem er at brukerpostboksene flyttes, men gamle systemer fortsatt prøver å sende via tidligere mailserver. Det kan gjelde:

  • kontaktskjema på nettsiden
  • kopimaskin eller skanner
  • regnskapssystem
  • alarmsystem eller overvåking
  • nettbutikk
  • eldre applikasjoner med SMTP-oppsett

Noen systemer kan bruke Microsoft 365 direkte. Andre bør bruke en godkjent SMTP-løsning eller connector, avhengig av behov og sikkerhetskrav. Microsoft har egen dokumentasjon for connectors og scenarier der e-post skal rutes mellom Microsoft 365 og andre systemer.

Lag en enkel testplan

En praktisk testplan trenger ikke være lang. Den bør bare dekke det som faktisk kan gå galt.

Test minst dette:

  • mottak fra ekstern e-postadresse
  • sending til ekstern e-postadresse
  • sending internt mellom brukere
  • Outlook-oppsett på PC
  • mobiloppsett for minst én bruker
  • webmail i Microsoft 365
  • deling eller tilgang til felles postboks
  • kontaktskjema eller system som sender e-post
  • at gamle postbokser ikke lenger mottar ny e-post etter kuttet

Dokumenter hva som er testet. Når en bruker senere sier at “e-posten ikke virker”, er det stor forskjell på å vite at domenet fungerer, og å måtte gjette om feilen ligger i DNS, Outlook-profilen, passord, mobil eller en gammel konto.

Planlegg opprydding etterpå

Migreringen er ikke ferdig idet e-post begynner å komme inn i Microsoft 365. Etterpå bør dere rydde kontrollert.

Typiske etterarbeidspunkter:

  • bekreft at alle viktige adresser mottar e-post i ny løsning
  • kontroller at gamle videresendinger ikke sender e-post feil vei
  • oppdater dokumentasjon for DNS, postbokser og ansvar
  • fjern gamle kontoer først når data og tilgang er avklart
  • sett opp eller bekreft backup der det trengs
  • slå på sikkerhetsinnstillinger som tofaktor og betinget tilgang der det passer
  • avtal hvem som hjelper brukere med mobil og Outlook-profiler

Ikke slett gamle postbokser eller serveroppsett for tidlig. Det kan ligge historikk, systemkontoer eller avklaringer der som først bør verifiseres.

Backup og gjenoppretting må avklares separat

Microsoft 365 gir en robust skytjeneste, men en migrering bør likevel ha en tydelig plan for backup og gjenoppretting. Det gjelder både data som ligger igjen i gammel løsning, data som flyttes, og data som skal beskyttes etterpå.

Spør konkret:

  • finnes det en eksport eller backup før migreringen starter?
  • hvor lenge beholdes gammel løsning etter kuttet?
  • hvem kan be om gjenoppretting?
  • dekker backup e-post, OneDrive, SharePoint og Teams, eller bare deler av miljøet?
  • hvordan testes restore hvis noe mangler?

Vi har skrevet mer om dette i Hva dekker Microsoft 365-backup? og Hvordan fungerer backup og gjenoppretting hos Trønder Data?.

Når bør dere få hjelp?

En liten bedrift kan fint gjøre en enkel e-postflytting selv hvis miljøet er ryddig, få brukere er involvert og ingen gamle systemer er koblet på. Men få hjelp hvis dere har:

  • flere domener eller flere e-postleverandører
  • gamle postbokser på webhotell
  • mange aliaser, delte adresser eller videresendinger
  • skannere, regnskapssystem eller nettsider som sender e-post
  • behov for å bevare historikk
  • usikkerhet rundt DNS, SPF, DKIM eller DMARC
  • krav til minst mulig nedetid

Da er det ofte billigere å bruke litt tid på kartlegging enn å feilsøke i hast etter at e-posten har stoppet.

Kort sjekkliste før dere flytter

  • Kartlegg nåværende e-postleverandør og DNS-ansvar.
  • Lag liste over brukere, aliaser, videresendinger og delte postbokser.
  • Opprett nødvendige brukere og postbokser i Microsoft 365 før MX endres.
  • Bestem migreringsmetode og test med en konto først.
  • Sjekk gamle systemer som sender e-post.
  • Planlegg DNS-endring og tidspunkt.
  • Test sending, mottak, mobil, Outlook og webmail.
  • Avklar backup, arkiv og opprydding.
  • Dokumenter hva som er gjort.

Trønder Data kan hjelpe med kartlegging, migrering, DNS, Microsoft 365-oppsett og etterkontroll for små og mellomstore bedrifter. Se også siden vår om Microsoft 365 og artikkelen Når passer Microsoft 365, og når bør dere velge Nextcloud?.

Videre lesing


Fortsett å lese våre artikkler

Søk