The rollback guarantee, and its limits
Rollback is the reason this plugin exists, so it is worth being precise about what it promises and what it does not. Read the limits section before you rely on it.
The guarantee
After import → rollback, your database is in the state it was in before the import ran.
Concretely, for each row the import wrote:
Posts the import created are deleted permanently. Not trashed — deleted, along with their post meta, their taxonomy assignments and any images the import downloaded for them.
Posts the import updated are restored field by field. Before an update, the importer records the current value of every field it is about to change. Rollback writes those values back:
- The
wp_postsrow is restored column by column, includingpost_modifiedandpost_modified_gmt. This is written directly rather than throughwp_update_post(), because that function would stamp the modification date with the time of the rollback and leave the row differing from its pre-import state. - Every custom field the import touched is restored to its previous values, including having multiple values under one key. A key that did not exist before the import is deleted, not left as an empty string.
- Every taxonomy the import touched is restored to exactly the terms the post had before, in that taxonomy.
Posts the import never touched are not modified. Rollback works from a ledger of rows the import wrote. It has no reason to look at anything else, and it does not.
You get a report. How many posts were deleted, how many restored, and an itemised list of anything that could not be reverted with the reason.
This is verified in the test suite by diffing the wp_posts, wp_postmeta, wp_terms, wp_term_taxonomy and wp_term_relationships tables before an import and after a rollback, for every fixture in the corpus.
What is not restored
Terms the import created stay. If a row created the category "Nordic Crime", rollback removes the assignment of that category from the post but does not delete the term itself. Terms are shared: another post, or a person, may have started using it in the meantime, and deleting a term to undo an import is a bigger blast radius than the import had.
Delete unwanted terms yourself from the taxonomy screen afterwards. They will have a post count of zero if nothing else used them.
Auto-increment counters do not rewind. After importing and rolling back 1,000 posts, the next post you create has a higher ID than it would otherwise have had. This is how MySQL works and it affects nothing.
Anything another plugin did in response to the import. If a plugin hooks save_post and writes to its own tables, sends a webhook, pushes to a search index or generates a static page, rollback undoes the WordPress content but not the side effect. The importer cannot know about a table it has never heard of.
If you run something like that, roll back on a staging copy first.
Images that something else now uses. Rollback deletes images the import downloaded — unless one of them has since become the featured image of a post the import did not create. In that case the image is kept and the report says so, listing the attachment IDs.
Files you supplied by server path. Never touched, never deleted. That file is yours.
What can go wrong, and what happens
| Situation | Result |
|---|---|
| You deleted an imported post yourself before rolling back | Counted as "could not be reverted because it no longer exists". Everything else still rolls back. |
| You edited an imported post after the import | The rollback wins. Your later edit is overwritten with the pre-import value. Rollback restores the state before the import, not before your edit. |
| The rollback window expired | Rollback is unavailable and says so, with the expiry date. The imported content is untouched — only the undo data was deleted. |
| The import is still running | Cancel it first. Rollback then undoes everything it wrote up to the cancellation. |
| Rollback itself is interrupted | It resumes. Rollback runs in the same batched queue as imports, and each row is marked reverted as it is done, so a restart continues from where it stopped and never reverts a row twice. |
| A single row cannot be reverted | It is recorded in the report and the rollback continues. One problem row does not abort the rest. |
The retention window
Rollback data is kept for 30 days. With Importundo Pro you can set anything from 7 to 365 days, either globally in Importundo → Settings or per import on the mapping step before it runs.
The window is shown on screen before you start an import, not buried in settings, because the moment to decide how long you might need to undo something is before you do it.
When the window expires, a scheduled daily task deletes the snapshots and the stored source file. The imported content itself is never touched — only the ability to undo it automatically. The history entry remains, so you can still see what the import did.
Longer windows cost storage. A snapshot holds the previous values of the fields the import changed, so an import that updated 50,000 posts across ten fields stores considerably more than one that created 50,000 posts (a created post needs no snapshot at all — undoing it is a delete).
Rolling back a cancelled or failed import
You do not have to let an import finish to undo it. A cancelled, paused or failed import can be rolled back for whatever it managed to write.
This is the intended response to noticing mid-import that the mapping was wrong: Cancel, then Roll back. You are returned to where you started and can fix the mapping and run it again.
If rollback is not enough
Rollback is a targeted undo of one import, not a backup. It cannot help with a mistake made outside an import, and it deliberately does not touch anything the import did not.
Keep backups. Test large imports on staging first. Use the preview, which is free and shows you the problem before it becomes one.