Treat a migration as a controlled change
Moving hosting is a good opportunity to improve your environment. It is also a change to how the application reaches its files, database and visitors. A practical migration plan keeps those moving parts visible and gives you a way back if a problem appears.
For a straightforward move, keep the existing domain and URL structure wherever possible. If you also change URLs, prepare a separate mapping of each old address to its relevant replacement.
If the move also involves a Joomla version change, prepare a separate update or upgrade rehearsal. Testing the hosting move and application upgrade as distinct changes makes failures easier to diagnose.
Take stock of the current site
Record your Joomla version, PHP version, database engine, templates and extensions. Note scheduled tasks, email settings, custom server rules and anything stored outside the normal document root.
Check your DNS records before changing them. The domain may also handle email, domain verification and other services. Moving the website does not mean you should replace every DNS record or change nameservers unnecessarily.
Confirm you can access the registrar, DNS provider, current host and new host. Save instructions and credentials securely, outside the site being moved.
Back up files and database together
Create a complete backup of the website files and database. Keep a copy outside the source server. Check the backup tool’s own documentation and ensure its restore process supports your destination environment.
For sites that accept orders, registrations, comments or other writes, plan when those changes will pause. A copy taken yesterday will not include today’s activity. The final copy needs to reflect the state you intend to make live.
Prepare and test the new server
Configure a compatible PHP and database environment, the domain’s virtual host, TLS and the appropriate clean URL rules. Restore the files and database, then update database credentials and environment-specific configuration paths where necessary.
Use a staging hostname or a local hosts-file override to inspect the destination before changing public DNS. Keep the test copy from sending customer emails or accepting real transactions. Discourage indexing and use access controls where appropriate; a robots instruction is not a privacy barrier.
Test the parts visitors actually use:
- The homepage, category pages and deeper article URLs.
- Administrator login, file uploads and media paths.
- Forms, password resets and outbound email.
- Search, multilingual routes and extension-specific features.
- Scheduled tasks and any external integrations.
- HTTPS, redirects and server error logs.
Plan the cutover
Choose a time that suits your audience and anyone supporting the move. Where appropriate, reduce the relevant DNS record’s TTL ahead of time and allow the previous TTL to expire. A lower TTL can help future DNS changes spread sooner, but it does not guarantee an instant switch for every visitor.
For a site with changing data, pause writes on the source, take the final files/database copy, restore it on the destination and verify it. Then update only the DNS records needed for the website. Keep the source available in a controlled state while caches expire so that you can investigate or roll back.
Be careful about a rollback after the new site starts accepting data. Simply pointing DNS back could lose new orders or accounts. A rollback plan must account for changes made on the destination as well as the server switch itself.
Preserve URLs and redirect specific changes
Keeping a working URL unchanged is often simpler than introducing a new address. When a page has genuinely moved or been consolidated, use a server-side permanent redirect to the most relevant replacement.
Avoid sending all missing URLs to the homepage. Google’s migration guidance warns that irrelevant bulk redirects can be treated as soft 404s. Where no equivalent page exists, a proper 404 or 410 may be more appropriate than an unrelated destination.
Update internal links to point directly at the final URLs, check canonicals and publish a sitemap that lists the current pages.
Check after launch
Monitor availability, forms, logs, backups and resource use. Check the site through public DNS from more than one connection. Make sure any temporary indexing blocks are removed from the production site and submit the sitemap through Google Search Console.
Keep the old environment until the cutover is stable and you have a fresh, tested backup of the new one. End the old hosting service only after checking its billing and data-retention process.
Further reading: Google’s guidance on site moves and URL changes and Joomla technical requirements.