Changing website vendors: what to recover before the switch

Anyone switching vendors almost always discovers two things on the same day: that the site is the easiest part of the switch, and that some things they thought were theirs are registered to someone else. The real risk isn't losing pages, which can be rewritten: it's going two days without email, or no longer being able to prove the domain is yours.

It's worth doing the inventory beforehand, while everything is working and there's no rush. It's also the only thing that lets you understand how much the switch will cost: a site that can be rebuilt in two weeks and a site tied to services registered to other people are two different quotes.

Registration and access aren't the same thing

Having the credentials to a control panel doesn't mean you own what's inside it. These are two separate layers, and they need to be checked separately.

• The registrant is whoever is listed as the owner of the service: it's the position that matters when something needs to be recovered, and it needs to be your company.
• The administrator is whoever can change settings, add and remove other users. This can also be the vendor, as long as you're included too.
• Operational access is whoever logs in every day to work. It's the least important of the three levels, and the only one that's usually handed over without issue.

For the domain, registration can be verified externally, on public registries, within the limits set by personal data privacy. For everything else, you look inside the control panels, receipts, and contracts.

The inventory: what to list

The list needs to be written down, not kept in your head, because it helps the new vendor put together a sensible quote and helps you notice what's missing.

What gets exported and what gets rewritten

Not everything you see on the site can be recovered in a reusable form. The distinction needs to be made beforehand, because whatever can't be exported needs to be quoted as new work.

• Text and images: images are needed in their original format, not just the compressed version published on the site.
• Data: orders, customers, received requests, newsletter subscribers. These need to be requested in a readable format and handled with the care required for personal data.
• Email archive: it's not enough to have new messages arrive; you need to bring the old ones along too.
• The structure of page URLs and any redirects already in place.
• Invisible automations: forms, automatic confirmation messages, connections to other systems. This is almost always the part that gets rewritten.

The rule is simple: if something can't be exported in a readable format without asking the old vendor for help, treat it as something to redo.

Services registered to the vendor: knowing beforehand

Some things are legitimately in the vendor's name. A license bought by the agency, a resold service, a tool shared across several clients. It isn't an abuse, but it changes the picture.

• Personal licenses don't transfer: when they expire, they need to be repurchased in your name, or the function needs to be replaced.
• Resold services shut off when the relationship ends, even if the site keeps working for a few more weeks.
• Customizations built on a base the vendor owns may not be reusable elsewhere.

Asking for a list of these items in writing, plainly and without friction, is a normal request and usually gets a response.

The plan: who does what, and in what order

1. Set a date after which no one publishes any more changes to the old site: two versions changing at the same time produce differences no one can piece back together.
2. Make a complete copy and actually verify it: download it, open it, check that everything is there. A copy that's generated and never opened isn't a copy.
3. Rebuild and test the new site while the old one is still online and reachable.
4. Move the mail separately from the site, with the records verified before the switch, because it's the service that can't tolerate interruptions.
5. Change the routing records during a low-traffic window, and not on a Friday afternoon.
6. Keep the old environment active for an agreed period, read-only, until it's clear it's no longer needed.

Every line needs a name next to it. A plan where actions have no owner produces the worst case: two people each waiting on the other while the domain expires.

Checks after the switch

The moment you discover something didn't work shouldn't be a phone call from a customer. Tests get done right away, and repeated the next day.

• The site on a mobile network and from a connection other than the office's.
• Contact forms: send a real request and verify it arrives where it should, not just that the confirmation message appears.
• Incoming and outgoing mail, tested from an address outside the company too.
• The URLs of the most-visited pages and the old ones printed on materials or present in old links.
• The security certificate and its automatic renewal dates.
• The measurement tools: that they keep recording, and from which day.
• Restricted areas and payments, if they exist, tested with a real transaction of minimal amount.

When it's worth postponing

The switch has no mandatory date, and doing it at the wrong moment costs more than it saves.

• During peak season or an ongoing campaign: a day of email downtime is worse than a month of waiting.
• If the registrations aren't sorted out yet: fix the domain and mailboxes first, then move the rest.
• If no one at the company has time to follow up on the checks in the days after.
• If there are open orders, ongoing matters, or data that's changing while you're copying.

Postponing by a month is a decision; discovering halfway through the switch that access is missing is an incident. The difference between the two is the inventory done beforehand.

What this guide doesn't cover

This guide covers the operational switch: what to recover, in what order to move it, what to check afterward. What existing contracts provide for, who owns the rights to the work done, and what notice periods apply are found in the signed documents and, in doubtful cases, should be assessed by a professional. Continuity on search engines — URLs, redirects, equivalent content — is covered in the dedicated guide on redesigning a site without neglecting SEO.