We [plan to make it possible to have zero downtime migrations](https://gitlab.com/gitlab-org/gitlab-ce/issues/26130) between each subsequent release. It is hard to have zero-downtime migrations when someone upgrades between many versions at once, so our plan assumes that we will require downtime when someone wants to upgrade between multiple releases. Maintaining a zero-downtime migrations between releases might require shipping releases with a clean-ups / workarounds which purpose only is to avoid downtime. This is a valid approach, but it increases chances of problems when someone wants to upgrade between multiple releases at once, with downtime. Let's consider a scenario that actually should never happen. 1. We need to migrate some data from NFS to a database. 1. We prepare a new column in the database, but because we want to avoid downtime, we decide to persist new records in the database and still use NFS as a source of old "records". 1. This implementation supports both data sources, we deploy this to gitlab.com as 9.10 and it works well! 1. We decide that using two data sources is a technical debt and we want to migrate everything into the database. This still can't be done without a downtime, because we require a data integrity during the runtime. 1. We prepare a runtime mechanism in 9.11 that migrates data from NFS to the database while maintaining a data integrity. 1. We deploy 9.11 and entire data-set migrates correctly! 1. In 9.12 we remove this mechanism since everything is migrated on gitlab.com, no need for this code anymore. 1. Someone performs an offline upgrade from 9.9 to 9.14 and encounters serious data integrity problems. I believe that it is not likely that similar scenario will ever happen, but having automated test for upgrading data from 9.0 -> current version (when actually 9.0 contains some data in the database) might be still good idea. This is easily achievable with GitLab QA, because we now keep test scenarios for each version, thus we will be able to populate 9.0 with data, and upgrade to 10.10 afterwards. and verify if everything works well. What do you think about it @yorickpeterse @stanhu @rymai?