Migrate your website without downtime

Moving a website to a new host without downtime requires careful preparation rather than a quick change to DNS records. The files, database, email routing and domain settings must work together, so replacing only the server address can leave a business with broken forms, inaccessible pages or lost enquiries.

Most migration failures happen because the new copy is not tested, the final database sync is missed, or the old hosting is switched off too soon. A controlled cutover gives the new host time to prove itself while the existing service remains available as a safety net.

For Australian businesses, the plan should also account for regional internet conditions, local traffic patterns and Australian privacy requirements. Whether the site serves customers in Perth, Brisbane or overseas, the objective is a transfer that visitors barely notice.

Plan the change around Australian traffic

Begin with a complete inventory of the current website. Record every subdomain, page, database, application, script, redirect and third-party service. List the DNS records for web hosting, email, subdomains and any Australian payment or marketing integrations. Also note the hosting panel, registrar, domain renewal dates and administrator access details.

Choose a cutover window based on when the site receives the least traffic. Sydney, Melbourne, Brisbane, Adelaide and Perth sit in different Australian time zones, while daylight-saving changes can temporarily alter familiar schedules. Early morning Sunday is often practical for Australian sites, although businesses with international customers should compare activity in the relevant overseas markets.

Lower the web records’ time-to-live value at least 24 to 48 hours before the move. A value such as 300 seconds tells resolvers to check the DNS more frequently, reducing the period in which visitors may reach the old server. Do not alter unrelated records, especially those controlling mail delivery.

Prepare an exact copy of the site

Create the new hosting environment with matching PHP, application and database versions. Transfer website files, hidden configuration files, media, cron jobs, user-uploaded content and the database. For a WordPress or similar content-managed site, check that the migration has not replace the database prefix or alter stored paths.

Configure a staging address so the copied site can be tested privately. Its database should contain a recent copy of production information, and its configuration should use secure test credentials where possible. Confirm that the staging copy cannot send live customer emails, trigger campaigns or duplicate payments while testing is underway.

Teams that want a managed hand can ask Whipnet for migration support to handle environment setup, transfers and verification. If the website uses a .com.au or .au domain, keep the existing registration with the authorised Australian registrar, but be prepared to update the hosting names or address records at cutover.

Test the new environment thoroughly

Test every page, form, search function, member login and checkout on the staging address. Submit real-looking test orders and enquiries, then confirm that they reach the intended inbox and appear correctly in the database or customer relationship system. Check image uploads, downloadable files, redirects, error pages and administrator tools.

Compare the new copy with the live site for visual and functional accuracy. A successful data transfer can still introduce incorrect image paths, missing fonts or menu differences caused by a mismatched theme. Test on common desktop and mobile browsers, because many Australian visitors encounter websites through mobile broadband or a phone before trying a larger screen.

The new host should also perform adequately for Australian conditions. NBN connections, fixed-line services and regional mobile networks can behave differently, so test page loading from several locations rather than relying on a fast office connection. Include any CDN or caching service in the checks and make sure it can be purged immediately after the switch.

Switch traffic with a controlled cutover

Begin the final transfer by briefly pausing content updates or maintenance tasks that could alter files or database records. Run one last incremental file sync, export the newest database entries and apply any configuration changes needed for the production domain. Test the updated copy locally or through the staging address before changing public DNS.

Update the web address records to point to the new host, keeping the previous records documented. DNS changes are not instantaneous everywhere: some visitors will use the new address within minutes, while cached information may take longer to expire. The old host should remain online during this period and continue serving anyone who still reaches it.

After the new site begins receiving traffic, check the HTTPS certificate, canonical URLs, contact details and transaction flow again. If a CDN is active, clear its cache so pages do not mix content from the two servers. Avoid cancelling the old hosting until monitoring shows stable traffic and no errors.

Monitor services and keep rollback ready

Watch server logs, uptime monitoring, bandwidth use, database errors and support tickets for at least the first few hours. Compare real-time traffic and form submissions against the previous period so an apparently successful DNS change is not masking a broken application. Check that Google Analytics or another analytics platform is recording activity without counting the staging environment.

Email needs separate verification because it may continue working even when the website is failing. Confirm that mail for Australian staff and customers arrives through the correct MX records, and review SPF, DKIM and DMARC settings. The Spam Act 2003 governs commercial email in Australia, so a hosting change should not disrupt consent records, unsubscribe functions or sender identification.

Keep the previous server, database snapshot and DNS values ready for a fast rollback. Define clear triggers in advance, such as sustained server errors, failed payments or missing form submissions. Do not delete old accounts immediately; another careful migration in the following week is preferable to restoring a service during an incident.

Secure the site and document the new setup

Rotate passwords, API keys, database credentials and secure-file salts where appropriate. Review administrator accounts, remove former staff access and apply current security updates. Ensure automated backups run on the new host and test a restore, rather than assuming a successful backup message proves the data is usable.

Australian privacy obligations may continue to apply after the hosting provider changes. If the site collects personal information, confirm that data locations, disclosure policies and consent mechanisms meet the Privacy Act 1988. The Australian Consumer Law also remains relevant to the service being sold, even though the technical infrastructure has moved.

Document the final configuration, including DNS records, server paths, cron schedules, backup settings, renewal dates and recovery steps. A shared runbook prevents essential knowledge from remaining with one former host or contractor. It also makes future platform changes, security patches and even a complete migration much easier to manage.

Contact Whipnet for a practical migration assessment and a clear cutover plan for your website, domain and email services. Move with a tested copy, a controlled DNS change and a rollback option so your customers keep uninterrupted access throughout the transfer.