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.
Move a Drupal site as a coordinated set: the Composer-managed codebase, public and private files, configuration and secrets, and a consistent database export. Build a compatible stack on the new server, restore those components, point settings.php to the new environment, test through a temporary hostname, and change DNS only after the copy works. Keep the old server and verified backups available until the new site has operated cleanly.
What a Drupal server move actually includes
A Drupal installation is more than the directory served by the web server. A complete migration contains five related parts:
| # | 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 |
- Code: Drupal core, contributed and custom modules, themes, libraries, and the Composer files that define the build.
- Database: content, configuration, users, sessions, queues, and other state stored by Drupal and its modules.
- Public files: usually
sites/default/files, or the equivalent site-specific files directory. - Private files: documents configured outside the public web root and protected by Drupal and the web server.
- Environment configuration:
settings.php, its included files, the hash salt, database credentials, trusted hosts, filesystem paths, cron jobs, mail settings, and integrations.
Leaving out any one of these can produce a site that appears to load while images, logins, uploads, private documents, or administrative operations fail. PHP and database versions must be recorded and matched for a compatible restoration; Drupal documentation specifically recommends documenting both versions before the move.
Choose a migration window and inventory the source
Record versions and locations
Before copying anything, write down the Drupal core version, Drush version, PHP version, database engine and version, web-server software, document root, public-files directory, private-files directory, and any additional asset directories. Record the repository commit, composer.json, and composer.lock as well. The destination should be able to reproduce this exact software combination before you import production data.
#1 Best Overall
- Used Book in Good Condition
List operational dependencies
Inventory scheduled jobs and services that are easy to overlook:
- Drupal cron and any system cron entries or queue workers.
- Mail delivery configuration, SMTP credentials, and sender domains.
- Payment, webhook, search, analytics, CDN, object-storage, and other integrations.
- SSL certificates, reverse-proxy rules, redirects, and web-server rewrite settings.
- DNS records and the current DNS time-to-live (TTL).
Lower the DNS TTL before the cutover if your DNS provider permits it. A shorter TTL reduces how long resolvers may continue using the old address after you change the record, but it does not stop already-open connections or guarantee instant worldwide propagation.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Freeze writes at the right moment
You can copy most files and prepare the new server while the old site remains online. The database dump must represent a known point in time, however. Schedule a maintenance window, enable read-only or maintenance mode where practical, or otherwise prevent content and account changes during the final export. If writes occur after the dump, those changes will not exist in the imported database and must be handled with a new dump and import.
Back up the database, code, files, and secrets
Export the database
With Drush available, create a SQL dump with drush sql:dump and write it to a protected location outside the web root. Use the native database utility when Drush is unavailable: mysqldump for MySQL-compatible databases or the PostgreSQL dump tools for PostgreSQL. Preserve the exact resulting SQL file; it is the rollback source and the record of what was imported.
Do not assume a database export contains uploaded files. It normally does not. Files and the database are separate migration artifacts.
Preserve the reproducible codebase
For a Composer-managed site, back up or commit the repository files, including composer.json and composer.lock, and note the precise commit used for the running site. The destination should be rebuilt from that repository and dependency lock file rather than relying on an incomplete copy of the web directory. Include custom modules, themes, patches, and libraries that are part of the deployment.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Copy public and private files
Archive or synchronize the complete public-files directory, normally sites/default/files, including generated image styles and any files in site-specific directories. Copy the private-files directory separately and retain its intended location and access restrictions. Also identify asset directories outside the normal Drupal paths; a custom module or theme may depend on them.
Save ignored configuration and credentials safely
Files ignored by version control are often essential to a rebuild. Keep a protected copy of settings.php, any included settings files, environment files, certificate material, and integration secrets. Never commit database passwords or other credentials to a public repository. Preserve the existing hash salt securely so the destination uses the same site identity unless you have deliberately planned a security rotation.
Rank #2
Protect the backups before transferring them
Store SQL dumps and archives outside the old site’s document root, restrict ownership and permissions so the web process cannot serve them, and encrypt them when they leave a trusted system. Drupal’s user guide gives the specific warning: “For security reasons, avoid storing this file on your hosting server anywhere under the Drupal site root.” Keep an untouched copy off the old server as well as the transfer copy.
Generate and record checksums for the SQL dump, code archive, and file archive before transfer, then calculate them again on the destination. A matching checksum verifies that the bytes arrived unchanged; it does not prove that permissions, database credentials, or application configuration are correct.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Select a workflow that fits access, size, and downtime
| Situation | Practical method | Trade-off |
|---|---|---|
| SSH and Drush available | Use drush sql:dump, SSH transfer, and Drush aliases with drush rsync for remote file synchronization. |
Fast and scriptable, but requires shell access and correctly configured aliases. |
| SSH and native database access available | Transfer archives with SSH or rsync; import through mysql or psql. |
Well suited to large dumps because it avoids browser upload limits. |
| Control panel only | Use the panel’s database export/import and file archive tools, or the Backup and Migrate module where it is supported. | Accessible without a shell, but large archives may hit upload, timeout, or permission limits. |
| Composer-managed Drupal | Clone the repository, run composer install, then restore files and the database. |
Reproducible and preferred for current Drupal; copying only the document root is incomplete. |
| Legacy or Drupal 7 site | Copy the code and files, import SQL, edit settings.php, and adjust the host configuration carefully. |
The sequence remains useful, but older commands and security assumptions must not be applied blindly to Drupal 8–11. |
| Very little downtime tolerated | Stage the destination in advance, then take a final write-blocked dump and perform a short final import before DNS change. | Reduces the outage window but requires disciplined coordination and a second transfer. |
Archive commands are version-sensitive. Drush 14 documents archive:dump; older Drush documentation describes archive:restore, while the current Composer guidance warns that archive restore was removed in Drush 13. Check drush --version and the command list installed on your site before building an archive-based procedure.
Provision the new server before restoring production data
Build a compatible software stack
Create an empty database and a dedicated database user. Install a PHP version and database engine/version compatible with the source Drupal release and its modules. Enable the PHP extensions required by the site and match web-server behavior such as URL rewriting, PHP-FPM settings, request limits, and TLS termination.
Recreate the filesystem layout
Set the new document root to the Drupal web directory used by the project. Create the public-files and private-files directories at known paths, and ensure the private path is outside the document root when possible. Recreate any additional asset directories and mount points used by custom code or containers.
Install the application code
Clone or copy the repository at the recorded commit and run composer install. Do not run an unconstrained dependency update during a migration; changing dependency versions at the same time makes failures harder to isolate. Confirm that the resulting code tree contains the expected Drupal core, modules, themes, and libraries before importing the database.
Prepare jobs and services without enabling traffic
Recreate cron definitions, queue workers, mail transport, certificates, and integration credentials. Keep public DNS pointed at the old server while you validate the destination. If a job could send mail, charge a payment, or call a webhook, disable or isolate it until testing is complete.
Transfer code and files without losing permissions
Restore the code archive or repository first, then transfer the public and private files. Drush aliases can use drush rsync to synchronize remote files; SSH-based rsync is another suitable option for large trees. Preserve timestamps where useful, but prioritize correct ownership and mode bits for the destination’s web and deployment users.
Rank #3
- Keep track of everything from attendance to test scores
- Spiral bound
- Measures 8-1/2" x 11"
After transfer, compare checksums or file counts for representative directories. Pay particular attention to files with spaces or non-ASCII names, deeply nested private documents, and generated image-style derivatives. A successful archive extraction does not guarantee that the web process can read public files or that Drupal can write new uploads.
Update settings.php for the destination
Change database connection values
Edit the destination copy of settings.php or its environment-specific include so the $databases entry contains the new database name, host, user, password, port, and driver. A MySQL-style example is:
$databases['default']['default'] = [
'database' => 'drupal_new',
'username' => 'drupal_user',
'password' => getenv('DRUPAL_DB_PASSWORD'),
'host' => '127.0.0.1',
'port' => '3306',
'driver' => 'mysql',
'prefix' => '',
];Use the driver and port required by the actual database engine. Keep credentials in protected environment configuration or a file that is not publicly readable; do not paste a production password into a repository.
Preserve security and host settings
Carry over the site’s $settings['hash_salt'] securely, then set trusted host patterns for every legitimate hostname, including the final canonical host and any deliberately supported alternate host. For example:
$settings['trusted_host_patterns'] = [
'^example.com$',
'^www.example.com$',
];Use your real hostnames in place of the example patterns. An incorrect pattern can produce “The website encountered an unexpected error” or a trusted-host violation even when the database connection is correct.
Point Drupal at the private-files path
Set the private path to the directory restored on the new server, for example:
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minute$settings['file_private_path'] = '/srv/drupal-private';Verify that this directory is not reachable through a normal web URL and that Drupal’s web user can read it when serving an authorized download. Also review environment-specific settings for reverse proxies, file schemes, temporary directories, and domain-dependent configuration.
Import the database safely
Create the destination database with the correct character set and permissions before importing. Do not import into a database that contains an unrelated Drupal installation unless you have explicitly emptied it and verified the target name.
Use Drush when it is available
From the Drupal project directory, import a SQL dump with drush sql:cli < backup.sql. The shorter alias drush sqlc < backup.sql performs the same kind of import. Confirm that Drush is reading the destination settings.php before running the command.
Use the native client for large dumps
For MySQL-compatible databases, use the host’s mysql client; for PostgreSQL, use psql. Run the import over SSH or through host-native tooling rather than uploading a large SQL file through a browser. Browser-based tools commonly impose file-size, execution-time, or memory limits that are unrelated to Drupal.
Recommended Free Tools
Validate the import before opening the site
Check that the command completed without SQL errors, that the expected Drupal tables exist, and that row counts for representative content tables are comparable with the source. If the import stops partway through, discard the partial database, correct the reported issue, and import the untouched dump again instead of trying to guess which statements ran.
Rebuild caches and correct ownership
After the database and files are in place, run the cache-rebuild command appropriate to the installed Drush version: drush cr. Confirm that the web process can read the code and public files and can write only where Drupal requires it, such as the public-files, temporary, and private-files directories.
On systems using SELinux, AppArmor, containers, or volume mounts, check the security labels and mount permissions in addition to ordinary Unix ownership. A directory may show apparently correct mode bits while the mandatory access-control policy still blocks PHP or the web server. Review PHP and web-server error logs immediately after the rebuild.
Test the new copy before changing DNS
Use a temporary hostname, an internal name, or a hosts-file override that resolves the production hostname to the new server from your test workstation. Do not rely on the server’s IP address alone: Drupal may generate absolute URLs, apply trusted-host rules, or behave differently when the expected hostname is present.
Free tools Windows power users keep installed
One-click scans. No signup required.
Run an anonymous visitor test
- Open the home page, several representative content pages, taxonomy pages, and search results.
- Check CSS, JavaScript, responsive behavior, image styles, and downloads.
- Follow canonical URLs, redirects, and HTTPS links; confirm that no page unexpectedly points back to the old host.
Run an authenticated and administrative test
- Log in with a test account and an administrator account.
- Open administrative pages, edit content, submit forms, and create a controlled upload.
- Verify that public files display and private files are available only through authorized Drupal responses, never by guessing a public URL.
Exercise background operations
- Run cron and inspect queue processing.
- Send a controlled test email and verify the configured sender and delivery path.
- Exercise payment, webhook, search, and other external integrations in their documented test or safe mode.
- Review PHP, web-server, database, and Drupal logs for permission errors, missing extensions, broken rewrites, and failed outbound connections.
Compare representative content and database counts with the source. The goal is not merely a successful front page; it is evidence that the restored state, filesystem permissions, scheduled work, and integrations behave as one system.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Cut over DNS and monitor the result
- Confirm that the destination passed the temporary-hostname tests and that the final SQL dump, code commit, Composer lock file, settings backup, and transfer checksums are preserved.
- Place the old site in maintenance or read-only mode for the final cutover if possible, and stop jobs that could write data while the last dump is created.
- Take the final database dump and import it into the destination. If new writes occurred after the earlier staged import, do not skip this step; repeat the import or apply a controlled, documented data-transfer plan.
- Run
drush cron the destination and repeat a short smoke test using the production hostname override. - Change the DNS records to the new server, then watch requests and error logs as resolvers update.
- Keep the old server online but prevented from accepting unintended writes. Retain the verified backups until traffic, logs, and functional tests remain clean for the period appropriate to your organization.
A live host move necessarily includes a DNS change. Do not decommission the old environment immediately: it is your fastest rollback path if a missed integration, permission problem, or data discrepancy appears after traffic arrives.
Best Value
- Used Book in Good Condition
Rollback and failure recovery
The destination shows a database connection error
Recheck the database name, host, port, driver, username, password source, and database-user permissions in settings.php. Confirm that the destination database service is listening on the address specified and that local firewall rules permit the connection. Verify that Drush and the web request are loading the same settings include.
Pages work but images or uploads fail
Check that the correct site-specific files directory was copied, that generated image styles exist or can be regenerated, and that the web process has the required read/write permissions. Review SELinux, AppArmor, container-volume, and filesystem ownership rules rather than changing permissions broadly.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Clear out junk files and repair common Windows errors3Scan for outdated or missing drivers - takes under a minutePrivate documents are exposed or inaccessible
Confirm the private path in settings.php, ensure it is outside the document root, and test both an authorized download and a direct unauthenticated request. A private file that can be fetched as a static URL indicates a web-server or path configuration problem that must be fixed before cutover.
Trusted-host or wrong-domain errors appear
Update $settings['trusted_host_patterns'] for every hostname used in testing and production. Check reverse-proxy headers and canonical redirects so the application sees the intended host and scheme.
New content is missing after launch
Determine whether it was created after the SQL dump. Keep the source database untouched, take a new consistent dump, and repeat the import into a clean destination database. Do not attempt a blind SQL search-and-replace when the domain changed; serialized data and environment-specific URLs require Drupal-aware procedures.
The new server must be abandoned
Leave DNS pointed at the old server, restore its write capability only after confirming that no destination-only writes need preservation, and document which dump and code commit were used. If DNS has already changed, revert the record and allow resolver caches to expire while you investigate using the retained destination copy and logs.
Version-specific and access-specific cautions
Composer-managed Drupal
Rebuild from the repository and lock file, then run Composer on the destination. Copying only the web directory can omit dependency metadata, custom code outside that directory, patches, or deployment files needed to reproduce the running application.
Drush archive workflows
Archive command names and capabilities differ by Drush release. Drush 14 documents archive:dump; older documentation refers to archive:restore, and archive restore was removed in Drush 13 according to current Composer guidance. Verify the installed release before depending on an archive command, and keep separate SQL and file backups even when an archive is used.
Administrators without shell access
The Backup and Migrate module can provide a database-and-files backup and restore workflow, with Drush integration where available. Control-panel workflows remain subject to hosting limits, so large SQL imports may still need the host’s native import facility or assistance from the provider.
Drupal 7 and older migration instructions
Older Drupal guidance is still useful for the broad order—copy code and files, import SQL, edit settings.php, adjust the host configuration, and change DNS—but Drupal 7-era commands and security assumptions should not be applied unchanged to Drupal 8, 9, 10, or 11. Use the procedures and configuration conventions of the versions actually installed.
When the move is complete
Declare the migration complete only when the new server serves the production hostname, representative content matches, public and private files behave correctly, scheduled work and mail are operating, integrations have been checked, and logs remain free of migration-related errors. Keep the exact SQL dump, code commit, Composer lock file, settings backup, and transfer checksums together with the change record so the move can be audited or reversed without reconstructing what happened.
Quick Recap
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.
