Moving Joomla to a New Server? Keep Your Site Working

Your Joomla website works, but the hosting bill has risen or support has become unreliable. You want to move it to another server while keeping the same pages, domain and editing system. That is a hosting migration, with a smaller scope than replacing the CMS.

The difficult part is keeping two copies consistent while you test and switch traffic. Copying yesterday's site can lose today's enquiries or orders. This guide gives an owner a practical handover checklist, including what to ask a technician to prove. If you are replacing Joomla itself, use our separate plan for leaving Joomla.

1. Separate the host move from a software upgrade

Record your installed Joomla release, PHP version, database engine, template and essential extensions. Ask the destination host to check that exact combination. As of 2026, Joomla's technical requirements distinguish supported and recommended software versions; requirements for the newest release do not prove an older installation will run there.

Changing servers will not fix an abandoned extension or make unsupported software supported. A destination with a different PHP version can expose problems that were hidden on the old host. If an upgrade is necessary, agree its sequence and rehearse it separately before combining the work into one launch.

Keeping Joomla avoids unnecessary content conversion and retraining when its workflow still fits. The case against a simple move is that it preserves existing limitations. If the reason for moving is slowness, use our slow-site triage guide to check whether hosting is actually the cause.

For a small brochure site, allow typically 3-8 hours of technical work across 2-5 days and typically CAD 300-1,200, excluding hosting. These are editorial planning ranges, not supplier quotes or a DNS deadline. Shops, memberships, large databases and unsupported extensions need separate estimates.

2. Choose a transfer method and keep a recoverable source

Joomla's backup documentation identifies two essential parts: the site files and its database. Files include software, templates, images and configuration; the database contains structured content and settings. A file-manager download alone does not preserve the whole site.

A host-managed move reduces your workload, but its scope may exclude mailboxes or a second data transfer. Akeeba packages the site conveniently, but archive size, compatibility and available storage still matter. Manual transfer gives more control, but makes it easier to miss hidden files or pair the wrong database with the files.

Keep a dated copy outside the public website and retain owner-controlled access to the old host. Backup archives can contain credentials and personal data. Do not put a database export at a guessable public URL. Our restore-test guide explains why a downloaded archive is only the start of recovery planning.

3. Restore and test before sending visitors there

Use an isolated destination with a separate database. Confirm its folder and database names before importing anything. The Akeeba restoration guidance says a full-site archive already includes the restoration script and Joomla installation; you do not need to install Joomla first. It also warns that restoration overwrites matching files and tables without deleting unrelated leftovers.

For an Akeeba move, download all parts of a multipart archive and follow the matching restoration instructions. For a manual move, copy the complete file tree, including relevant hidden files, import the matching database, then update Joomla's database connection details and server-specific log and temporary paths. Preserve the source database's table prefix.

Have the technician test the destination using the real hostname with a local address override, or a protected preview environment. Testing only the server IP can exercise the wrong virtual host. Check HTTPS for the production hostname before launch. Protect previews from public indexing and disable outgoing customer email, payment actions and scheduled jobs on the copy.

Test the homepage, several nested pages, images, downloads, administrator login, search, forms and essential extensions. A working homepage does not prove URL rewriting works. If internal pages return 404, check the destination web-server rewrite configuration and whether the old hidden configuration files were transferred. Apache rules do not automatically configure Nginx.

4. Freeze changes, then switch the website records

A rehearsal uses a snapshot. Anything written afterwards remains on the old server unless you transfer it again. List what can change: articles, uploads, form records, registered users, orders and scheduled tasks. Decide who stops those writes and who confirms the final transfer.

1. Record a cutover time and the person authorised to proceed or roll back.
2. Pause editing and relevant transactions, or use a tested synchronisation method for the changing records. An offline notice alone may not stop integrations or background jobs.
3. Take the final matching files-and-database backup, restore it on the destination, and repeat the essential checks.
4. Change the required website address records at the existing DNS provider. Check both IPv4 and IPv6 records, plus the www hostname if used.
5. Confirm public traffic reaches the destination before reopening writes. Keep the old copy from accepting independent new orders or edits.

Avoid changing nameservers unless moving DNS is part of the agreed scope. Our website-move email checklist covers MX records, sender authentication and shared mail hostnames. Preserving MX records alone is insufficient if a mail server depends on an address you also changed.

As of 2026, Google's hosting-move guidance recommends preparing and testing the destination, considering DNS TTL in advance, then monitoring both servers. Reducing TTL at cutover does not erase answers already cached under the earlier value.

5. Diagnose the failures a file copy can hide

If Joomla reports a database connection error, compare the configured server, database name, username and permissions with the destination account. Do not assume the database host is always localhost. A blank page or server error needs the destination PHP error log and a compatibility check, rather than repeated DNS edits.

If pages load but saving or uploads fail, check writable destinations, ownership, available storage and the log and temporary paths. Avoid making the entire installation writable as a shortcut. If forms claim success but no message arrives, test receiving and sending separately; the new server may need different authenticated mail settings.

Do not fix redirect loops by randomly changing Joomla, proxy and HTTPS settings together. Compare each layer with the known working source, change one cause at a time and retest. Pause launch if a required customer journey fails. Our website triage tool can help an owner organise symptoms before handing them to the maintainer.

6. Close the move with a rollback decision

Keep the same public URLs when this is only a server move. A host change alone does not call for a new redirect map or Search Console Change of Address request. If you also change domains or paths, use the separate URL-change checklist and budget for that additional scope.

Monitor errors, form delivery and traffic on both hosts. Google's guidance recommends retiring the old infrastructure once traffic has moved and users, including Googlebot, receive content correctly from the destination. Do not cancel the old account just because your own laptop sees the new site.

Agree rollback triggers, such as a broken checkout or unavailable administrator, before launch. Reverting DNS cannot instantly reverse cached answers. Once the destination accepts new records, restoring the old copy without reconciling them can lose data. For a changing site, pause writes and account for those records before reverting.

Finally, remove restoration scripts and backup archives from public folders, restore scheduled jobs deliberately, and verify the new backup process. Close the handover when access, recovery and customer journeys work on the new server. The guides hub covers the separate maintenance work that continues afterwards.

— Editorial team. Facts current as of 2026; we revise guides when the ground shifts.