During an upgrade of an application it is handy to have backups available, but once normal operation ensues, they are out of date.
If it turns out that there is a critical problem a day after the upgrade, and a solution takes too much time, a roll back could be a preferable option.
At the moment we tend to give roll back as an option for risk mitigation, but lacking tools it is a last option in case of data model changes. Restoring a backup would mean losing a day’s work, while a roll back would only lose data in the mismatch between the two data models.
Is it a lot of trouble to generate a roll back script including reverse data migration in addition to the regular upgrade script?
Hi Boudewijn,
It is already possible to generate a 'downgrade' script by referring the version management of the old version to the new version and then regenerating this old version. Is this what you mean?