Site Migration Wiped My Theme Settings? Fix It Fast

Your theme customizations just vanished. I know that sinking feeling.

You migrated your WordPress site — maybe to a new host, maybe a fresh domain — and suddenly your header logo, colors, fonts, and layout settings are all gone. The site looks like a naked skeleton of what it was.

I've been there. Ran a help desk for years, saw this at least twice a week. The fix is simpler than you think.

Step 1: Find your old site's theme mods in the database

Your theme customizations live in the wp_options table, inside a row called theme_mods_yourthemename. For a theme like Astra, it's theme_mods_astra.

Before you do anything, back up your old database. Seriously. One wrong click and you're in worse shape.

Open phpMyAdmin on your old site. Run this query:

SELECT * FROM wp_options WHERE option_name LIKE 'theme_mods_%';

If you changed the table prefix from wp_ to something else (like site2_), adjust that in the query. Most hosts use wp_ by default.

You'll see one row for your active theme. Click "Export" on that row — just that single row, not the whole table. Choose SQL format.

Step 2: Import that row into your new site

On your new site's phpMyAdmin, run the same query to check if there's already a theme_mods_ row for your theme. If it exists, delete it. If it doesn't, you're ready.

Then import the SQL file you exported. That's it. Your customizations are back.

Why did this work?

Most migration plugins (Duplicator, All-in-One WP Migration, even manual FTP + SQL dumps) copy everything except the theme mods sometimes. Why? Because theme mods are serialized data — they contain arrays of settings. When the database is exported and re-imported, the serialization can break if the site URL changes.

WordPress stores your site URL in the home and siteurl options. When you migrate, these URLs get replaced. But the theme mods row often gets skipped because it's not fully understood by many migration tools. So the settings disappear.

By manually moving just that row, you bypass the broken migration flow completely.

What if the customization still doesn't show up?

Sometimes the theme mods are stored in a different place. Check these variations:

1. Theme uses the Customizer API with a different option name

Some themes store settings in option_name like _options_mytheme or mytheme_settings. Look for anything with your theme name in the wp_options table. Export and import those too.

2. Your theme uses a page builder (Elementor, Beaver Builder, WPBakery)

Page builders often store global styles in separate tables like wp_postmeta or their own options. For Elementor, search for elementor_ in wp_options. Export all rows starting with that prefix.

3. Custom CSS is in the Additional CSS box

That lives in wp_options under option_name = theme_mods_yourthemename — we already covered that. But double-check that the row you exported actually contains custom_css in its serialized array. If not, run this query on the old site:

SELECT * FROM wp_options WHERE option_name = 'theme_mods_yourthemename';

Then copy the option_value column content manually into the new site's same row. You can do this with phpMyAdmin's edit function. Just paste the value into the field.

How to prevent this from happening again

I've got two methods. Pick one.

Method 1: Use WP-CLI (if you have SSH access)

Before migration, run this on the old site:

wp option get theme_mods_yourthemename --format=json > theme-mods-backup.json

After migration, run this on the new site:

wp option update theme_mods_yourthemename --format=json < theme-mods-backup.json

This is the fastest method. Takes 10 seconds.

Method 2: Manual backup with phpMyAdmin

Export the wp_options table but only filter for option_name starting with theme_mods_. Keep that export file safe. If the migration goes wrong, you can import it directly into the new site's database.

Pro tip: Also export option_name values starting with widget_ — those contain sidebar widget settings. They vanish too sometimes.

One last thing

If you're using a managed WordPress host (WP Engine, Kinsta, Flywheel), their migration tools often handle theme mods correctly. But never trust it 100%. Always do a test migration on a staging site first. I learned that the hard way — spent 4 hours rebuilding a client's theme because I skipped the test run.

You've got this. Go get those settings back.