Moving a website to cloud hosting without downtime
Moving a website to cloud hosting without downtime is a planning job first and a technical job second. The public site should keep answering while you prepare the new home. List what the current site uses: the database, uploaded files, email, scheduled tasks, forms, search, and any keys for payment or maps. The forgotten piece is usually a form that writes to a folder nobody documented, or a nightly job that rebuilds a feed. If you do not list it, you will discover it after the domain has already moved.
Decide why you are moving, because the reason changes the setup. You may need more reliable backups, a newer language version, room for traffic spikes, or a host your team can actually reach for support. Cloud hosting is not automatically faster or safer. It helps when someone owns updates, monitoring, and the bill. Pick a region close to your visitors if the provider asks, and confirm that email will stay where it is or move with a written plan. Email is the part most likely to surprise people on the day.
Build a copy and test the paths people use
Copy the files and the database to the new environment and point a temporary address at that copy. Do not change the public domain yet. Click the home page, the main service pages, the contact form, the login, and the checkout if you have one. Submit a test enquiry and confirm it arrives in the right inbox. Open the site on a phone. Check that images load and that links do not still point at the old host. A test that only loads the homepage will miss the paths customers actually use.
Compare versions before you call the copy ready. The new server should run the language, database, and web server versions your site supports. Turn on the same redirects you already rely on, including links from old campaigns. If the site has a search index or a cache, rebuild it on the copy and then load a page twice. Scheduled tasks should run once in the test so you can see their output. Freeze content edits for the final copy, or you will launch an older page someone updated that morning.
The hour you switch the domain
Lower the DNS lifetime a day or two before the switch so the change spreads faster when you make it. Take a fresh backup of files and database in the hour before you move, and know how to put that backup back on the old host. Move the latest copy, test the temporary address one more time, then update the website DNS. Keep the old host online. A move is not finished when the new address works for you. Some visitors will still reach the old server until the change catches up, so both copies should be safe to view.
Watch mail through the switch. If email stays with the current provider, do not change those records by accident while you edit the website records. If email moves too, test sending and receiving from an outside address before you tell the whole company. Forms that send mail through the host need the new credentials, or enquiries will fail quietly. Payment and newsletter keys should be updated in the new setup and removed from any scratch file. Write down the time you switched and the person who can reverse it.
Watch the day after, then close the old host
For a full day, watch the error log and one real journey: a page, a form, and a reply. Ask a colleague outside the office to try the site on a phone network, because your own connection may still be showing a cached path. Check the certificate so HTTPS remains valid on the new host. Look at analytics only as a hint. A sudden drop can mean the tracking code was lost in the copy, or it can mean a page is broken. Confirm which one before you celebrate or panic.
When the old host has been quiet and the new site has behaved, cancel the old plan on purpose rather than letting a card expire. Download a final archive first. Update the notes: where the site lives, who can log in, how backups run, and how to renew the domain. Cloud accounts often have more than one user. Remove people who do not need access, and keep a second owner on the billing account so a single lost login does not strand the company. The move is complete when the next person can find those notes without a meeting.
Leave the clutter on the old server
Do not copy clutter just because it is there. Old plugins, unused themes, and test folders can move with the site and become the first thing that needs patching. This is a fair moment to retire a form you no longer read, or a staging copy that still has a real password in a public folder. Keep the redirects that protect old links. Drop the experiments that never launched. A smaller site is easier to host, easier to back up, and easier to explain to the next developer who inherits it.
Tell the team when the move is finished and what, if anything, looks different. Editors should know the new login address. Finance should know the new invoice. If something still points at the old host, fix that reference rather than leaving a private note that only one person can find. A written rollback you did not need is a success, not a waste of the morning. Vyon Media plans these moves so the public site stays up while the new hosting is proven.
