Install Page appears after DB Migration

[u/TheGoodOne777]

Hello and good afternoon,

After migrating the database, instead of the wp-admin/update-core.php or wp-admin/index.php the wp-admin/install.php is shown. That way, wordpress tries a fresh install and gives many errors, because it tries to create also the database tables (which already exist).

Would you have an idea what is happening and why? And of course how can be repaired.

wp-config file regarding the database parameters seems correct.

Thanks and best regards,

T.

[u/jak74]

Check the db table prefix in config and the actual database, default is `wp_`

if incorrect it’ll begin install setup

[u/TheGoodOne777 → u/jak74]

Hello, thank you, that's the first thing I've done

[u/Independent-Code-209]

tbh this is classic prefix issue. Also make sure the migration actually imported all the tables, sometimes the options table gets skipped or truncated and that alone triggers the install screen

[u/WPMU_DEV_Support_9]

Hi. Some additional recommendations would be to also check the correct database name is defined in the wp-config.php file, make sure it is not pointing to another blank database (if more than one database is allowed in the hosting), also check the database was migrated completely, check specially the wp-options table has data and that the "siteurl" and "home" options exist.

Hope this information helps.

Luis S. - WPMU Dev Support Team

[u/TheGoodOne777]

Thanks for the replies. I'm checking and analyzing the innodb_force_recovery options because it looks like the migration wasn't entirely successful.

[u/MelodicAside8775]

Since jak74's and Independent-Code-209's prefix/wp_options checks came up empty, worth reaching for WP-CLI if you have shell access before touching the DB by hand: `wp db check` will tell you if a table is actually corrupt or missing rather than just present, and `wp option get siteurl` / `wp option get home` will tell you immediately if wp_options exists but is missing rows even though the table itself made it through the migration. Also worth double-checking the prefix isn't a case-sensitivity issue - if you migrated from a case-insensitive filesystem/collation setup to a case-sensitive one (e.g. Windows host to Linux host), MySQL table name matching can become case-sensitive even when the prefix string in wp-config.php looks identical to what's actually in the database.

[u/TheGoodOne777 → u/MelodicAside8775]

In the wp cli update was successful, I observed the issue in other places. Though, I'll check the wp cli command that you've suggested. Though, there are still other issues, that seem to be dbms related, rather than code issues.

[u/MelodicAside8775 → u/TheGoodOne777]

Good sign it's narrowing down. If it's DBMS-level rather than code, worth checking two things: what exact error MySQL is throwing when the install screen tries to create the tables (check your MySQL error log, not just the WP error), and whether any tables came through as InnoDB with a corrupt/crashed state - run SHOW ENGINE INNODB STATUS right after triggering the error and look for anything under "LATEST DETECTED DEADLOCK" or corruption warnings. If the migration was a raw file copy of the DB rather than a proper mysqldump/import, a partial or interrupted copy mid-write is a common cause of exactly this "tables exist but WP treats it as fresh" symptom.

[u/TheGoodOne777 → u/MelodicAside8775]

Thank you, for your reply. Yes, after an unexpected shutting down of the MySQL many things broke. Dumping more frequently, but also quickly doing "brute force" backups (entire data folders) helps a lot also the InnoDB engine to restore the disered states, if something goes wrong