<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=385312) </details> <!--IssueSummary end--> <!-- This template is a great use for issues that are feature::additions or technical tasks for larger issues.--> ### Proposal <!-- Use this section to explain the feature and how it will work. It can be helpful to add technical details, design proposals, and links to related epics or issues. --> One of the steps around feature flags is that after the rollout has terminated, we remove the check from the code and the old code goes away. But between that moment and the moment where the feature flag is default to true for the customer, one or more releases elapse. While the feature flag is in the code, customers have the option to toggle it off for any particular reason, maybe the new code is breaking a flow or a feature in their specific pattern of usage. This means that when they're upgrading GitLab to the version where the feature flag check was removed, the behavior will automatically, and probably unexpectedly, revert to the new code ("Feature Flag ON" scenario). ### Context Despite not being sure how prevalent and frequent this problem might be for our customers, we were wondering if it would be possible to: 1. Keep documented the milestone in which the feature flag was removed from the code. 2. When upgrading an instance, check the current feature flag settings for the instance 2.1 If any feature flag removed since last update is toggled OFF 2.2 Issue a (blocking?) warning, asking for confirmation to proceed anyway. <!-- Consider adding related issues and epics to this issue. You can also reference the Feature Proposal Template (https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Feature%20proposal%20-%20detailed.md) for additional details to consider adding to this issue. Additionally, as a data oriented organization, when your feature exits planning breakdown, consider adding the `What does success look like, and how can we measure that?` section. --> <!-- Label reminders Use the following resources to find the appropriate labels: - https://gitlab.com/gitlab-org/gitlab/-/labels - https://about.gitlab.com/handbook/product/categories/features/ -->