The call usually comes on a Tuesday morning. The website is gone, or it is there but no orders are arriving any more. The day before, somebody moved the domain to a new provider because the contract was running out or the offer was better. The move itself worked. What did not work is everything that hung off it: the mailboxes, the sender authentication, the form on the contact page, the address the accounts department collects its invoices from. A domain migration is rarely a technical problem. It is a sequencing problem — and sequences can be planned.
Key takeaways
- A migration has two tracks: the website and the mailbox. They hang off different DNS records and may be switched on different days.
- The shelf life of DNS answers (TTL) sets the schedule, not the provider change. Typical values are 1 to 5 days (RFC 1912) and have to be lowered beforehand.
- A .de domain needs a transfer password that expires after 30 days (DENIC). With international endings a transfer is approved by default after five calendar days (ICANN), even if nobody acts.
- The old mail server stays open after the MX switch until nothing verifiably arrives there any more. Sending servers hold undeliverable mail for at least four to five days (RFC 5321).
- SPF, DKIM and DMARC do not travel with the domain. They describe the sending server, and after the move that is a different machine.
One migration, two tracks
Almost nobody who says „domain migration" means only the domain. They mean a bundle: the name itself, the website behind it, the mailboxes, often a form, a calendar, an interface into the inventory system. The name is the smallest part of that. It is an entry in a directory, and rewriting that directory takes minutes. Everything else only hangs off the name because it is found through it — and that is exactly what separates a quiet migration from an expensive one.
It helps to picture two separate tracks. On the upper track sits the website. It hangs off the A and AAAA records that name a server address, and usually off a CNAME for the address with „www". On the lower track sits the mailbox. It hangs off the MX record that says which server accepts messages for this domain, and off several TXT records describing who is allowed to send in your name. The two tracks share the same name and nothing else. They can be planned separately, tested separately and switched separately.
That separation is the single most useful move in the whole exercise. Switch both on the same afternoon and have a problem that evening, and you have two suspects and no evidence. Switch the website on Monday and the mailbox on Thursday, and every symptom points somewhere immediately. The effort is the same, the troubleshooting is a different world. If you are changing provider anyway, it is worth looking at the selection criteria for web hosting — a lot of what makes a migration hard later is decided when the provider is chosen.
| Website track | Mailbox track | |
|---|---|---|
| Records | A, AAAA, CNAME | MX, TXT (SPF, DKIM, DMARC) |
| Symptom when it breaks | page unreachable or old version visible | message in the wrong mailbox or rejected |
| Testable in advance | yes, fully, via a local hosts entry | partly, via test addresses at the new provider |
| Way back | revert the record, effective after the TTL | revert the record, follow-up work remains |
| Critical window | minutes to hours | hours to days |
What has to be settled before the first click
The most common reason a migration fails is not a misconfiguration but a missing authorisation. The domain is registered to a name nobody remembers; the customer account at the old provider runs through an email address that no longer exists; the agency that built the site seven years ago is listed as the owner. All of that is fixable, but none of it in two days. Sorting this out beforehand saves the rest. We took the ownership question apart in who owns my website and my domain.
For .de domains the registry handles this through a transfer password, the AuthInfo. The new provider needs it to start the change. Two details are regularly overlooked: it is between 8 and 16 characters (DENIC) long, and it expires automatically after 30 days (DENIC). Request it in July for a move in September and you request it again in September. International endings such as .com or .net follow the ICANN Transfer Policy, which ticks the other way: if the losing provider does not respond, a transfer counts as approved after five calendar days (ICANN). A freshly registered or recently transferred domain, on the other hand, is locked for 60 days (ICANN) — a deadline that wrecks any schedule if it only surfaces on cutover day. The other way round, the losing provider is not allowed to drag its feet either: the auth code and the transfer lock have to be handed over or removed within five calendar days (ICANN Transfer Policy).
The inventory nobody enjoys taking
- Who is the registered owner of the domain, and is the address on file still correct?
- Which email address does the account at the old provider run through — and does that address still exist?
- Is the AuthInfo available, and how much longer is it valid?
- Is the domain under a transfer lock because it was recently registered or moved?
- Which records are currently in the zone, and which service depends on which one?
- How many mailboxes are there really, and which of them are forwards or distribution lists?
- Which third-party services send in your name — newsletter, accounting, inventory, appointment booking?
- Where does the certificate live, and who renews it after the move?
The last question on the list is the one that takes longest. Third-party services sending in your name appear on no invoice and in no contract; they exist only as records in the zone. A newsletter tool, an invoicing package, a booking system — each of them was given a line once, and each of those lines has to exist again at the new provider, or the messages concerned will land in the spam folder after the move. Nobody notices that on cutover day. You notice it three weeks later, when somebody complains about an invoice that never arrived.
TTL: the shelf life that sets the schedule
Every answer from the name system carries a shelf life, the time to live. It tells every asking server how long it may remember the answer before asking again. That single number decides how long the old answer stays in circulation after a change — and therefore the entire schedule. The classic guidance names 1 to 5 days (RFC 1912) as typical values and, for records that are queried often and changed rarely, even 1 to 2 weeks (RFC 1912). Anybody who does not know those numbers plans a migration for one afternoon and then spends two days puzzled.
The remedy is trivial and still regularly forgotten: the TTL is lowered before anything else happens — and at least one old TTL length in advance, so that the old, long shelf life has itself expired. If the MX record says 86400, lower it to 300 today and schedule the move in eight days. Otherwise you do lower the value, but the world only notices a day later — and the day it notices is cutover day.
Two more numbers belong in the same context, because they explain why a mistake sometimes stays visible longer than the TTL suggests. First, the absence of a record is cached too: for this negative caching, values of one to three hours (RFC 2308) have been found to work well as a default. Query a record before it exists and you get the error back for hours, long after the record has been set. Second, resolvers may keep serving an expired answer when the authoritative servers are unreachable; the suggested period for that is 1 to 3 days (RFC 8767), and the cap for stored shelf lives should sit at 604,800 seconds (RFC 8767), which is seven days.
Not every TTL is yours to choose
Moving the website: test first, switch second
The website is the easier track, because it can be tested in full before anybody notices a thing. The trick is a local name entry on your own machine: you put the real domain name with the new server address into the hosts file, and from that moment your browser sees the new site under the real name while everybody else still sees the old one. That lets you submit forms, check redirects, inspect certificates and measure load times — all under the name it will run under later, without putting a single visitor at risk.
# Only on your own machine: the real name points at the new target.
# Everybody else still sees the old site.
203.0.113.42 example.com
203.0.113.42 www.example.comWhat gets checked in that test run is more than „the page loads". It is about addresses: every old address that appears in search engines, in directories or in printed material has to either show the same thing after the move or redirect to the new target. When the migration coincides with a new site, this is not a side issue but the actual work. How such a change is planned without losing existing visibility is covered in our piece on the relaunch and in the overview of our web design work.
Addresses stay put
Every reachable address on the old site is noted and checked individually after the move. Whatever disappears gets a permanent redirect — no hiding via robots.txt, no blocking via noindex.
Certificate first
The certificate is issued on the new server before the record is switched. Otherwise the first visitors see a security warning, and that sticks in the memory longer than the migration does.
Forms with a real sender
Contact and order forms send through a server that matches the domain. How to set that up properly is described in professional email on your own domain.
After the switch there is no celebration, there is measurement. The most useful source is Search Console: within a few days it shows whether addresses suddenly return errors, whether the number of indexed pages drops and whether clicks fall away on the same queries. Which of those numbers actually mean something and which are just noise is something we took apart in reading Search Console data. A migration is one of the few occasions where that look is not optional.
The mailbox: the part that actually hurts
Email is why domain migrations have a bad reputation. A website showing yesterday's version for an hour annoys nobody seriously. An order sitting in a mailbox that nobody has opened since yesterday costs money — quietly. The volume does not help: working internet users receive an average of 53 work messages per day (Bitkom), and 14 percent (Bitkom) of them get a hundred or more. A migration that sends ten percent of that in the wrong direction for three days is not a cosmetic flaw.
The heart of the problem is that you do not control the switch. Whether a message reaches the old or the new server is decided not by your mailbox but by the sending server on the other side — and it works with the answer it received last. One large provider puts this unusually plainly and names up to 72 hours (Google Workspace) before new MX records are recognised. Three days in which part of the mail still lands at the old target is therefore not the exception but the norm.
The old server stays on
How long „at some point" is stands in the mail transport standard. A sending server should wait at least 30 minutes (RFC 5321) between attempts and keep trying for at least four to five days (RFC 5321) before giving up. That is the safety margin a migration has — provided a queue forms at all. If the message is hard-rejected because no server is responsible for the domain any more, there is no retry and no second chance.
- Create the new mailboxes at the target provider, with the same size and folder structure as the existing ones.
- Run the first full sync while everything still arrives at the old target. Folders, read status and attachments belong in it.
- Prepare the devices: store the new credentials, but leave the old account configured for now.
- Switch the MX record. From this moment the double-delivery window is running.
- Repeat the sync daily until no new message has arrived at the old target for 24 hours.
- Only then remove the old account from the devices.
- Leave the old server accepting for a few more days, then set it to forward, then shut it down.
The old mailbox is not an archive
SPF, DKIM and DMARC do not travel with you
The three records that decide today whether your mail arrives do not describe the domain, they describe the server sending in its name. That server is a different one after the migration. Copy the zone one to one and you copy permission for a machine your business no longer uses — while denying it to the one that now sends. The result is inconspicuous and unpleasant: the messages go out, they arrive, and they land in the spam folder.
SPF is the line with the trap in it. It does not only list which servers may send, it also has a hard ceiling: one evaluation may trigger at most ten (RFC 7208) lookups in the name system. Every third-party service you include costs at least one of them, some more. Leave the old provider in and add the new one, and you breach that limit faster than you expect — and then the whole line counts as faulty, not just the surplus part.
; Website
@ 300 IN A 203.0.113.42
@ 300 IN AAAA 2001:db8::2a
www 300 IN CNAME @
; Mailbox
@ 300 IN MX 10 mx1.newprovider.example.
@ 300 IN MX 20 mx2.newprovider.example.
; Sender authentication
@ 300 IN TXT "v=spf1 include:_spf.newprovider.example -all"
sel2026._domainkey 300 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."
_dmarc 300 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"DKIM signs every outgoing message with a key whose public half sits in the zone. The migration creates a new key pair, and the new public half gets its own name — the selector. The old selector may and should stay for a while, so that messages sent before the switch remain verifiable. There is a clear lower bound on key length: delivery to personal mailboxes at one large provider requires a key of 1024 bits or longer (Google Workspace).
DMARC is the record that ties the two together and reports what happens. Straight after a migration it stays on the observing setting until the aggregate reports show that every legitimate sender gets through cleanly. The catch is that those reports arrive slowly. An aggregate report typically covers a single UTC day (RFC 9990), and that rhythm can no longer be steered: the ri tag, which still carried a default of 86,400 seconds in the superseded RFC 7489, is listed as historic (RFC 9989) in the version in force since May 2026. Tighten the setting too early and you lock out your own newsletter and find out a day later. One more number belongs here if you watch your delivery rate: the spam rate should stay below 0.30 percent (Google Workspace).
Two more thresholds belong here, because they only bite after the move. Anyone sending larger volumes falls under tightened requirements for exactly these three records from 5,000 messages per day (Google Workspace) upwards — a migration is a bad moment to leave them half finished. And if you use MTA-STS, the policy has to be touched before the server changes: sending servers may cache it for up to 31,557,600 seconds (RFC 8461), roughly a year. A policy still naming the old mail server therefore outlives the move by considerably longer than the server itself.
A migration is only finished when the first invoice after the switch sits in the recipient's inbox and not in their spam folder. Everything before that is an interim state.
Certificate, HSTS and the addresses that have to stay
When a site shows a security warning after a migration, it is almost always because the certificate was issued after the switch. Automated issuance checks whether the applicant controls the domain — and that check runs through exactly the records being changed. Reverse the order and switch first, and you may sit there for an hour with a warning page. Issue beforehand and the problem does not exist. Free certificates are valid for 90 days (Let's Encrypt), and the ceiling for newly issued server certificates now stands at 200 days (CA/Browser Forum). Both mean the same thing: automatic renewal has to run at the new location after the migration, or the site fails weeks later.
The second obstacle has a longer tail. If you have set HSTS, you are telling browsers to reach this domain only over an encrypted connection for a given period. Inclusion in the browsers' preload list requires a validity of at least 31,536,000 seconds (HSTS Preload List) — one year. That is the right setting for a site in production, but it forgives no migration to a server without a valid certificate: the browser will not let the user click through, it blocks.
| Item | Before the switch | After the switch |
|---|---|---|
| Certificate | issued and verified on the new server | test automatic renewal at the new location |
| Redirects | list of all old addresses compiled | every address called individually, status code noted |
| HSTS | validity and preload status checked | leave unchanged until everything runs stably |
| Search engine | inventory of indexed addresses saved | review coverage and errors daily |
| Mailbox | full sync completed | sync daily until nothing arrives any more |
The week after: what gets watched
Cutover day is the least spectacular part of a well planned migration. The interesting part is the week that follows, because that is where the oversights surface. Three observations are enough: is mail still arriving at the old target? Do the old website addresses return the right answers? And is the sender authentication reporting failed attempts from directions you cannot explain? Each of those questions takes one look a day, and each of them has already rescued migrations that would otherwise have gone quietly wrong.
That watching is not a special task, it is a slice of what should be running anyway. If you have ongoing maintenance in place, the migration simply hooks into it: the same checks, on a tighter cadence for a few days. If you do not, this is the moment it becomes obvious why it pays off — the points that regularly turn up are collected in maintenance and security for local businesses.
- Check daily whether new messages are arriving at the old mailbox — the window only ends after 24 hours of silence.
- Call every previously noted website address and record the status code, not just the home page.
- Read the aggregate reports from the sender authentication and clarify every unknown sending server.
- Trigger the certificate renewal manually once, so the automatic run is not first tested in three months.
- Carry over out-of-office notices, forwards and distribution lists — they are routinely forgotten when mailboxes are created.
- Test third-party services individually: send a real invoice, a real newsletter, a real form submission.
What a migration really costs a business
The question of effort cannot be answered with a number, but it can be answered with a structure. The technical move — create the zone, set the records, switch — is the smallest item and done in a few hours. The bigger item is the inventory beforehand: working out everything that hangs off the domain regularly takes longer in an established business than the migration itself. The third item is the follow-up, and that one cannot be shortened, because it depends on deadlines that are not yours.
A migration pays off above all when something is due anyway. If the contract is running out, a relaunch is on the table or the hosting has reached its limits, then the move is one step in a larger project rather than an end in itself. What to look at when choosing is set out in our hosting checklist for local businesses; and where frequently changing content is involved — a menu with allergen labelling, say — the way it is maintained belongs on the migration list too, because it is often different afterwards.
That this is no niche topic is clear from the sheer spread: by June 2026 more than 18 million (DENIC) .de domains were registered. How routine a company website has become shows in a regional figure: in Bavaria, 92 percent (Bayerisches Landesamt für Statistik) of companies with at least ten employees ran their own website in 2025. Nearly every one of those businesses faces a provider change at some point. Which parts of it we take on is listed under services; what that looks like in practice is shown in our references.
In the end a domain migration is a process with few real decisions and many small steps in the right order. Lower the shelf life beforehand, test beforehand, leave the old server on and keep looking for a week, and you will barely notice the move. Do it the other way round and you will notice it for weeks. The difference is not in the tooling, it is in the calendar.
Sources and studies
Related Articles
Website Maintenance 2026: Secure Against Attacks
The BSI reports around 119 new vulnerabilities per day (up 24 percent). Why local businesses must regularly maintain their website and what upkeep covers.
Set Up a Professional Email With Your Own Domain
Why info@yourbusiness.invalid beats free webmail: a professional image, deliverability and protection against spoofing with SPF, DKIM and DMARC.
Seasonal pages: be visible before the season starts
Six to eight weeks of lead time: why a seasonal page must go live long before the season starts, what belongs on it and how to park it correctly after.