Taxonomy Switcher migrates terms from one taxonomy to another in batches. Move all your old “tags” into a brand-new “keywords” taxonomy, or merge two custom taxonomies into a single one, without writing custom SQL or losing post relationships.
What this feature does
WordPress lets you create taxonomies easily but doesn’t give you any way to change them after the fact. If you decide your “tags” should really be a custom taxonomy called “topics,” you’re left with two unappealing options: write SQL by hand, or recreate every term and re-tag every post manually.
Taxonomy Switcher solves this. Pick a source taxonomy and a target taxonomy. AdminEase moves every term (and its post relationships) from source to target, in safe batches, with optional duplicate merging and source-cleanup.
You can only move terms between taxonomies that are registered against the same post type. For example, you can move terms from post_tag (tags) to a custom taxonomy that’s also registered for posts. Trying to move from a post taxonomy to a product-only taxonomy will fail validation.
How to enable it
- Open AdminEase › Taxonomies. Click AdminEase in the WordPress admin menu, then switch to the Taxonomies tab.
- Toggle Enable Taxonomy Switcher on. Save settings to mount the migration tool. The dashboard reloads and a Taxonomy Switcher panel appears below the toggle.
Settings reference
| Setting | What it does | Default |
|---|---|---|
| Enable Taxonomy Switcher | Master switch. Off means the tool isn’t mounted and the AJAX endpoints don’t exist. | Off |
| Batch Size | How many terms are processed per request. Range: 10 to 100. Lower values are safer on slow hosts. | 20 |
| Source Taxonomy | Where the terms come from. Picker lists every registered taxonomy. | Empty |
| Target Taxonomy | Where the terms go. Must share at least one post type with the source. | Empty |
| Delete Source Terms | When on, terms are removed from the source taxonomy after they’re moved. Off means they stay in both places. | Off |
| Merge Duplicate Terms | When a term with the same slug already exists in the target taxonomy, post relationships are reassigned to the existing term instead of failing or creating a numbered duplicate. | Off |
Running a switch
The workflow is always: validate, preview, confirm, run.
- Pick source and target. Choose the source and target taxonomies and the optional flags. AdminEase validates the pair behind the scenes and warns if the post types don’t overlap.
- Click Preview. AdminEase counts how many terms will be moved and how many post relationships are involved. The preview also lists a sample of term names and any potential duplicate-slug conflicts so you can decide whether to enable Merge Duplicate Terms.
- Confirm and run. Click the run button. AdminEase processes terms in batches of N (your Batch Size), updating a progress bar after each batch.
- Verify. After the run finishes, open the target taxonomy’s admin screen. The migrated terms should appear with their post counts intact. If Delete Source Terms was on, the source taxonomy should now be empty.
Taxonomy migrations rewrite the relationships table and (when Delete Source Terms is on) remove rows from wp_term_taxonomy. Always take a fresh database backup before running a switch on production data. The Preview step is your safety net but a backup is your insurance.
What happens behind the scenes
The tool uses three endpoints in sequence:
adminease_taxonomy_switch_validate: checks that the source and target both exist and share at least one post type. Returns the shared post types so the UI can display them.adminease_taxonomy_switch_preview: counts matched terms, returns labels and a sample.adminease_taxonomy_switch_batch: processes one batch of N terms per call. The UI calls it repeatedly until everything is processed.
Term relationships are migrated by updating the term_taxonomy_id on each row in wp_term_relationships. New term-taxonomy rows are created in the target taxonomy as needed. With Merge Duplicate Terms, conflicting slugs are resolved by reassigning relationships to the existing term and skipping the duplicate creation.
Common workflows
Move tags into a custom taxonomy
Source: post_tag (Tags). Target: your custom taxonomy. Enable Delete Source Terms if you want to retire tags entirely. Run.
Merge two custom taxonomies
Source: the smaller taxonomy. Target: the larger taxonomy. Enable both Merge Duplicate Terms and Delete Source Terms. After the run, retire the now-empty source taxonomy from your code.
Duplicate a taxonomy without losing the original
Source: the original. Target: a new empty custom taxonomy. Leave Delete Source Terms off. After the run, both taxonomies will have the same terms and the same post relationships.
Troubleshooting
The validate step says “source and target must share at least one post type”
Check the registration of both taxonomies. Look at the object_type argument in register_taxonomy(). If they don’t overlap, you can’t migrate; you’d be moving terms to a taxonomy that no posts can use.
Preview shows fewer terms than I expect
The preview counts only terms in the source taxonomy. If you have orphaned wp_terms rows not associated with any taxonomy (rare, usually from a botched plugin uninstall), they won’t show up. They also won’t be migrated.
The run finished but post counts on the new terms are zero
WordPress caches term counts. Visit Tools › Site Health or any page that triggers wp_update_term_count_now() to refresh. The relationships migrated correctly; only the cached count is stale.
The progress bar stalls partway through
Lower your Batch Size. Some hosts kill long-running PHP processes; smaller batches keep each request well under typical timeout windows.