Migrating to GoDaddy Managed WordPress when DB table prefixes differ

Hi Migrate Guru Support,

I recently completed a migration using the free Migrate Guru plugin from a WordPress website hosted by 1ClickWebsite to a client’s GoDaddy Basic Managed WordPress hosting.

The migration ultimately succeeded, but we encountered a database table-prefix issue that caused considerable troubleshooting.

I’m hoping to understand whether we missed an important step in the migration process and, more importantly, establish the correct procedure to prevent this from happening again.

Our migration setup

The destination was a new GoDaddy Managed WordPress hosting installation that already had a default, blank WordPress website installed.

We installed Migrate Guru on the source and destination sites and performed the migration.

The two installations had different database table prefixes:

• Source (1ClickWebsite): wp_
• Destination (GoDaddy): wp_433e1b8df5_

What happened

Migrate Guru completed the migration, and the migrated website’s files and database tables were present on the destination hosting.

However, both sets of database tables remained in the destination database:

• The original GoDaddy WordPress tables (wp_433e1b8df5_)
• The migrated website’s tables (wp_)

The destination WordPress installation was still configured to use the original GoDaddy prefix in wp-config.php.

Consequently, visiting the website displayed the original blank GoDaddy WordPress installation, including the default “Hello world!” post, rather than the migrated website.

After changing $table_prefix in wp-config.php to wp_, the correct migrated website loaded.

We subsequently encountered further confusion because GoDaddy’s server-side caching continued displaying the original starter website even after the configuration was corrected. We eventually identified that separately by comparing the normal URL against a cache-bypassing URL and flushing GoDaddy’s cache.

The migration now appears to be functioning correctly.

What I’m trying to understand

I’ve found other WordPress.org discussions suggesting that Migrate Guru intentionally preserves existing destination tables when their prefix differs from the source site’s prefix.

I understand why that might be desirable, especially when multiple WordPress installations share a database.

What I don’t understand is how Migrate Guru is intended to handle the destination’s wp-config.php configuration in this scenario.

Specifically:

1. Is this expected behavior?

When the source and destination have different table prefixes, is it normal for Migrate Guru to import the source tables alongside the destination’s existing tables?

2. Should Migrate Guru automatically update wp-config.php?

After importing the source database tables, is Migrate Guru supposed to update the destination’s $table_prefix setting to match the imported tables?

Or is this a configuration step that the person performing the migration is expected to handle manually?

3. What is the recommended procedure before GD WP migration?

For future migrations to GoDaddy Managed WordPress, should we:

• Create the required blank destination WordPress installation and leave its automatically generated database prefix unchanged?
• Change the destination’s table prefix to match the source before running Migrate Guru?
• Or use a different approach entirely?

I want to avoid making unnecessary database changes that could break the destination installation.

4. What should we verify after migration?

If the source and destination prefixes differ, is checking and potentially correcting $table_prefix in the destination’s wp-config.php an expected part of the migration process?

5. Are there any GoDaddy Managed WordPress-specific considerations?

Given that GoDaddy automatically provisions a WordPress installation when setting up Managed WordPress hosting, is there a particular procedure you recommend for this hosting environment?

My ultimate goal

I regularly build WordPress websites for small businesses and occasionally migrate them to client-owned hosting and am in a community of over 500 people doing the same model. Migrate Guru is our default tool for migrations. I’m developing a written SOP for future migrations and would like to follow Migrate Guru’s recommended process rather than rely on trial and error.

I’m particularly interested in understanding whether the table-prefix mismatch could have been prevented before migration, or whether correcting the destination’s configuration afterward is simply an expected step when using Migrate Guru.

Any guidance from your team would be greatly appreciated.