Copy WordPress Plugin Settings from Dev to Production with WP-CLI
Plugin settings usually live in the WordPress database, not in the plugin files. When a plugin is configured on a development site and the same settings need to move to production, the safest process is to export only the plugin's known option values, review the file, then import those values into production with WP-CLI.
This workflow is similar to moving WordPress articles from dev to production, but it is more conservative. Posts are normal content records. Plugin settings can include API keys, environment-specific URLs, account IDs, cache paths, or licensing values, so the exported file should be reviewed before it is applied anywhere else.
What It Does
- Finds the option names that belong to the plugin.
- Exports selected option values from the development WordPress database.
- Stores the reviewed settings file in a source or release folder.
- Imports the reviewed values into the production WordPress database.
- Verifies the production values after import.
- Avoids copying the full database when only plugin settings are needed.
Before You Start
Install and activate the same plugin on both sites before copying settings. The import should update settings for an already installed plugin, not secretly install a new plugin or replace production code.
Use two different paths in the commands:
- Source repository or release folder:
C:\DevOps\DEV-Site - Development WordPress install:
C:\inetpub\sites\example-dev.com - Production WordPress install:
C:\inetpub\sites\example.com
The source repository does not have to be the WordPress install. The important part is that each wp --path value points to the correct WordPress folder.
Confirm the Plugin on Both Sites
Start by confirming the plugin is installed and active on development:
wp --path="C:\inetpub\sites\example-dev.com" plugin list --fields=name,status,version
Then check production:
wp --path="C:\inetpub\sites\example.com" plugin list --fields=name,status,version
If the plugin versions are different, update the older site first or review the plugin's changelog before copying settings. A newer plugin version may store settings differently.
Find the Plugin Option Names
Most WordPress plugins save settings in the wp_options table. The option names often contain the plugin slug, company name, or feature name.
Search development for likely option names:
wp --path="C:\inetpub\sites\example-dev.com" option list --search="plugin_slug" --fields=option_name,autoload
For example, if the plugin slug is example-plugin, search with:
wp --path="C:\inetpub\sites\example-dev.com" option list --search="example_plugin" --fields=option_name,autoload wp --path="C:\inetpub\sites\example-dev.com" option list --search="example-plugin" --fields=option_name,autoload
Write down only the option names that are clearly owned by the plugin. Do not copy unrelated WordPress options such as siteurl, home, active_plugins, rewrite rules, transients, cron data, or cache values.
Create a Settings Export Folder
From the source repository root, create a folder for the reviewed settings export:
Set-Location C:\DevOps\DEV-Site New-Item -ItemType Directory -Force -Path .releases\plugin-settings
Use one file per plugin and environment:
.releases\plugin-settings\example-plugin-dev-options.json
Export Selected Settings from Development
Use wp option get for each known option and save the values into a JSON file. This example exports two plugin options:
Set-Location C:\DevOps\DEV-Site
$settings = [ordered]@{}
$settings["example_plugin_settings"] = wp --path="C:\inetpub\sites\example-dev.com" option get example_plugin_settings --format=json | ConvertFrom-Json
$settings["example_plugin_display"] = wp --path="C:\inetpub\sites\example-dev.com" option get example_plugin_display --format=json | ConvertFrom-Json
$settings | ConvertTo-Json -Depth 50 | Set-Content -Encoding UTF8 .\.releases\plugin-settings\example-plugin-dev-options.json
If an option is a plain string instead of a structured array, remove --format=json for that option and store it as text:
$settings["example_plugin_license_mode"] = wp --path="C:\inetpub\sites\example-dev.com" option get example_plugin_license_mode
Review the Export
Open the JSON file before importing it into production. Look for values that should not move from development to production:
- Local development URLs.
- Test account IDs.
- API keys or access tokens.
- License keys tied to one domain.
- Absolute file paths.
- Cache folders or generated temporary values.
- Webhook callback URLs.
- Email recipient lists.
If a value is environment-specific, edit the JSON file before import or leave that option out of the migration.
Back Up Production Values First
Before importing, export the current production values to a separate backup file:
Set-Location C:\DevOps\DEV-Site
$backup = [ordered]@{}
$backup["example_plugin_settings"] = wp --path="C:\inetpub\sites\example.com" option get example_plugin_settings --format=json | ConvertFrom-Json
$backup["example_plugin_display"] = wp --path="C:\inetpub\sites\example.com" option get example_plugin_display --format=json | ConvertFrom-Json
$backup | ConvertTo-Json -Depth 50 | Set-Content -Encoding UTF8 .\.releases\plugin-settings\example-plugin-production-backup.json
Keep this backup until the production site has been checked. It gives you a quick rollback path if the copied setting causes a problem.
Import Settings into Production
Load the reviewed JSON file and update the production options one at a time:
Set-Location C:\DevOps\DEV-Site $settings = Get-Content .\.releases\plugin-settings\example-plugin-dev-options.json -Raw | ConvertFrom-Json $examplePluginSettings = $settings.example_plugin_settings | ConvertTo-Json -Depth 50 -Compress $examplePluginDisplay = $settings.example_plugin_display | ConvertTo-Json -Depth 50 -Compress wp --path="C:\inetpub\sites\example.com" option update example_plugin_settings $examplePluginSettings --format=json wp --path="C:\inetpub\sites\example.com" option update example_plugin_display $examplePluginDisplay --format=json
For plain string options, pass the value directly:
wp --path="C:\inetpub\sites\example.com" option update example_plugin_license_mode $settings.example_plugin_license_mode
Do not run a blanket database import for this kind of task. A full database copy can overwrite production posts, users, orders, comments, URLs, and live plugin data that should not be replaced.
Verify Production
After the import, confirm the values in production:
wp --path="C:\inetpub\sites\example.com" option get example_plugin_settings --format=json wp --path="C:\inetpub\sites\example.com" option get example_plugin_display --format=json
Then open wp-admin and check the plugin settings screen. Save the settings once from the admin screen if the plugin needs to rebuild derived values, regenerate CSS, refresh rewrite rules, or validate remote service credentials.
Finally, check the public feature that depends on the plugin. For example, if the plugin controls a gallery, form, payment method, SEO output, cache behavior, or language switcher, verify that specific frontend behavior instead of only checking that the option value exists.
Roll Back if Needed
If the copied settings are wrong, restore the production backup:
Set-Location C:\DevOps\DEV-Site $backup = Get-Content .\.releases\plugin-settings\example-plugin-production-backup.json -Raw | ConvertFrom-Json $examplePluginSettings = $backup.example_plugin_settings | ConvertTo-Json -Depth 50 -Compress $examplePluginDisplay = $backup.example_plugin_display | ConvertTo-Json -Depth 50 -Compress wp --path="C:\inetpub\sites\example.com" option update example_plugin_settings $examplePluginSettings --format=json wp --path="C:\inetpub\sites\example.com" option update example_plugin_display $examplePluginDisplay --format=json
After rollback, clear any plugin cache and recheck the plugin's admin screen.
When Not to Copy Plugin Settings This Way
Do not use this option-copy approach when the plugin stores important data in custom database tables. Ecommerce orders, form submissions, LMS records, CRM activity, booking records, analytics data, and logs often live outside wp_options.
For those plugins, inspect the plugin documentation and database tables first:
wp --path="C:\inetpub\sites\example-dev.com" db tables --all-tables
If the plugin uses custom tables, decide whether you are moving only configuration, moving content records, or performing a full plugin data migration. Those are different tasks and should have separate backup and verification steps.
WP-CLI Setup
If wp is not available in the terminal yet, install WP-CLI first. The setup steps and basic command examples are covered in Install WP-CLI on Windows and Run Basic WordPress Commands.