Shopware 6 upgrade wizard rollback limits when migrations fail midway

Short answer

No. Re-running the Shopware 6 upgrade wizard or clearing the cache does not revert schema changes that were committed before the failure point. The migration runner is forward-only: on re-execution it skips migrations already recorded as executed and attempts only the pending ones. There is no supported automatic rollback, and no built-in procedure that reliably identifies and removes orphaned tables or columns left behind by an interrupted upgrade. Without a pre-upgrade database snapshot, returning to the exact pre-failure state is not possible.

What is confirmed vs. likely

Confirmed behavior of the migration runner: Shopware 6 tracks executed migrations in a tracking table (the Doctrine-style migration version table). When the runner starts, it compares available migration classes against that table and executes only those not yet recorded. A migration that completed and was recorded before the failure will be skipped on every subsequent run — it will not be reversed, even if its changes are part of the problem.

Likely explanation for the mixed state: the wizard runs migrations incrementally, and each successfully executed migration is typically committed independently rather than inside one giant transaction spanning the whole upgrade. So a failure at migration N leaves migrations 1..N-1 permanently applied. Clearing var/cache/ only refreshes compiled container, proxy, and configuration artifacts; it touches no schema objects, so it cannot unwind anything.

Practical recovery steps for this case

1. Establish where the failure occurred. Inspect var/log/upgrade.log for the last successfully executed migration and the error that stopped the run.
2. Compare executed vs. pending migrations:

   bin/console doctrine:migrations:status

   This shows which migrations are recorded as executed and which remain pending — the authoritative map of your partial state.
3. Fix the blocking cause first. If a plugin compatibility check or a SQL error halted the run, resolve that (update/deactivate the plugin, correct the data conflict) before re-running anything. Re-running while the blocker persists just re-fails at the same point.
4. Re-run the pending migrations forward via the wizard or bin/console database:migrate --all (command names vary slightly by Shopware minor version — verify with bin/console list). The goal is to complete the upgrade, not to go backward.
5. Then clear caches and rebuild (bin/console cache:clear) so the application reflects the finished schema.

Orphaned schema objects

Tables and columns left over from prior versions are not purged automatically, and Shopware ships no supported cleanup tool that diffs your live schema against a canonical one. The practical options are:

• Compare your schema against a fresh install of the same target version and drop confirmed-orphan objects manually — only after a verified backup, since an incorrect drop is unrecoverable.
• Leave harmless orphans in place; an extra unused table generally does not break the application.

Assumptions and uncertainty

This assumes a Shopware 6.x line using the standard Doctrine-based migration component; exact console command names and the migration tracking table name can differ across minor versions, so verify against your installed version. One detail that would change the recommendation: the exact error message and migration name at the failure point in upgrade.log — if the failing migration itself partially executed before erroring (some DDL auto-commits and cannot be rolled back transactionally), manual schema repair may be needed before pending migrations can proceed.

The durable lesson: take a database dump immediately before every upgrade. Forward-only migration runners make the pre-upgrade snapshot the only true rollback mechanism.