Moving a site between accounts without downtime

Sites end up in the wrong account. One grew and now shares a ceiling with twenty small sites. Another needs a PHP version the rest of its account cannot use. Moving it is a routine operation, and the only part that needs care is the order you do things in.

Why you would move one

• It has outgrown the ceiling it shares with its neighbours.
• It needs a PHP version that would break the others in the same account.
• It should answer on its own address and currently does not.
• It is being sold or handed to a client and must stand alone.

The sequence that avoids downtime

1. Lower the DNS record's time to live first. Do this a day ahead. If the record is cached for hours, nothing you do afterwards takes effect quickly, and this is the step everyone skips and then regrets.
2. Create the destination account with the package, limits and dedicated address you want it to end up on.
3. Copy the site across while the original stays live and serving. Files and database both.
4. Test it on the new account before switching anything, using the temporary access method rather than the live domain.
5. Freeze changes. No publishing, no orders, no form submissions you care about, for the length of the switch.
6. Re-sync the database immediately before the switch, so nothing written during testing is lost.
7. Point the domain at the new address. With a low time to live this propagates in minutes.
8. Keep the old account for a few days before removing anything.

The parts people forget

• Cron jobs. They belong to the old account and will keep running there, quietly writing to a database nobody is reading any more.
• Email. If the domain had mailboxes, they do not follow the files.
• Certificates. A new account means issuing a certificate for the new location, before the switch rather than after.
• File paths. The absolute path to the site changes with the account name. Anything with a hardcoded path breaks: cron commands, config files, cached compiled templates.
• Database credentials. The user name is usually prefixed with the account, so it changes and the site's configuration must change with it.

That last pair causes most of the "it worked in testing" failures. The site works on the new account because you fixed the config there, then someone restores an old backup and reintroduces the old credentials.

What the visitor experiences

Done in this order, effectively nothing. During the switch some visitors resolve to the old address and some to the new one, and both are serving the site, so both work. The only genuine gap is writes: anything submitted to the old copy during the window does not exist on the new one. That is why step five exists and why the window should be short and quiet.

When not to bother

If the only reason is a resource ceiling and the site is not actually hitting it, moving accounts achieves nothing. Check the fault counters first, as described in Platform and Limits. And if the real requirement is root access or a service the panel does not offer, an account move will not deliver that either; that is the case for a VPS.

The transfer tooling is documented at docs.cpanel.net. For a full move from another provider rather than between your own accounts, see Moving In.