A step-by-step guide to migrating your blog to a new host

Moving a blog means transferring its files, database and configuration while preserving the same public URLs, working email and search visibility. The switch may take only a few hours, but a missed redirect, stale DNS record or incomplete database can undo hours of careful preparation.

This process works for WordPress and similar content platforms, with small adjustments for other systems. It also accounts for Australian conditions such as .com.au and .au domains, local support hours, AUD billing and privacy expectations.

Build a complete inventory before the move

Create a written inventory of your CMS version, PHP version, database, extensions, media files, cron jobs, SSL certificate, DNS records, email accounts, CDN, analytics and backup settings. Record where each component is hosted so nothing depends on an undocumented feature of the current server.

Use Google Search Console and analytics to record your indexed URLs, top landing pages, organic traffic, backlinks and popular posts. Save a copy of your current sitemap, robots.txt file, canonical tags and redirect rules. These references provide a baseline for identifying missing content or broken URLs after the move.

Leave your domain with its current registrar unless there is a separate reason to transfer it. Changing hosts does not require changing .com.au or .au registration, and auDA eligibility rules remain relevant to the registrant. Reducing DNS time-to-live now will make the eventual cutover faster.

Choose hosting that fits traffic and support

Match the new plan to your traffic, storage, database requirements and budget. Check uptime, page speed, support response times, backup frequency, security features and whether the provider offers assisted migration. A cheap plan that lacks database access or staging may create extra work later.

Shared hosting is usually sufficient for a small or moderately sized blog, while a VPS or managed WordPress service suits higher traffic, custom configuration or resource-heavy plugins. Avoid choosing by price alone: confirm PHP limits, email allowances, CDN support and the provider’s restoration process for failed migrations.

For Australian buyers, compare the final AUD cost, including GST where applicable and any foreign card fees. A Sydney or Melbourne data centre can reduce latency for local visitors, while support hours should remain useful across AEST and AEDT. A global CDN may matter more than server location for readers farther from the data centre.

Create and verify a recoverable backup

Back up both the database and website files. For WordPress, an export such as wp db export blog-backup.sql captures the content, while an archive of wp-content preserves themes, plugins and uploads. Use equivalent export tools if your blog runs on another CMS.

Download the backup to a separate device or cloud storage location, then confirm that the archive opens correctly and the database file is readable. Store administrator credentials, DNS details, database settings and encryption keys in a secure password manager. Test a restoration if your hosting provider offers one.

Keep the existing account active until the new site has passed testing. Its files, database and DNS records act as your rollback plan. Avoid deleting anything until search visibility, email delivery and analytics have remained stable for several days after the cutover.

Transfer the site into the new environment

Create the destination hosting account and, where possible, a staging subdomain. Transfer the database and files using the provider’s migration tool, an SFTP client or a command-line utility such as rsync. Uploading through a local plug-in can work for smaller sites, although large media libraries may take longer.

Update database credentials, site URL, home path and file permissions in the new configuration. Import the database before changing any path references, then confirm that the CMS recognises the installation. Clear its cache and test the dashboard, editor, comments, media library and scheduled tasks before making the site public.

Use a staging copy for search-and-replace operations so mistakes can be corrected safely. Replace old domain names, temporary paths and database prefixes without changing public slugs unnecessarily. For large uploads, run the transfer in smaller batches and verify file counts against the original inventory.

Preserve domains, URLs, email and trust

Reduce the DNS time-to-live at least 24 to 48 hours before launch. At cutover, update the website’s A or CNAME record to the new server, then confirm that nameservers and the domain registration remain unchanged. Leave the old hosting account running briefly so traffic can be redirected if necessary.

Keep every existing post and category URL unchanged whenever possible. If a URL must change, create a direct 301 redirect to its equivalent page rather than the homepage. This protects backlinks and organic rankings while allowing the new structure to settle. Regenerate the sitemap and validate it in Search Console after the switch.

Install the SSL certificate on the new server and redirect HTTP traffic to HTTPS. Test certificate renewal, mixed-content warnings and canonical tags. Secure pages, clean URLs and consistent redirects all help preserve trust accumulated through years of publishing and link-building work.

Migrate email separately from the website by creating the required mailboxes and updating MX, SPF, DKIM and DMARC records. Send test messages to several external providers and check spam folders. If the current host no longer handles email, your existing sending reputation may need time to recover after the records change.

Confirm where subscriber data, backups and logs are stored, including any overseas servers or subprocessors. For covered businesses, check the provider’s arrangements against the Australian Privacy Act and OAIC guidance where applicable. Obtain a copy of the relevant agreement before uploading personal information.

Run a staged acceptance check

Test the staging site as an ordinary visitor and an administrator. Open every important page, submit contact forms, publish a test post, upload media and process a small transaction if the blog sells anything. Check browser errors, server logs, redirects, search previews and the password-reset flow.

Include real mobile devices in the test matrix. When choosing which models to cover, current release lists such as current mobile arrivals can help identify recent Android and iPhone devices worth testing. Check menus, tap targets, image compression and horizontal scrolling on mobile connections.

Use this comparison as the final acceptance check:

Area	Existing host	New host	Required result
Content	Pages, posts and media inventory	Imported content and uploads	No missing files or records
Core URLs	Indexed pages and current redirects	Same paths or permanent redirects	Direct response or one-hop 301
Functions	Login, comments, forms and cron	Repeated on staging	No errors; submissions arrive
Email and security	SPF, DKIM, DMARC and SSL	Reissued and validated	No lost mail; valid certificate
Measurement	Analytics and Search Console baseline	Events and property verified	No unexplained traffic loss

Compare page loads, server errors and database queries with the original environment. Pay particular attention to slow images, plugin conflicts and memory limits, since a visually complete page can still perform poorly. Document any differences and resolve them before changing DNS.

Launch with a controlled cutover and steady monitoring

Schedule the switch during a quiet period in Australian time, using analytics to identify when your readership is least active. Pause publishing and unnecessary automation, take a final backup and lower the DNS time-to-live if you have not already done so. Update the website record, clear caches and monitor the first visitor requests closely.

Watch analytics, Search Console, uptime, server logs, forms and outbound email for at least 72 hours. Investigate 404 reports, indexing changes, sudden referral losses and unusual database activity. Keep the old server available but do not leave it serving duplicate content, as that can confuse search engines and split your signals.

Choose your destination host today, complete the inventory and set a cutover date with a tested backup ready for immediate rollback.