## Overview Right now we have to manually implement upgrade stop planning and there may be ways to automate our upgrade documentation. ### Problem statement Self-managed instances can have a poor upgrade experience if they are not aware of a required upgrade stop beforehand. The upgrade will fail if background migrations are not complete before moving past one of these minor versions. This exacerbates the user's confidence that our upgrades will work, which decreases our upgrade rate and the percentage of users on the latest version of GitLab. ### Why we care It is in our best interest for customers to have the best experience managing a GitLab instance as possible in general. Furthermore, users able to access our latest features means they are able to get the most value out of GitLab. ### Scheduling upgrade stops We plan to proactively plan upgrade stops so that we can avoid unplanned upgrade stops, which causes a very poor experience for self-managed instances.