The decision has been made: the company is switching website providers. The contract has been reviewed, the quote is on the table, the new working relationship is ready to start. And then comes the question no quote ever describes: how does everything actually get from there to here, without the site disappearing for days, without enquiries running into a void and without the search results collapsing? Switching providers is not a single operation. It is four migrations that interlock in time: the domain, the e-mail mailboxes, the content and the old page addresses. Each of these four tracks has its own deadlines, its own parties involved and its own pitfalls. This article describes the sequence the way it has proven itself in practice: from the inventory taken before the cancellation, through the domain transfer using an auth code, to the checklist for the day after the switchover.
Four migrations in one operation
Anyone switching providers moves four things that feel like a single unit in daily work but are technically administered separately. The domain is the name under which the company can be reached; it sits with a registrar and can be moved independently of everything else. The hosting is the place where the pages live. The mailboxes are a separate service that happens to carry the same name. And the addresses of the individual subpages are what search results, directory entries and external links hang on. Most people only notice that this separation exists when they switch providers – and then they notice it very clearly. For the vast majority of companies with ten or more employees a website has long been part of the basic equipment; it is a piece of working equipment like the phone line. In June 2026 the registry reported that the stock of .de domains had passed the 18 million (DENIC eG) mark. Which contract points and access credentials belong on the table before the order is even placed is covered in the article on contract and access with a website provider; this one is about the move itself.
An outage during the switch is rarely spectacular, but it is expensive. Someone searching during that window finds an error message instead of an offer and calls the next result. Someone sending an enquiry may get no answer, because the form points at a mailbox that no longer exists in that form. And someone arriving via an older link lands on an address without content. A study on the durability of web content shows how quickly web addresses decay: 38 percent (Pew Research Center) of the pages that existed in 2013 were no longer reachable ten years later. When providers are switched without redirects, exactly that effect appears overnight – and it hits the addresses that have been linked the longest first, which are usually the most important ones. How strongly response speed decides who wins the job is examined in the article on enquiries and response time.
That is why one rule comes first, a rule that sounds simple and is still rarely followed: the move is prepared, checked and only then switched over – the cancellation of the old contract comes last. Anyone who cancels first works against a deadline they set themselves and loses access to content, mailboxes and analytics at precisely the moment they need it most. A switch with enough lead time is unspectacular; a switch under deadline pressure turns into correspondence with a provider who no longer has any interest in prompt processing. How much lead time a website project needs overall is set out in the article on the timeline of a website project.
Take inventory before you cancel
The inventory answers three questions whose answers, in our experience, are often not available. First: who really owns the domain? Not who pays for it, but who is entered in the register as the holder. For .de domains the contract exists between the holder and the registry, while a provider handles the technical administration (DENIC eG). If an agency or a private individual is listed there instead of the company, the switch stops being a technical operation and becomes a negotiation. Second: where do the mailboxes sit? With the same provider as the website, with a separate service, or in a package that bundles both? Third: who holds the certificate for the encrypted connection, and does it lapse automatically as soon as the contract ends? These three answers determine the schedule. The technical background is covered in more depth in the article on domains and business e-mail addresses.
Three checks that belong before every cancellation
Notice periods and the right sequence
Website contracts frequently run for twelve or twenty-four months and renew silently if they are not cancelled in time. Towards consumers, section 309 number 9 of the German Civil Code sets narrow limits: a commitment of no more than two years, a notice period of no more than one month before expiry and – for contracts concluded after 1 March 2022 – renewal only for an indefinite period with the option to cancel monthly (German Civil Code, section 309). Towards businesses this provision does not apply directly; there the review runs through the general fairness test of section 307, with the customs applying in commercial dealings to be taken into account appropriately (German Civil Code, section 310). For a trade or service business this means in practice: read the term clause, put the deadline in the calendar and count backwards from there. The contract for the domain itself is separate from this and, for .de domains, can be cancelled at any time without notice (DENIC eG) – which is precisely not a reason to cancel it, because a cancelled domain is a lost domain.
Ownership of the domain
The register entry names the company as the holder, with a contact address that someone in the office reads regularly.
Complete mailbox inventory
Every address on the domain is recorded, including forwards, distribution lists and rarely used functional addresses.
Certificate and renewal
It is clear who issues the certificate and whether it lapses automatically when the contract ends.
Content at full resolution
Texts, images and documents are backed up, with photos at full resolution rather than as a downsized web copy.
List of all page addresses
The sitemap, the server logs and the analytics data together produce the complete address list.
Recipients of the forms
For every form it is known which mailbox it delivers to and who actually processes what arrives there.
The point about content deserves a note of its own, because it is underestimated both legally and practically. Under German law copyright itself cannot be transferred; only rights of use can be granted, limited in territory, time and scope (German Copyright Act, sections 29 and 31). Anyone who had texts or photos produced by the previous service provider should therefore clarify, before the switch, to what extent that use continues after the contract ends. Technically there is a simple rule alongside it: back up images at the resolution in which they were originally supplied. A version downloaded from the live website is frequently too small for print, for large image areas and for modern image formats. Which formats and sizes make sense is described in the article on image formats and alt text.
Scroll table sideways
| Point | Planned migration | Migration after cancelling |
|---|---|---|
| Access to content | Available throughout the preparation | Ends with the contract, often mid-project |
| Auth code | Requested calmly, validity kept in view | Becomes a point of dispute under time pressure |
| Mailboxes | Built in parallel, existing archive copied | Created from scratch, old correspondence lost |
| Switchover time | Freely chosen, a low-traffic hour | Dictated by the end of the contract |
| Redirects | Fully prepared before the switchover | Added later, once errors surface |
| Way back | Open until the old contract ends | Closed |
Moving the domain: the auth code step by step
The domain transfer is the part of the switch with the clearest rules – and the least tolerance for improvisation. For .de domains it runs through the provider change procedure using a password, the auth code. The previous provider generates it on the holder's instruction, verifies the holder's authorisation in the process and deposits it in encrypted form with the registry; the new provider files the transfer order with the same auth code, and if the two match the domain is transferred without further delay (DENIC eG). The period of validity matters: an auth code expires after at most 30 days (DENIC eG) and has to be deposited again afterwards. Equally important is what must not be done under any circumstances: a domain is not deleted and registered again. After a deletion there is only a limited recovery window of 30 days (DENIC eG); after that the name is open to any interested party. And a change of holder invalidates every auth code stored for the domain (DENIC eG) – another reason why it does not belong in the same work step.
- Commission the new provider and build the new site completely before anything is changed on the domain name.
- Request the auth code from the previous provider; it goes to the holder contact address stored in the register.
- Note the validity: the transfer order has to be filed within 30 days of the auth code being generated, otherwise a new code has to be requested (DENIC eG).
- One or two days beforehand, lower the validity period of the name entries so that the switchover takes effect promptly (RFC 1035, IETF).
- Hand the auth code to the new provider and order the provider change without altering the holder details at the same time.
- After the transfer, check that the register entry still lists the company as the holder.
- Carry out a change of holder, if one is needed, only afterwards – with generic endings it otherwise triggers a lock period (ICANN).
- Cancel the old contract for hosting and mailboxes only once the domain, the mailboxes and the site have been verified in their new home.
Generic endings such as .com or .net follow their own rules, because there the transfer policy of the Internet Corporation for Assigned Names and Numbers applies. It defines three lock periods of 60 days each (ICANN): after the initial registration, after a registrar transfer and after a change of registrant, unless the holder opted out of that lock in advance. From this follows a practical sequence that the policy points out explicitly: anyone planning to do both should transfer the registrar first and change the registrant afterwards (ICANN). Conversely, a lock the holder set themselves has to be removed by the registrar on request within five calendar days (ICANN), or a reasonable means of doing so has to be provided. The operative version is currently the one dated 21 February 2024 (ICANN), which had to be implemented by 21 August 2025 (ICANN) at the latest.
Take the mailboxes with you instead of recreating them
The most common avoidable loss when switching providers is the correspondence. If mailboxes are simply created from scratch in the new location, the existing archive stays behind with the previous provider and disappears when the contract ends. For a business those are quotes, order confirmations, appointment arrangements and complaints – records that count in a dispute and that, depending on their content, are subject to commercial and tax retention obligations. Technically the move is straightforward as long as the mailboxes are reachable via IMAP: with that protocol the messages stay on the server together with the folder structure and can be copied wholesale to another server (RFC 3501, IETF). The timing is what decides: copying happens while both accesses still exist – so before the cancellation, not after it.
- Record all addresses on the domain, including distribution lists, forwards and rarely used functional addresses.
- Create the mailboxes in the new location with the same addresses so that nothing changes on the outside.
- Copy the existing archive via IMAP while the old access is still available (RFC 3501, IETF).
- After copying, spot-check folders, attachments and date stamps against the original.
- Set the sender verification entries anew so that outgoing mail is delivered.
- Choose a provider whose e-mail service has been tested against Technical Guideline TR-03108 (BSI).
- Recreate signatures, out-of-office notices and sorting rules in the mailbox.
- After the switchover, send a test message from outside and have receipt confirmed.
The archive is a business record, not ballast
Securing content, images and addresses
Securing the content has two sides. One is obvious: texts, images, documents, price lists, form texts and legal texts belong exported in full while the access still exists. Back up photos at the resolution in which they were uploaded. The other side is forgotten more often: the list of addresses. Every subpage has an address, and search results, directory entries, links from partners, stickers on vehicles and details in printed material all hang on that address. This list is assembled from several sources together: from the existing sitemap, from the server logs and from the analytics data on which pages were actually opened. How content can be collected continuously instead of being scraped together shortly before the move is shown in the article on website content from everyday work. The entry in the business profile belongs on the list as well, because it frequently appears ahead of the website in local searches – its upkeep is described in the article on the Google Business Profile.
The redirect plan grows out of the address list. Every previous address gets a new target, and specifically the one that matches in content rather than the home page across the board. The correct status code for a permanent move is 301 (RFC 9110, IETF), which marks the new address as final; the newer code 308 (RFC 9110, IETF) does the same and additionally preserves the request method. How long these rules should stay in place is documented: at least one year (Google Search Central). If the domain name changes at the same time, the address change should additionally be reported via the search console (Google Search Central). How to build and verify such a plan systematically is described in detail in the article on a relaunch without ranking loss.
A provider switch rarely fails on technology. It fails on sequence – and on cancelling before the successor was standing.
The switch day and the hours after it
The switchover itself is a short operation with a long after-effect. As soon as the new entries are set in the Domain Name System, caches around the globe still know the old values. How long for is determined by a number that belongs to every entry: the validity period, called Time to Live in the standard (RFC 1035, IETF). If that value is set to several hours, individual visitors will still see the old server for hours. That is why it is lowered to a short value one or two days before the switchover and raised again afterwards. Even so, plan for a transition window of several hours up to a few days in which both states should remain reachable in parallel – old and new site, mailboxes included. That is exactly why the old contract is not ended on the switch day.
The timing of the switchover is a business decision, not a technical one. Put it in the quietest period of your operation – for many trade and service businesses that is the early morning of a working day on which someone is available, and explicitly not the Friday evening before a long weekend. Your own figures show when things are quiet: the distribution of visits across the day appears in any traffic report. Also avoid dates shortly before trade fairs, seasonal peaks or promotional periods. And make sure that on that day one person has time to work through the checklist – a move that everyone considers finished while the results go unverified is the most common cause of errors discovered late.
- Open the home page and the ten most visited subpages from an outside network, not just from the office Wi-Fi.
- Check the certificate: valid, issued for the right domain, no browser warning.
- Submit every form once and confirm that it arrived in the target mailbox.
- Send a test message to every mailbox from an external address and send the reply back.
- Open a sample of old addresses and check that the redirect ends at the target that matches in content.
- Review the search results for important terms and watch for reported errors in the search console.
- Check the entry in the business profile and in industry directories against the new address.
- Proofread the phone number, directions and opening hours, because those details slip easily during a rebuild.
Two things deserve additional attention in the days that follow. First, availability: a silent outage during the transition phase only surfaces without monitoring when someone calls – how to observe this automatically is described in the article on outages and availability. Second, the enquiries: a drop that coincides with the switchover usually has a mundane cause in the form path or in delivery. Whether calls from the website still arrive can be measured as well, as the article on calls from the website shows. For the weeks after going live there is a list of its own in the article on the first weeks after launch.
When the previous provider will not cooperate
It does happen that a provider fails to respond to a request for the auth code or attaches conditions to it. For .de domains there is a regulated route for this: if the previous provider stays inactive, the holder can have an auth code generated directly at the registry via the future provider; it is sent by registered mail to the holder address stored in the register (DENIC eG). That presupposes that this address is current – another reason to check the register entry early. For generic endings the situation is similarly regulated: the transfer policy lists which grounds support a denial and which do not. Denial for non-payment for a future or current renewal period is expressly not permitted (ICANN). Nor does a registrar lock support a denial if the holder had no reasonable opportunity to remove it before placing the order (ICANN).
If content and data remain in dispute, it helps to look at the data processing agreement, which should exist anyway for any website with forms and server logs. Article 28 paragraph 3 point (g) of the General Data Protection Regulation obliges the service provider to delete or return all personal data at the controller's choice after the end of the service (General Data Protection Regulation, Article 28); in total, paragraph 3 prescribes a catalogue of eight (General Data Protection Regulation, Article 28) mandatory contents. Request the handover and a subsequent deletion record in writing and set a reasonable deadline. For businesses that handle ongoing service matters through the website it is also important that those paths stay reachable during the switch; how to build such paths is shown in the article on service forms for existing customers.
How XICflow handles the migration
For a small business the switch is above all a question of capacity: the steps are easy to follow, but they demand attention alongside daily operations over several weeks. That is exactly the work XICflow takes over. We record the inventory, collect domain, mailboxes and content, and build the new site in parallel while the existing site keeps running unchanged. The switchover happens only once the new version has been checked – in a time window that suits your business. The redirects for all previous addresses are fully prepared before the switchover, and we verify mailbox delivery with real test messages in both directions. Which building blocks are included is shown in the overview of XICflow services; how a site comes together is described in how XICflow works.
The pages are delivered as static HTML, which keeps the attack surface small and the loading time short. Cookie-free traffic measurement runs alongside, so that after the move you can see whether visits and enquiries are at their usual level. We recommend cancelling the old contract only after a review week – that keeps the way back open if something needs adjusting. What finished sites look like can be seen in the example websites in the demos, and what the build costs is shown in the pricing overview. If business mail runs unreliably after the switch, the article on business e-mail deliverability helps with the fine tuning.
Sources and Studies