Plenty of businesses stay with a supplier who no longer suits them, for fear of breaking everything on the way out. The fear is real, and it is largely unfounded: switching web agency or host is a well marked passage, and the risk sits on three points only. Better still, those three points can be dealt with before you have said a word to anyone. Here is the method, in the order in which we apply it when we take over an existing site.
First of all: what do you actually own
Before talking about migration, you need to know what belongs to you. Five assets, to be checked one by one:
- The domain name and its registered holder. This is the single most important point in the whole article. A domain registered in the supplier’s name is the most paralyzing situation there is: without them you can neither transfer it, nor edit the zone, nor even recover your email. The holder can be checked with your registrar or through the public directories (Afnic, managing your domain name, in French).
- The hosting and the account holder. Hosting billed to the supplier, on the supplier’s own account, means you are the tenant of a space whose door you cannot open.
- The code and the plugin licenses. A premium plugin bought by the agency on its own developer license stops receiving updates the day you leave. Make the list, it is usually a long one, and insist on a code repository that belongs to you.
- The content and the rights to the photographs. A stock image library licensed to the agency does not travel with the site.
- The third party accounts: analytics, search console, business email, payment module. You need to appear on each of them as the owner, not as an invited user.
A word on timing, which is often ignored: on generic extensions such as .com, a recent transfer or a change of holder locks the domain for sixty days. So check ownership before you announce your departure, not after.
Getting your access back without a fight
The vague request, “please transfer the site to us”, never produces anything you can use. Ask in writing for a precise list, which makes a refusal visible and a reminder easy to send:
- An administrator account on the site in your own name, and confirmation that no other active accounts exist.
- Access to the hosting panel, to the SFTP accounts and to the database.
- Access to the account at the domain registrar, or the transfer code. That code must be handed over to you, within a few days at most, from the moment you are the registered holder.
- The code repository if there is one, and the deployment documentation.
- Owner rights on the analytics tools and on the search console.
- A complete, dated export: files, database, media.
A decent supplier makes leaving easy, because they know that a clean separation leaves a good reputation behind. Conversely, how readily the logins come back to you says a great deal about the relationship you were in. Stay factual, in writing and dated: that is what gives weight to a formal notice, if it has to come to that. We do not give legal advice, but we do observe that a precise written request settles the matter in the great majority of cases.
The three real risks in a migration
Everything else is logistics. These three deserve your attention.
Losing page addresses
Risk number one. Any address that changes without a permanent redirect carries away with it the ranking that address had built up, and turns every external link pointing at you into a page that cannot be found. The counter to it is a complete inventory before the switchover: a crawl of the existing site, the sitemap, the addresses known to the search console, the server logs to recover the forgotten pages. That gives you a list, then a mapping table of old address to new address, line by line.
Losing recent data
Between the copy and the switchover, life goes on: orders placed, messages sent, accounts created. That data exists on the old environment and not on the new one. The counter to it is a short write freeze, often one to two hours in the middle of the night, with a differential copy taken just before the switch, then a manual catch up on what is left over.
Cutting off the email
The classic trap. When you change DNS zone, you recreate the records for the site and forget the ones for the mail. Write down the complete zone before you change anything, recreate every record identically, and delete nothing until the new environment has been signed off. A business can weather two hours without a website; it cannot weather two hours without email.
The switchover checklist
In order, with the consequence of skipping a step.
- An inventory of the existing addresses. Skipped: pages disappear without anyone noticing for months.
- A complete copy on the new environment, files and database, plus a full backup before any switchover, stored off the server. Skipped: there is no way back.
- Functional tests on a private address that is not indexed, protected by a password. Skipped: the test copy ends up indexed and starts competing with the real site.
- A redirect plan written and tested before the switchover, using permanent redirects. Skipped: this is the leading cause of a drop in traffic after a migration.
- A shorter lifetime on the DNS records, twenty four to forty eight hours beforehand. Skipped: propagation drags, and a share of your visitors keeps being sent to the old server.
- A switchover window in the trough of activity. Skipped: you discover the faults at the same moment as your customers do.
- The old environment kept readable for several weeks. Skipped: the missing piece of data you notice three days later is gone for good.
- A check on the certificates on the new hosting, before and after the switchover. Skipped: a security warning greets your visitors.
- Submission of the new sitemap and, if the domain changes, a declaration of the move in the search console (Google documentation on moving a site).
- Errors and traffic watched for a month. Skipped: the problems show up in the following quarter, when it is too late to connect them to the migration.
One point of calendar: Google recommends keeping the redirects for at least a year. Do not schedule the closure of the old domain for three months after the switchover.
The thirty days that follow
The migration does not end at the moment the site appears. Five checks, to be kept up for a month: the list of pages that cannot be found in the search console, which should trend toward zero; traffic compared by group of pages rather than in aggregate, because an average fall of 5% can hide a collapse in one section; the indexing of the important pages; forms and payments working properly, tested for real with a real order; and the feedback from your customers, who always spot what the tools do not see.
A limited dip lasting two to three weeks is normal, and Google documents it: visibility fluctuates while the new addresses are being processed. A dip that persists beyond a month is not normal, and almost always signals a redirect or indexing problem rather than something you have to accept.
Taking over a badly built site: how far to go
The case comes up constantly and is rarely handled honestly: the new supplier lifts the hood and finds a fragile site. Three options only, and the choice is made on criteria you can observe.
| What you find | The reasonable decision |
|---|---|
| Standard theme, plugins up to date, clear structure | Take it over as it stands and document it |
| Redundant plugins, a few adjustments in the theme, PHP behind | Clean it up gradually, in batches |
| Theme edited directly with no child theme, abandoned plugins, no documentation | Rebuild, keeping the content and the addresses |
The decisive criterion is the theme edited directly: every update wipes out the work, so nobody updates any more, so the site ages until it becomes vulnerable. When that point is combined with plugin debt and an out of date version of PHP, cleaning up costs more than rebuilding. The signals to watch are set out in the signs that a redesign is due.
The zero downtime migration procedure we apply is described on our page for website hosting in Pau, in south west France.
Where we stand: the six questions to ask your next supplier
We do not think a client should have to trust: we think a client should be able to check. Six questions, to be asked before signing, and the answers to them fit on a single page:
- Who will be the holder of the domain name and of the hosting account? The only right answer is: you.
- Where will the code be kept, and will I have read access to it at any time?
- What is the backup policy, how often do backups run, where are they stored, and when was a restore last tested?
- How are requests tracked, and within what response time?
- What happens if we leave? Ask for that answer in writing: it is the question whose answer tells you the most about the years ahead.
- What exactly does the monthly support cover, and what is billed on top of it?
That is the logic behind our packages with hosting and support included, from €59/month plus a registration fee (VAT not applicable, article 293 B of the French tax code): domain and hosting in the client’s name, full access handed over on day one, and no technical lock on the way out. Before any commitment, we start with a takeover audit and guided migration that draws up the inventory of what you actually own. To compare several suppliers, our guide on how to choose a web agency rounds out this list.
Conclusion
You do not leave a supplier: you take your site back. Once the question of ownership is settled, the rest is a well marked technical operation, in which every step has a known consequence if you skip it. Start with the one point that can genuinely hold you fast: check today who is the registered holder of your domain name.
Have the takeover of my site audited Talk about my current site
