Å 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.
Ikke velg «tre år» bare fordi det høres passe ut
Et mønster vi møter i migreringsarbeid, er at virksomheten først ber om å få med e-post fra de siste tre årene. Det kan virke som en enkel avgrensning. Senere kommer spørsmålet om hvor eldre korrespondanse ble av, fordi ingen undersøkte hva postboksene faktisk ble brukt til før grensen ble satt.
Det betyr ikke at all historikk alltid skal flyttes. Det betyr at beslutningen bør bygge på innhold og behov, ikke på hukommelse alene. Før dere velger en dato, bør hver postbokseier kontrollere noen konkrete eksempler:
- Hvor gammel er den eldste e-posten de fortsatt søker etter i arbeidshverdagen?
- Finnes det eldre dialog om avtaler, leveranser, reklamasjoner eller andre saker som fortsatt kan bli aktuelle?
- Ligger viktig historikk i Sendt, egne undermapper, lokale arkivfiler eller en tidligere ansatts postboks?
- Er det krav i avtaler, interne rutiner eller regelverk som påvirker hvor lenge bestemte opplysninger skal bevares eller slettes?
Velg deretter en bevisst løsning: flytt hele den nødvendige historikken, flytt et dokumentert utvalg, eller etabler et separat arkiv med avklart tilgang og levetid. Å la gammel e-post bli stående på en server som snart skal stenges, er ikke en arkivplan.
Kontroller historikken før gammel løsning stenges
Etter migreringen bør dere søke etter kjente meldinger fra både nyere og eldre perioder. Kontroller innboks, Sendt og egne mapper, åpne noen vedlegg, og sjekk eventuelle lokale arkivfiler. Utpek én person som bekrefter at den avtalte historikken er tilgjengelig før gammel løsning slettes eller abonnementet avsluttes.
Migreringsmetoden påvirker også hva som følger med. Microsoft opplyser at en vanlig IMAP-migrering flytter e-post i postmappene, men ikke kontakter, kalenderoppføringer eller oppgaver. Målpostboksene må dessuten opprettes i Microsoft 365 før IMAP-migreringen gjennomføres. Slike avgrensninger må stå i migreringsplanen, slik at manglende innhold ikke først oppdages etterpå.
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
