Troubleshooting guide
Can't log in after a WordPress migration? Diagnose it in the right order.
The password hash almost certainly survived the move intact. Migration login failures are nearly always a prefix, URL, cookie, or plugin problem wearing a "wrong password" costume.
The salt lives inside the stored hash, so copying the database preserves every password exactly.
New wp-config.php keys log everyone out of their sessions — they never invalidate a password.
"Incorrect password", a redirect loop, and "permissions" errors have three different causes.
Two myths to discard before touching anything
Myth one: "the password hashes broke in transit." WordPress password hashes — legacy $P$ and modern $wp$2y$ alike — embed their own salt inside the stored string. Nothing about them depends on the server, the domain, the PHP version, or the keys in wp-config.php. If the row arrived in the new database byte-identical, the password verifies. Hash corruption during a normal export/import is vanishingly rare.
Myth two: "I regenerated the salts, so all the passwords changed." The keys and salts in wp-config.php sign session cookies; they play no role in password storage. Rotating them forces everyone to sign in again — with the same password as before. If you rotated salts during the migration (a fine practice), expect a logout, not a lockout. The salts guide covers exactly what they do.
Match the symptom to the failure
Unknown usernameYou imported the wrong or an older databaseRow counts and latest records in the new DBIncorrect passwordWrong DB, truncated import, or a login-replacing pluginVerify the hash locally, then disable auth pluginsRedirect loop on wp-loginsiteurl/home still point at the old domain, or HTTPS mismatchwp_options rows 1–2, TLS proxy headersSufficient permissions error$table_prefix does not match the imported tableswp-config.php vs. actual table namesLogin page keeps reappearingCookies rejected: stale cache, cookie-domain constants, or new saltsHard-refresh, COOKIE_DOMAIN, browser consoleThe diagnosis sequence
Step 1 — prove which database the site is reading. More migrations fail here than anywhere else: the new wp-config.php quietly points at an old, empty, or staging database. Check DB_NAME, DB_HOST, and $table_prefix, then confirm the users table actually contains your account with a recent user_registered or your latest content nearby. If the prefix in the config says wp_ but the imported tables are wpx1_*, you will see permission errors or a site that half-works — the users-table guide shows how prefixes and multisite naming behave.
Step 2 — verify the credential against the hash, locally. Copy the user_pass value for your account and check your password against it with the local hash verifier — it handles $wp$2y$, $P$, plain bcrypt, and MD5 without the password leaving your browser. A match tells you the database is fine and the fault lies in URLs, cookies, or a plugin. A mismatch tells you this is not the database you think it is, or the import was incomplete.
Step 3 — fix the URLs, not the login. If siteurl and home in wp_options still carry the old domain, wp-login.php bounces you between hosts and the session cookie never sticks. Update both values (or set WP_HOME/WP_SITEURL temporarily), and if the new site terminates TLS at a proxy, make sure WordPress knows it is being served over HTTPS before you blame the password.
Step 4 — take the security layer out of the equation. Login-limiting, 2FA, CAPTCHA, and "hide wp-login" plugins frequently misbehave on a new domain — locked lockout tables, mismatched secrets, or a renamed login URL you forgot. Rename each suspect plugin's directory to disable it, then retry. If login succeeds, re-enable them one at a time.
Step 5 — reset the password through WordPress, not around it. Once the environment is proven sane, a clean reset via WP-CLI (or the phpMyAdmin procedure when the shell is unavailable) beats another hour of guessing. If the reset email never arrives, that is its own diagnosis.
Before you migrate the next site
- Record the table prefix, WordPress version, and active security plugins of the source site.
- Export and import with the same tool end-to-end; verify table counts match after import.
- Run the domain search-replace with a serialization-aware tool, never a raw SQL
REPLACE(). - Rotate the salts as part of go-live and expect the resulting logout.
- Test login on the new host via a hosts-file override before switching DNS.
Quick answers
Do WordPress passwords stop working after a migration?
No. The stored hash contains its own salt and does not depend on the server, domain, or wp-config.php keys. If the database row migrated intact, the old password still verifies on the new host.
Does changing the salts in wp-config.php break passwords?
No. New salts invalidate session cookies, so every user must sign in again, but their passwords are untouched. A lockout after rotating salts has another cause.
Why does wp-login.php just reload without an error?
That is almost always a cookie or URL problem: siteurl/home pointing at the old domain, an HTTPS mismatch behind a proxy, or aggressive page caching serving a stale login form. The password is not being rejected — the session cookie is.
How do I check whether the migrated hash matches my password?
Copy the user_pass value from the users table and test your password against it with a local verifier that supports WordPress formats. A match proves the database is fine; a mismatch means you are looking at the wrong or an incomplete database.
Primary references: Migrating WordPress and wp_check_password().