How to Move a Drupal Site’s Files and Database to a New Server

A Drupal migration is complete only when the destination has the codebase, database, public uploads, private files, configuration and secrets, and the same compatible PHP and database stack. Rebuild the destination from the repository, import a verified database dump, copy every files directory, update settings.php, test on a temporary hostname, and change DNS only after the new server passes functional checks. Keep the old server and an untouched backup available until the cutover is proven.

Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.

What a Drupal server move actually includes

Drupal is not just the web directory. A working copy combines several parts that can live in different locations:

#	Preview	Product	Price
1		Drupal 6 Content Administration	$45.99	Buy on Amazon
2		Drupal For Dummies	$12.37	Buy on Amazon
3		Teacher Record Book	$4.89	Buy on Amazon
4		Drupal 7 Multi Sites Configuration	$24.99	Buy on Amazon
5		Drupal 5 Views Recipes	$57.99	Buy on Amazon

As an Amazon Associate I earn from qualifying purchases.

Leave nothing essential only on the old host. A migration that moves the database but omits private files, or copies files without the matching code and configuration, is an incomplete migration.

Choose a transfer method before scheduling downtime

The right procedure depends on access, site age, size and how much write downtime you can accept.

#1 Best Overall

Drupal 6 Content Administration

• Used Book in Good Condition

$45.99

Buy on Amazon

Prepare the source and destination

1. Inventory versions, paths and integrations

Write down the Drupal core and Drush versions, PHP version, database engine and version, document root, public-files path, private-files path, Composer files, cron definitions, queue workers, mail service, payment or webhook integrations and DNS records. Drupal’s migration guidance specifically recommends documenting the PHP and database versions used by the site so compatibility can be checked during restoration.

Record the current domain and any environment-specific URLs. If the domain will change, list canonical URLs, redirect rules, cookie settings, webhook endpoints and external services that must be updated. Lower the DNS TTL before the maintenance window so resolvers can adopt the new address sooner; the old TTL may remain cached for its previous duration.

2. Decide how to freeze writes

For a small site, schedule maintenance and prevent logins, submissions and commerce activity while the final dump is taken. For a busy site, stage the destination first, then put the old site into maintenance or read-only mode for the final database export. Keep the source database untouched until the destination has passed testing. If anyone can write to the old site after the final dump, plan to repeat the export and import.

3. Provision a compatible destination

• Create an empty database and a dedicated database user with the required password, host and port.
• Install PHP, the database engine and all required PHP extensions at versions compatible with the source.
• Set the web-server document root to Drupal’s intended public directory, not to a private project directory.
• Create writable public-files and temporary directories, and a private-files directory outside the web root.
• Recreate cron, queue workers, mail delivery, HTTPS certificates, redirects and any container-volume or SELinux/AppArmor permissions.

Do not point DNS at the destination yet. A temporary hostname or a hosts-file override lets you test the new server while visitors continue using the old one.

Back up the old site completely

Export the database

From the source project, use the installed Drush version’s SQL export command, drush sql:dump, or the database engine’s native tool such as mysqldump. Preserve the resulting SQL file exactly; do not edit it in a text editor. Note the database engine, character set and version used to create it.

For a source that uses PostgreSQL, restore with the matching PostgreSQL client rather than a MySQL command. A dump made by one engine cannot be imported into the other without a deliberate conversion.

Rank #2

Sale

Drupal For Dummies

$12.37

Buy on Amazon

Archive code and Composer metadata

Save the repository commit, composer.json and composer.lock, custom modules and themes, and any patches or deployment scripts. Composer-managed sites should be rebuilt from this source and dependencies installed with composer install; copying only the web directory can omit vendor packages and produce code that does not match the database.

Copy public, private and ignored files

Copy sites/default/files or the site-specific files directory, all private files, and any additional asset directories used by custom code. Include ignored files that are not in version control, especially settings.php, environment include files and certificates or other secrets required at runtime.

Protect the backups

• Store SQL dumps and archives outside the Drupal document root.
• Restrict ownership and permissions so the web process cannot serve or modify the backups.
• Encrypt backups when they contain personal data or credentials.
• Keep an untouched copy away from the old server, and record transfer checksums so you can verify that files were not altered.

Drupal’s user guide warns: “For security reasons, avoid storing this file on your hosting server anywhere under the Drupal site root.” That warning applies particularly to database dumps, which can expose every table if downloaded.

Transfer the code and files

Composer-managed projects

1. Clone or check out the exact repository commit on the destination.
2. Copy the matching composer.json and composer.lock.
3. Run composer install in the project root using the destination’s production options.
4. Restore custom code and any deployment-specific files that are intentionally outside the repository.

Installing dependencies after the code is in place ensures that Drupal core, contributed packages and their autoload files correspond to the lock file used by the source.

Synchronize files over SSH

For a remote source, Drush aliases can use drush rsync to synchronize site files. A standard SSH/rsync workflow is preferable to downloading thousands of files through a browser because it can resume and preserve timestamps and permissions. Confirm the source and destination paths before starting; a reversed path can overwrite the only good copy.

Transfer public files, private files and any custom asset directories separately when they have different access rules. Verify that the private directory is not beneath the document root and that the web server cannot serve it directly.

Rank #3

Teacher Record Book

• Keep track of everything from attendance to test scores
• Spiral bound
• Measures 8-1/2" x 11"

$4.89

Buy on Amazon

Archive-based workflows

Drush archive commands are version-specific. Drush 14 documents archive:dump; older documentation describes archive:restore, while the current Composer guidance warns that archive restore was removed in Drush 13. Check drush --version and the installed command list before relying on an archive workflow. Do not assume an archive created by one Drush generation can be restored by another without checking its documentation.

Update settings.php safely

Make a destination-specific copy of the settings file and keep the source copy unchanged until cutover. Update the database connection in $databases with the new database name, host, username, password and port. Then check every environment-dependent setting:

• hash_salt: retain the site’s intended value; do not replace it casually during a move.
• Trusted hosts: add the temporary hostname used for testing and the final domain, using patterns appropriate to the site.
• Public and private paths: point Drupal at the restored directories and confirm that the private path is outside the web root.
• Service overrides: carry over required services.yml, reverse-proxy, cache and environment include settings.
• Secrets: keep database credentials and API keys out of a public repository and out of downloadable backups.

Do not solve a domain change with blind SQL replacement. Drupal stores serialized and structured data; use a Drupal-aware search-and-replace procedure for environment-specific URLs so serialized values remain valid.

Import the database on the new server

1. Confirm that the destination database is empty and that the selected database engine and version are compatible with the dump.
2. Import through SSH or host-native tooling. Drush supports drush sql:cli < backup.sql and the shorter drush sqlc < backup.sql form when the site’s settings point to the destination database.
3. Alternatively, use the native mysql or psql client with the destination credentials.
4. Watch the client output for errors, then verify that expected Drupal tables and representative content exist.

For a large dump, avoid a browser upload. SSH and provider-native import tools remove browser request limits and generally provide clearer error output. If an import fails, preserve the failed log, correct the database or connection problem, recreate an empty database and restart from the untouched SQL file rather than editing the dump.

Rebuild caches and correct permissions

Once the database, code and files are present, run the version-appropriate cache rebuild command, normally drush cr. Ensure that the web-server user can write the public-files, private-files and temporary directories while backup files remain unreadable to the web process. On systems using containers, verify volume ownership inside the running container, not only on the host. Check SELinux or AppArmor rules if Drupal reports permission errors even though Unix mode bits look correct.

Load the temporary hostname and inspect the web-server and Drupal logs immediately. A missing vendor directory, wrong document root, stale cache or incorrect database credentials usually appears before deeper functional tests.

Rank #4

Drupal 7 Multi Sites Configuration

$24.99

Buy on Amazon

Test the new copy before DNS

Use a hosts-file entry or temporary hostname that resolves to the destination. Test as both an anonymous visitor and an administrator.

• Open the home page, representative content types, taxonomy pages, search results and pagination.
• Log in, visit administrative pages, edit content and submit every important public form.
• Open original images and image styles, upload a new file and download an existing file.
• Request a private file as an authorized user, then confirm that an anonymous request is denied and that no private path is publicly browsable.
• Run cron and queue workers, and confirm that scheduled jobs complete without permission or PHP errors.
• Send test mail and verify the configured delivery service, sender domain and links.
• Exercise payment, webhook, API and other external integrations in their supported test mode before enabling production traffic.
• Check HTTPS certificates, HTTP-to-HTTPS redirects, canonical URLs, robots directives and any reverse-proxy headers.
• Compare representative node, user, taxonomy and file counts with the source. Investigate differences instead of assuming they are harmless.

Keep a written result for each check and save relevant log excerpts. This checklist is the point at which a missing directory, stale configuration value or incompatible extension is cheapest to fix.

Cut over DNS and keep a rollback path

1. Place the old site in maintenance or read-only mode and stop writes.
2. Take the final database dump and transfer any files created since staging began.
3. Import the final dump, rebuild caches and repeat the highest-risk functional checks.
4. Point the DNS records to the destination. DNS changes are required for a live host move; existing resolvers may continue using the old address until their cached TTL expires.
5. Monitor destination access logs, PHP and Drupal logs, queue status, mail, webhooks and error rates.
6. Keep the old server powered on and retain the verified backup, exact SQL dump, code commit, Composer lock file, settings backup and transfer checksums until traffic and tests remain clean.

If new writes occurred after the final dump, do not attempt to reconcile them by guessing. Put the old site back into maintenance, create another final dump, import it into the destination and repeat the cutover check.

Common failure modes and fixes

The site shows a database connection error

Recheck the database name, host, port, username and password in settings.php. Confirm that the destination user has access from the web server’s network address and that the database engine is running. An imported database does not help if Drupal is still reading the old connection settings.

Images or downloads return 404

Confirm that the correct site-specific files directory was copied, that its path in settings.php is correct and that the web server can read it. Rebuild caches and image styles after correcting ownership. A code-only deployment will not recreate uploaded files.

Private files are exposed or inaccessible

Move the private directory outside the document root, set the configured private path, and test both an authorized and an anonymous request. Review web-server aliases and container mounts; a permissive alias can bypass Drupal’s access checks.

Best Value

Drupal 5 Views Recipes

• Used Book in Good Condition

$57.99

Buy on Amazon

Trusted-host or redirect errors appear

Add the temporary and final hostnames to the trusted-host configuration, then review reverse-proxy and HTTPS settings. Remove temporary test hosts before production if they are not needed.

Admin pages fail after a Composer deployment

Verify that composer install completed successfully from the intended lock file and that the document root points to the directory containing the installed Drupal front controller. Running code from a different commit than the database can produce missing services, schema mismatches or fatal errors.

Scheduled work or mail stopped

Recreate cron and queue schedules on the new host, check their execution user and environment, and confirm outbound network and mail permissions. A browser test cannot prove that a command-line scheduler is running.

The domain changed and links or data broke

Find environment-specific URLs in configuration and content using Drupal-aware tooling. Avoid raw SQL replacement where serialized data may be present. Update canonical settings, redirects, webhook endpoints and third-party allowlists together.

Options when you do not have shell access

The Backup and Migrate module can provide database and files backup/restore workflows, with Drush integration where Drush is available. It is useful for administrators limited to a control panel, but it does not remove the need to verify PHP/database compatibility, private-file placement, permissions, settings, DNS and rollback. A hosting provider or professional migration service may be appropriate when you cannot safely access SSH, database tools or DNS.

Quick Recap

Bestseller No. 1

Drupal 6 Content Administration

Used Book in Good Condition

$45.99

SaleBestseller No. 2

Drupal For Dummies

$12.37

Bestseller No. 3

Teacher Record Book

Keep track of everything from attendance to test scores; Spiral bound; Measures 8-1/2" x 11"

$4.89

Bestseller No. 4

Drupal 7 Multi Sites Configuration

$24.99

Bestseller No. 5

Drupal 5 Views Recipes

Used Book in Good Condition

$57.99

Final migration checklist

• Drupal, Drush, PHP and database versions recorded and compatible.
• Repository commit, composer.json and composer.lock preserved.
• Database dump completed, imported successfully and stored outside the web root.
• Public files, private files and ignored configuration files copied and checksum-verified.
• settings.php updated for database credentials, hash_salt, trusted hosts and file paths.
• Destination document root, PHP extensions, cron, queues, mail and permissions verified.
• Cache rebuild completed with drush cr.
• Anonymous, authenticated, administrative, upload, private-file, search, HTTPS and integration tests passed on a temporary hostname.
• Final write freeze, dump and file synchronization completed before DNS change.
• Old server, exact backups and rollback materials retained until production monitoring is clean.

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.