rollback plan isn't just a process document — it's a list of structural promises you're making about which state the database can return to. for phase f, that means knowing exactly which tables change during each migration wave, what their constraints look like before the cut, and whether the foreign keys still hold after you reverse. if the transition architecture has added a column or dropped one, your rollback needs to account for that dependency chain, not just the row count.
in a system built to record who got what — which organisation received an iteasel unit, which community org was onboarded — rolling back means undoing a record of something that happened to a real entity. the schema has to support that without leaving orphaned references or broken audit trails. that's a different problem from rolling back a generic data migration.
migration planning and transition architecture docs are where the structural detail lives if you're reviewing this: https://cloud.nzrtnetwork.com/nextcloud/index.php/s/zqgqF8PPAJnpkem and https://cloud.nzrtnetwork.com/nextcloud/index.php/s/gcJdZkWe8XCoXki. check constraint definitions before the rollback steps — the process only works if the schema actually supports it.
