By Lenae Storey
Overview
Every government solution — whether a policy, procedure, service, or system — follows a lifecycle. Gradually, these solutions become outdated, no longer solve the right problem, or get bogged down by aging processes or technology. Deprecation is a systematic way to phase out these unused or outdated solutions so government works better.
Problem
Instead of proactively retiring ineffective or outdated solutions or operating models in government, we layer new ones on top to meet new mandates.
Over time, this creates layers of “cruft” — the gradual build-up of redundant and arduous systems and processes. Cruft can be incompatible technology, outdated requirements, duplicative processes, or PDF forms with fax cover sheets. The result? Rising costs, overburdened staff, slower response times, and the erosion of public trust in government institutions.
Solution
Deprecation helps government teams proactively address the buildup of old processes and technology and replace them with better alternatives. Deprecation doesn’t mean the solution no longer works — it means there is a more effective or sustainable way to deliver our missions. It ensures continuity, backward compatibility, and gives people relying on the old solution time to adapt to new options. Deprecations are a key part of continuous improvement and iterative delivery of services and programs.
Context
Without intentional deprecation, improvement stalls. 80% of federal IT budgets go to maintaining legacy systems. State offices waste valuable hours each month on outdated, manual processes. Then we spend even more on large modernization projects that repeat the cycle.
Deprecation as a solution
Deprecation should be a natural part of solution lifecycle management. Deprecation doesn’t abruptly remove solutions. Like pruning a tree, deprecation removes obsolete governance policies or technology that hinder growth so systems stay relevant and responsive.
What to deprecate
Deciding what and where to deprecate is as critical as deciding what to build. Deprecation can apply across all levels of government and solutions, from the smallest software components to overarching policies.
- At the component level: phasing out outdated logic within a software codebase to make way for upgraded or more secure alternatives.
- At the feature level: removing unused functionality that consumes limited resources allows teams to focus on value-adding features.
- At the service level: identifying and gradually eliminating workflow friction by streamlining to more outcome-driven processes.
- At the rules level: retiring cumbersome procurement documentation requirements in favor of sandbox and prototype assessments.
While deprecation is possible at all levels, the feasibility, impact, and risk differ as you move from technical to organizational levels. Make decisions based on a solution’s ability to fulfill its intended purpose and deliver the right outcome.
When to deprecate
Deprecation isn’t usually tied to specific timelines. Deciding when to deprecate depends on a solution’s relevance and effectiveness throughout its lifecycle.
Generally, it’s time to deprecate when:
- A solution is not being used and provides little to no value
- A significantly better alternative exists
- The solution is outdated, causing issues and consuming resources
- The solution is dependent on an underlying technology (like an operating system) that you’re already deprecating
Teams should set baseline metrics to evaluate the need and timing for a deprecation. For example, you could track baseline metrics like application completion rate, user satisfaction, and uptime performance for a system that has remained unchanged since launch. When the system doesn’t meet those benchmarks, teams can spot what needs improving or deprecating. You must evaluate the potential timing and impact, whether quickly deprecating an unused feature or phasing out a widely-used program.
How to deprecate
Start by understanding the problem and current state using user-centered research methods like interviews, feedback analysis, and service or dependency mapping. Revisit the original solution or program’s vision to ensure the new solution better addresses the original need.
Create a deprecation roadmap with clear milestones and feedback loops to minimize disruption. Roadmaps should account for offboarding users, staff, and stakeholders from the existing solution to alternative options. Include a communication plan with stakeholders explaining why the deprecation is necessary and highlighting key benefits of the new alternative.
Integrating deprecation into your delivery approach can help you respond to growing complexity, reduce costs, and future-proof existing solutions. Deprecation isn’t just about removing what’s old or unuseful — it’s about intentionally creating room for what’s better.
Mantras
- Deprecate to gain, not lose
- Deprecation is progress
Checklist
- Conduct discovery to learn about the current solution’s value, usage, and dependencies to inform decisions.
- Evaluate the impact of deprecation, assess risks, and develop mitigation plans.
- Set criteria for a new solution and define success metrics and transition requirements.
- Create a roadmap for a phased deprecation plan with milestones and a user transition strategy.
- Set a strategy by appointing a primary owner, aligning supporting teams, and getting stakeholder buy-in.
- Announce changes so users, stakeholders, and teams understand what’s happening and how to adapt.
Questions to ask
- What need does the current solution address, who uses it, and how often?
- What teams, services, or systems depend on this solution or process?
- Is there a significantly better alternative and can it scale better than the existing solution?
- What is the impact (including costs and risks) of keeping the current solution versus retiring it?
- What does a successful and safe deprecation look like for our users, stakeholders, and partners?
- What is the long-term vision for this policy, process, or solution, independent of the current state?
