How to Run a Security Audit Before a Site Migration

Why migration is the moment to check

A security audit before site migration is worth running because migration is the only routine occasion when someone inventories every file and every database table on a site. That makes it the cheapest possible opportunity to find things that should not be there, and skipping it wastes the one moment the work is already half done.

Three specific risks a migration carries if you do not audit. Persistence transfers. A web shell in an uploads directory or an injected function in a theme file copies across exactly like legitimate code. The timeline resets. On the new host, every file has a fresh modification date, so the single most useful forensic signal — what changed and when — is destroyed. And credentials propagate, because configuration files carry database passwords and API keys that may already be known to someone else.

A security audit before site migration is therefore not an optional extra step; it is the difference between moving a site and moving a problem.

Verify file integrity first

Do this on the old environment while the original timestamps still exist, because you cannot recover them afterwards.

1. Compare core and extension files against official checksums. Any modified file in a directory that should be pristine is a finding, not a curiosity.
2. Look for executable code where content belongs. Uploads directories should contain media, not scripts. This single check catches a large share of real compromises.
3. Sort every file by modification date and review anything changed outside a deployment you can account for.
4. List files with unusual permissions, particularly anything world-writable.
5. Check for files hidden by naming — leading dots, names imitating core files, or extensions that the web server will execute.
6. Record hashes of what you intend to migrate, so you can verify the copy arrived unaltered.

Where you find something you cannot explain, do not simply delete it and proceed. Preserve a copy, note where it was, and establish how it arrived — otherwise the same route will be used again on the new host.

The database is where things hide

File scanning is well understood and database contents are frequently skipped, which is precisely why injected content persists through migrations.

Four checks worth running against a copy of the database:

• Search post content for script tags, iframes and base64-encoded blocks. Injected spam and redirect code lives in content rather than in files.
• Review options and settings tables for unfamiliar entries, especially anything holding a URL or encoded data.
• Check scheduled tasks. A scheduled event that re-creates a backdoor after cleanup is a common persistence mechanism, and it migrates with the database.
• List administrator accounts and confirm each one belongs to a person you can name.

That last item overlaps with the next section and deserves the duplication, because an unexpected administrator account is the finding most likely to change what you do next.

Accounts, keys and credentials

Treat migration as a credential rotation event. Everything in the old environment should be assumed to have been readable by whoever had access to it, including former staff, agencies and the previous host.

Rotate on the new environment: database credentials, any application secrets or salts, API keys for third-party services, and hosting control panel and SFTP passwords. Remove old SSH keys rather than copying the authorized keys file across — that file is a list of who can log in, and it is rarely audited.

Then reduce the account list. Delete users who have left, downgrade contributors who do not need administrative rights, and confirm multi-factor authentication is enabled for everyone who remains. A migration is the rare moment when changing this causes no disruption because everything is changing anyway.

Hardening at cutover

The new environment starts clean, and a handful of decisions made at build time are far easier now than later.

Set correct file permissions from the outset rather than loosening them to fix a problem and never tightening them again. Disable code execution in upload directories at the web server level. Confirm the platform and language versions are supported releases, not whatever the old host happened to run. Put the site behind an edge layer before pointing DNS at it, so the origin address is never publicly associated with the domain. And configure logging to somewhere off the server, so a future incident leaves evidence an attacker cannot delete.

Finally, verify TLS properly after cutover — including whether the certificate covers every hostname you serve. A certificate valid for the apex domain but not the www host is a common and user-visible failure, and it is exactly the kind of thing a migration introduces.

The checklist

• Audit on the old host first, while timestamps are intact.
• Compare files against official checksums and hunt for executables in uploads.
• Search the database for injected content, unfamiliar options and scheduled tasks.
• Rotate every credential and do not copy authorized keys across.
• Reduce the administrator list and enable multi-factor authentication.
• Harden the new environment at build time, and log off-server.
• Verify TLS for every hostname after cutover.

Run that sequence and a security audit before site migration adds perhaps half a day to the project while removing the possibility of the most expensive outcome: a clean new environment that was compromised before it served its first visitor. Our migration checklist covers the non-security mechanics of the move.