How to bring a client site onto your platform

Bringing an existing client site onto your platform is a slightly different job to migrating your own — the client is watching, they have a business relying on the site staying up, and a mistake here is also a first impression of what hosting with you is going to be like. The technical steps are the same as any migration; what changes is how much margin you should leave yourself for things going slightly wrong.

Audit before you touch anything

Find out what you are actually moving before you start moving it. At minimum: what the site runs on, whether there is a database and what it needs to connect to it, how many mailboxes exist and what they are, and anything non-obvious — a cron job, a custom script, an integration with a third-party service tied to a specific IP address. Ask the client directly if you are not sure; a five-minute question now is considerably cheaper than discovering a missing piece after the domain has already switched over.

Set up the account correctly the first time

How to create a hosting account for a client covers creating the account itself. Size it to what the audit actually found, not to your smallest available plan — a migration that immediately runs into a resource limit is a poor start to the relationship.

Move the site without moving the domain yet

Copy the files and database to the new account while the domain's DNS still points at the old host. This is the step that removes almost all the risk from the process, because the live site is untouched throughout — if something on the new account needs fixing, you are fixing a copy, not the thing the client's visitors are currently using.

Preview it properly before switching anything

Once the copy is in place, load it without changing DNS — either through a temporary URL your hosting provides, or by editing your own computer's hosts file to point the domain at the new account just for you. Click through the site as if you were a visitor: check forms submit, check the database-driven parts work, check email addresses referenced anywhere on the site are correct. This is where you find the problems that a quick glance at the file list would not show you.

Agree the switch-over window like a real event, not a formality

Tell the client when you plan to switch DNS, roughly how long full propagation can take, and what — if anything — they should expect to notice. Avoid doing this in the middle of a period that matters to their business, such as a launch or a busy sales period, unless the migration is specifically part of that. See how to plan a migration window for choosing the timing properly.

Switch DNS, then actually verify it

Point the domain at your platform — see pointing a domain at hosting for the mechanics if you have not done this before — and then confirm the change from more than one network, not just your own connection, which will often be the slowest thing to update because of local caching.

Do not cancel the old hosting immediately

Keep the previous hosting account active for a short overlap period after switching. DNS changes take time to spread everywhere, and visitors reaching the domain through a slower-updating network will still see the old host during that window — which is exactly why it needs to still be there and still working. Cancel it only once you have confirmed the new site is answering consistently.

Finish with email and a final check

If mailboxes were part of the move, set them up on the new account and confirm mail sends and receives correctly before telling the client it is done — a working website with broken email is still a broken migration from the client's point of view. Run back through your original audit notes one more time and confirm every item on it actually made the move.

A migration handled this carefully takes a little longer than the absolute minimum required to move some files, but it is also the version of this process that does not produce a support ticket from a panicked client three hours after you thought you were finished.