Douglas Adams famously said he loves deadlines for the sound they make as they pass. This sentiment reflects a broader truth in software development: all systems age. Software might be digital, but as technology evolves, older systems can become obsolete. Maintaining these outdated systems drains resources and complicates operations. Instead of letting them linger, organizations should consider deprecating and removing them. This process involves careful planning and execution to minimize costs and improve efficiency. The chapter focuses primarily on technical systems rather than end-user products, emphasizing the internal policies and practices needed to effectively manage deprecation. Google’s experience with deprecation underscores the challenges involved. While having multiple systems might seem manageable, it often leads to increased maintenance costs and complicates the evolution of newer systems. Users may find themselves relying on both old and new systems, which can create dependencies that hinder progress. Effective deprecation requires recognizing that code is a liability, not an asset. Organizations must evaluate the costs of keeping legacy systems running against the benefits of transitioning to newer solutions. The presence of a better replacement is essential for deprecation to be considered. Emotional attachment to old systems can complicate the deprecation process. Engineers may resist removing code they’ve spent years developing, even when it becomes a burden. Google addresses this resistance by allowing access to historical code in its repository, ensuring that even deprecated systems can be retrieved if necessary. Funding and executing deprecation efforts can be politically challenging because the costs of doing nothing are often invisible, while the costs of deprecation are tangible. Convincing stakeholders of the value in removing obsolete systems is crucial for long-term success.