Free tools Windows power users keep installed
One-click scans. No signup required.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
A Joomla migration has two separate payloads: the website files and the database that stores its content. Joomla’s documentation describes copying a site as “a two-part process: you must copy the files and you must copy the database (which is where the content is stored).” Move both, update configuration.php, test on the new VPS before changing DNS, and keep the old server available for rollback.
This runbook covers a conventional SSH/database migration and an archive-based restore, including compatibility checks, a low-downtime cutover, validation, and recovery when something fails.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Clear out junk files and repair common Windows errors3Fix the driver behind crashes, sound loss and screen glitches
What you need before moving Joomla
Prepare the destination before copying anything. A migration is safest when the new server can run the exact Joomla release, extensions, template, PHP version, and database engine used by the source site.
Record the source environment
- Joomla version and update level.
- PHP version and enabled modules.
- Database engine and version, database name, user, character set, collation, and Joomla table prefix.
- Installed extensions, templates, plugins, custom overrides, and their license or domain-activation requirements.
- Document roots, media and upload directories, symbolic links, administrator URL changes, scheduled tasks, and server-side cron jobs.
- SSL certificate method, mail transport and SMTP credentials, DNS records, redirects, URL-rewriting rules, webhooks, payment callbacks, and any external integrations.
- Current file ownership and permissions.
Save this inventory outside both servers. It becomes your comparison checklist after the restore.
#1 Best Overall
Check version compatibility
Match the PHP and database requirements for the precise Joomla release, not merely the latest versions offered by a VPS panel. An old Joomla release or extension may fail on a newer PHP runtime; changing hosts can expose deprecated functions, missing PHP modules, stricter SQL behavior, or incompatible database collations. Confirm compatibility for every critical extension and template before committing to the new VPS.
Create and test an off-site backup
Make a complete backup of files and the database, then store at least one copy away from both servers. Joomla’s security checklist says you should always be able to return to a previous working state through a strong, off-site backup and recovery process. A backup that has never been restored is only an assumption, so restore it to an isolated test location and verify that the site opens, an administrator can log in, and representative records and media are present.
Choose the migration method
| Method | Best fit | Advantages | Trade-offs and checks |
|---|---|---|---|
| Manual files plus database | Operators comfortable with SSH, SQL, and web-server configuration | Fine-grained control, easy to repeat individual steps, and direct visibility into logs and permissions | More separate operations; you must preserve every file, import the correct database, and verify paths yourself |
| Archive restore with Akeeba Backup | Sites where a tested package-and-restore workflow is preferable | A .jpa archive can contain folders, files, database data, and an installer, reducing separate transfer steps |
The archive still needs a compatible VPS, enough disk and extraction time, correct new database details, and a tested restore before DNS changes |
Use the method your team can validate and roll back confidently. Large archives can hit upload, extraction, memory, or execution-time limits; manual rsync and a streamed database dump can be more controllable on a large site.
Build and harden the new VPS
- Install the supported operating system and web stack. Configure the web server, the PHP version required by Joomla and its extensions, the required PHP modules, and the supported database engine and version.
- Create a dedicated database and least-privilege user. Grant only the permissions Joomla needs for normal operation and updates. Use a strong, unique password and record the database host, name, user, and port.
- Configure the virtual host. Point the document root at the future Joomla directory, enable the required rewrite behavior, and set the intended PHP handler. Do not expose a half-restored site publicly before access controls and HTTPS are ready.
- Set ownership and permissions. The web-server process must be able to read the site and write only the directories Joomla and its extensions require, including temporary and log locations. Avoid making the entire tree writable or using a blanket
777permission. - Prepare HTTPS and mail. Install the certificate for the final hostname or a controlled staging hostname, configure outbound SMTP or the selected mail transport, and plan how certificates will renew.
- Restrict staging access. Use a temporary hostname with authentication, an IP allow-list, or a hosts-file override. Prevent search indexing and do not let staging send real customer mail or payment callbacks.
Manual migration: files and database
1. Put the source in a consistent state
Inventory the site and decide how much write downtime you can accept. For a mostly static site, you can copy files while it remains live and perform a short final database synchronization. For active stores, membership sites, or publishing systems, enable Joomla maintenance mode or otherwise stop writes during the final dump so orders, comments, accounts, and edits cannot diverge between servers.
Rank #2
2. Copy the Joomla files
Copy the complete Joomla document root, including administrator, plugins, templates, media and upload directories, custom overrides, hidden files, and any linked directories. SSH tools are usually the most reliable for a VPS-to-VPS transfer:
rsync -aHAX --info=progress2 /path/to/source/ user@NEW_VPS:/var/www/example/Run a second synchronization after the site is quiet. If SSH is unavailable, use SFTP or FTP in a client that preserves binary files and hidden files, or restore an archive. Review transfer output for permission errors, skipped files, broken symbolic links, and insufficient disk space. Do not delete the destination during the first pass; keeping the original copy makes comparison and recovery easier.
3. Export and import the database
Create a consistent SQL export from the source database. With MySQL-compatible tools, a typical export is:
mysqldump --single-transaction --routines --triggers --default-character-set=utf8mb4 DB_NAME > joomla.sqlUse a brief write freeze if the database engine or workload makes a transaction-consistent export impossible. Transfer the dump through a protected channel, create an empty destination database with the required character set and collation, and import it:
Rank #3
- Keep track of everything from attendance to test scores
- Spiral bound
- Measures 8-1/2" x 11"
mysql -u DEST_USER -p -h DEST_HOST DEST_DB < joomla.sqlFor phpMyAdmin, export the complete source database rather than selected content tables, then import the resulting file into the empty destination database. Check that the Joomla table prefix is unchanged and that the import completed without truncated statements, collation errors, or packet-size failures. Compare row counts in representative content, user, session, menu, and extension tables, and verify that recently uploaded media exists in the file copy.
Update configuration.php safely
Joomla’s root configuration.php contains the values that connect the application to its environment. Edit a copy on the destination and keep the original source file unchanged until cutover.
At minimum, verify the destination values for:
$host: database host name or address.$user: destination database user.$password: destination database password.$db: destination database name.$dbprefix: the imported Joomla table prefix.$log_path: an absolute, writable path for Joomla logs.$tmp_path: an absolute, writable path for temporary files and extension installation.
Change any destination-specific filesystem paths used by your installation. Keep $live_site and $cookie_domain empty unless this deployment specifically requires them; stale values can force the wrong hostname or prevent sessions from working on the staging address. Preserve the file’s PHP syntax, quoting, and permissions. A front end that loads does not prove the temporary and log paths are correct—test an extension update or another operation that uses them.
Archive workflow with Akeeba Backup
- Create a complete backup archive on the source and confirm that the archive contains the Joomla files and database data. Akeeba’s Joomla workflow uses a
.jpaarchive and an installer. - Download the archive and installer, then upload them to an empty directory on the new VPS. Confirm free disk space for both the compressed archive and extracted site.
- Open the installer through the protected staging hostname. Enter the new database host, database name, user, password, and table-prefix settings when prompted.
- Complete extraction and database restoration, then remove or protect installer artifacts as the tool requires.
- Review the generated configuration, set the correct log and temporary paths, and test the restored site before DNS changes.
An archive reduces the number of separate transfer operations, but it does not bypass compatibility checks, permission setup, database limits, or testing. Restore the same archive to an isolated location first so a damaged package or incompatible PHP version is discovered without affecting production.
Rank #4
- Used Book in Good Condition
Stage and test before DNS
Do not use DNS as your first test. Point a temporary hostname at the VPS, or override the hostname in your own computer’s hosts file while the public DNS record still points to the old server. Keep staging private and disable indexing.
Application checks
- Open the home page, several article and category pages, search, contact forms, and any multilingual routes.
- Log in to
/administrator; create a test article, edit it, save it, and remove it. - Open the media manager and upload, view, and delete a test asset.
- Exercise extension-specific workflows: shopping cart or membership actions, scheduled imports, maps, comments, and custom administrator screens.
- Send a test message through the configured mail transport and confirm headers, delivery, and reply addresses.
- Run scheduled jobs and server-side cron tasks manually once, then confirm their next scheduled run.
Web-server and security checks
- Test URL rewriting, canonical redirects, trailing-slash behavior, custom error pages, and every important redirect.
- Confirm HTTPS, certificate coverage, HTTP-to-HTTPS redirection, secure cookies, and mixed-content warnings.
- Inspect PHP, web-server, Joomla, and database logs while exercising the site. Resolve warnings, fatal errors, permission failures, and database connection errors rather than accepting a page that merely appears to load.
- Verify file ownership, writable directories, backup locations, firewall rules, SSH keys, automatic updates, and server monitoring.
- Check extension licenses or domain activation rules; some vendors require a reactivation after the hostname or server changes.
Data comparison
Compare representative records on the old and new sites: recent articles, users, menu items, orders or form submissions, configuration values, and the newest media files. If the source kept receiving writes during the initial copy, repeat the file synchronization and database export after testing and before cutover.
Cut over with minimal downtime
- Lower DNS TTL ahead of time. Do this early enough for existing resolver caches to expire. Lower TTL does not force every resolver to switch immediately, so retain the old server.
- Announce or schedule a brief write freeze. Enable maintenance mode or stop write-producing jobs. Record the time so you can identify transactions made after the final backup.
- Take the final database backup. Export the source database after writes stop, import it into the destination, and perform the final file synchronization for uploads and generated assets.
- Recheck configuration. Confirm database credentials, paths, hostname behavior, mail, HTTPS, and any environment variables on the production virtual host.
- Change DNS. Point the required A, AAAA, CNAME, MX, and verification records to the new VPS as appropriate. Do not change mail records unless mail is moving too.
- Monitor propagation and health. Watch access, PHP, Joomla, and database logs; test from more than one network; and monitor uptime, forms, scheduled jobs, and webhooks.
- Keep rollback available. Leave the old server intact and read-only until the new site has remained stable through the period that matters for your traffic and scheduled jobs.
Visitors who still resolve the old address must not be allowed to create conflicting data. During propagation, keep the old site in maintenance mode or route it to a clear migration notice once the new site is serving production traffic.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Rollback and common failure modes
Database connection errors
Recheck the host, port, database name, user, password, firewall allowance, and whether the database user is permitted to connect from the web server. Confirm that the imported database exists and that $dbprefix matches its tables.
Best Value
- Book - 1, 000 books to read before you die: a life-changing list (1000 before you die)
- Language: english
- Binding: hardcover
Blank page or HTTP 500 error
Read the PHP and web-server error logs first. An incompatible PHP version, missing extension, broken template override, or syntax error in configuration.php is more useful to diagnose than repeatedly refreshing the page. Temporarily switch to a known-compatible template or disable the offending extension from the administrator or database only when you understand the consequence.
Recommended Free Tools
Extensions cannot install or update
Check $tmp_path and $log_path, directory ownership, free disk space, PHP upload and execution limits, and outbound network access. Incorrect paths can leave the front end working while extension installation fails.
Images, downloads, or media are missing
Compare the source and destination media directories, including case-sensitive names, hidden files, and symbolic links. Re-run rsync and inspect its skipped-file and permission output.
Login loops or lost sessions
Remove stale domain or path assumptions from $cookie_domain, verify HTTPS and proxy settings, and clear old browser cookies. Test the administrator using the final hostname, not only the temporary staging address.
URLs return 404 errors
Confirm the virtual host document root, rewrite support, .htaccess handling, and Joomla SEO settings. Test both the home page and a deep link before opening the site publicly.
Mail or webhooks fail after DNS changes
Verify SMTP credentials, SPF/DKIM-related records when applicable, callback URLs, firewall rules, TLS certificates, and any provider allow-list that references the old server IP. Trigger a controlled test rather than waiting for a customer transaction to reveal the problem.
If a material defect persists, restore the last known-good backup, put the destination in maintenance mode, revert DNS to the old server, and keep the old site read-only until the cause is fixed. Do not resume writes on both servers.
Quick Recap
Post-migration cleanup
- Take a fresh, restorable backup from the new VPS and store an off-site copy.
- Confirm monitoring, alerting, renewal jobs, cron schedules, and backup retention.
- Remove temporary staging credentials, installer files, test users, and hosts-file entries.
- Review SSH keys, database users, firewall rules, and writable directories.
- Document the final Joomla, PHP, database, web-server, DNS, and extension versions.
- Keep the old server available until rollback is no longer needed; then securely remove credentials and data according to your retention policy.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
