4.6.1. Proper Removal and Documentation Procedures
💡 First Principle: Before physically removing any server, you must verify it's no longer in use and document the decommissioning. Removing an active server causes an outage; removing a server without documentation creates an audit gap and potential legal liability.
Decommissioning Steps
- Verify non-utilization: Confirm the server has no active dependencies—no services running, no applications pointing to it, no scheduled tasks, no active user sessions. Review monitoring, application configs, and DNS records.
- Migrate dependent services: If anything still depends on this server, migrate those dependencies before decommissioning.
- Notify impacted parties: Users, application owners, and management should be notified of the retirement timeline.
- Data disposition: Determine what data must be preserved (legal hold, archive) vs. destroyed.
- License management: Return licenses to the license pool, transfer to another system, or terminate subscriptions.
- Documentation:
- Update asset management (mark as decommissioned)
- Record in change management
- Archive server configuration documentation
- Physical removal: After all software steps complete.
Company Policies
Decommissioning procedures should follow documented company policy. These policies address:
- Who has authority to approve decommissioning
- Required notification periods
- Data retention requirements during decommissioning
- Handoff procedures for hardware
⚠️ Exam Trap: Decommissioning must follow documented policy even for servers that appear unused. An "unused" server may be providing a service that no one has documented—removing it without verification can cause an unexpected outage.
Reflection Question: An administrator receives a request to immediately decommission an old server to free up rack space. The administrator has no documentation about what the server was used for. What steps must be taken before physical removal?
