Feature Flags Need an Exit Plan

The rollout ends before the extra work does

Consider a university introducing a new program finder. A feature flag lets the web team expose the new experience gradually while keeping the previous version available. After the rollout, every visitor uses the new finder. The launch ticket closes.

Three months later, an editor requests a change to how program requirements appear. Engineering finds two rendering paths, two sets of tests, and an old flag nobody wants to touch. The previous finder remains in the code, but nobody knows whether it still works with the current content model.

This is a hypothetical example of a common delivery tension: a temporary release control can outlive the decision it was created to support.

For higher education web teams, distributed publishing makes that uncertainty expensive. Several departments may depend on the same templates while maintaining different content. Every retained branch gives the next change another place to investigate.

Feature flags are useful. Give temporary ones a planned end so they keep helping the team ship.

Decide which controls are temporary

A release flag selects between implementations during a rollout. Its retirement should become part of the release scope.

Other controls may need to stay. An operational kill switch can disable an expensive capability during an incident. An entitlement rule can govern which accounts receive a product feature. Those controls need ongoing ownership and testing; an arbitrary age limit is a poor reason to remove them. Access authorization must still be enforced by the application.

Unleash's feature-flag documentation distinguishes release flags from longer-lived kill switches and permission controls, and separates production use from cleanup in its lifecycle. The useful principle is to classify a control by its purpose before deciding that it is overdue.

For each temporary release flag, record five things in the existing delivery ticket:

• Owner: the person accountable for bringing retirement to a decision.
• Intended final behavior: which implementation or variant should remain.
• Evidence: what the team needs to observe before removing the old path.
• Review date: when to make that decision or explain why it needs more time.
• Recovery plan: what operators can do before and after the flag is removed.

A review date should prompt a decision. Automatically deleting a flag when a timer expires can change live behavior before the team is ready.

Prove the old path can be retired

“Enabled for everyone” describes configuration. Retirement requires knowing whether the old implementation still serves a purpose.

For the program finder, agree on representative journeys before calling the rollout complete. Include an undergraduate visitor filtering by subject, a graduate visitor comparing requirements, and an editor publishing a program update. Check keyboard use, empty results, detail-page links, and the inquiry handoff.

Choose an observation period that reflects actual use. A quiet weekend says little about a weekday publishing workflow. A rare program type may need a controlled check because waiting for ordinary traffic will not provide enough evidence. Define the expected behavior and acceptable failure levels before reading the results.

Then inspect the dependencies around the flag:

• Do all deployed application versions use the chosen path?
• Do background jobs, older browser sessions, or another site still evaluate the flag?
• Does the old path read fields that editors have stopped maintaining?
• Would restoring an earlier release require a data shape that has already changed?

Verify what rollback actually restores

Switching an interface back does not reverse records already written, restore removed fields, or undo messages already sent. A retained toggle may offer less recovery than its label suggests.

In the university example, the old finder may expect a single campus field while the new content model supports several locations. Keeping its code available does not establish that switching back would produce usable results.

If the team still needs the old path, test it against the current system and document its limits. If recovery now means deploying a corrected release or temporarily disabling the finder, make that the explicit operating plan. The retirement decision should reflect the recovery options that actually work.

Remove code before retiring configuration

Treat cleanup as a small release with its own verification. Unleash's cleanup guidance recommends removing obsolete code paths and flag references before archiving the flag.

For the program finder, a practical sequence is:

1. Confirm the chosen behavior. Review targeting rules across relevant environments and resolve any remaining exceptions.
2. Prepare the cleanup change. Make the accepted finder the ordinary implementation. Remove the obsolete branch and its flag lookup. Keep tests that verify the accepted user behavior, and update fixtures that existed only to exercise the retired branch.
3. Deploy and inspect. Run the agreed journeys against the deployed cleanup release. Check for remaining evaluations from other services, workers, sites, and supported client versions.
4. Close the recovery window deliberately. Confirm that any release still eligible for rollback can operate with the configuration that will remain. Wait for or explicitly handle older clients that still need the flag.
5. Archive the flag. Preserve its decision history and configuration record, then update the runbook and support notes.

Test how the actual SDK and application behave when a flag is unavailable. Depending on the implementation, an old caller may use a fallback value that selects the retired behavior. A quiet evaluation dashboard alone is insufficient evidence if telemetry is delayed, disabled, or missing for part of the system.

Keep unrelated refactoring out of this release. A focused change makes it easier to see whether the intended behavior survived the removal. The same logic behind small release trains for enterprise web teams applies: keep the decision and verification small enough to finish.

Give retirement a place in ongoing support

Flag cleanup belongs in continuous support and optimization because it protects the team's ability to change production systems after launch.

Use the existing backlog. Link the cleanup task when the rollout task is created, reserve time for it, and revisit it during the team's planned platform maintenance windows.

Track temporary flags awaiting a decision, cleanup work ready to ship, and retirements blocked by a specific dependency. Each blocked item should have an owner and a next review date. Total flag count alone mixes useful operational controls with forgotten release scaffolding.

For a support review, ask three concrete questions:

1. Which completed rollout still makes us maintain two implementations?
2. What evidence or dependency prevents us from removing the old one?
3. Who can resolve that condition, and in which release?

Those answers are more useful than a general instruction to reduce technical debt. They turn a vague maintenance concern into bounded work.

Finish with one maintained behavior

A successful rollout should leave the team with a clear implementation to maintain and a recovery plan it understands.

Start with one completed rollout. Confirm the flag's purpose, test the retirement assumptions, ship the code cleanup, and archive the configuration when supported callers and recovery plans allow it. Preserve the accepted behavior throughout that sequence.

The payoff is practical: the next editor request, accessibility fix, or platform upgrade has fewer obsolete paths to account for.

If temporary release controls are making routine changes harder, Start a Project to map the cleanup work and operating decisions around one production workflow.