Rationalization & Decommissioning

Rationalization Decision Tree

Walk through this flowchart to arrive at a TIME quadrant classification for any application in your portfolio.

                        +---------------------------+
                        |   Is the application      |
                        |   actively used?           |
                        +---------------------------+
                           /                  \
                         YES                   NO
                         /                      \
              +-----------------+        +-----------------+
              | Does it provide |        | Are there legal |
              | business value? |        | or compliance   |
              +-----------------+        | retention reqs? |
                /           \            +-----------------+
              YES            NO            /           \
              /               \          YES            NO
    +-------------+    +------------+     |        +----------+
    | Is it       |    | Can users  |     |        | ELIMINATE |
    | technically |    | migrate to |  RETAIN      | (Retire)  |
    | sound?      |    | another    |  w/ minimal  +----------+
    +-------------+    | system?    |  investment
      /        \       +------------+
    YES        NO        /       \
    /           \      YES       NO
+---------+ +----------+ +----------+
| INVEST  | | MIGRATE  | | TOLERATE |
| (Keep & | | (Move to | | (Maintain|
|  grow)  | |  modern) | |  as-is)  |
+---------+ +----------+ +----------+

Key Acronyms

Common Rationalization Triggers

Rationalization initiatives are typically catalyzed by one or more of these organizational events:

TIME Model Quadrants

Each application in your portfolio maps to one of four quadrants based on its business value and technical quality:

The 6Rs at a Glance

When an application survives rationalization, choose the right migration path:

Application Inventory Techniques

No single method catches everything. Combine automated and manual approaches for completeness:

CMDB: Key Attributes to Capture

Your Configuration Management Database becomes the single source of truth. At minimum, capture these attributes for every application:

Discovery Tools Comparison

Shadow IT Detection Methods

Up to 40% of enterprise IT spend occurs outside official channels. Finding shadow IT is critical for an accurate inventory.

AWS Discovery CLI Commands

Use the AWS Application Discovery Service to enumerate workloads prior to migration:

# Start continuous data collection via the Discovery Agent
aws discovery start-continuous-export

# List discovered servers with key attributes
aws discovery describe-configurations \
    --configuration-type SERVER

# Export server details for offline analysis
aws discovery start-export-task \
    --export-data-format CSV

# Check export status
aws discovery describe-export-tasks

# List discovered applications (agent-grouped)
aws discovery list-configurations \
    --configuration-type APPLICATION

# Tag servers with rationalization decisions
aws discovery create-tags \
    --configuration-ids "d-server-01a2b3c4d5" \
    --tags key=RationalizationDecision,value=RETIRE

# Fetch network connection data between servers
aws discovery describe-configurations \
    --configuration-type CONNECTION \
    --filters name=sourceServerId,values=d-server-01a2b3c4d5,condition=EQUALS

CMDB Schema Snippet

A minimal relational schema for tracking applications and their dependencies:

CREATE TABLE applications (
    app_id          VARCHAR(20) PRIMARY KEY,
    app_name        VARCHAR(255) NOT NULL,
    description     TEXT,
    business_owner  VARCHAR(255),
    technical_owner VARCHAR(255),
    business_unit   VARCHAR(100),
    criticality     VARCHAR(20) CHECK (criticality IN
                        ('Critical','High','Medium','Low')),
    lifecycle_stage VARCHAR(30) CHECK (lifecycle_stage IN
                        ('Active','Sunset','Decommissioned','Under Review')),
    hosting_env     VARCHAR(30) CHECK (hosting_env IN
                        ('On-Prem','IaaS','PaaS','SaaS','Hybrid')),
    tech_stack      TEXT[],           -- Array of technology tags
    annual_tco      NUMERIC(12,2),
    active_users    INTEGER DEFAULT 0,
    data_class      VARCHAR(30),
    eol_date        DATE,
    eos_date        DATE,
    time_category   VARCHAR(20),      -- Tolerate/Invest/Migrate/Eliminate
    six_r_strategy  VARCHAR(20),      -- Rehost/Replatform/Refactor/etc.
    created_at      TIMESTAMPTZ DEFAULT NOW(),
    updated_at      TIMESTAMPTZ DEFAULT NOW()
);

CREATE TABLE app_dependencies (
    id              SERIAL PRIMARY KEY,
    source_app_id   VARCHAR(20) REFERENCES applications(app_id),
    target_app_id   VARCHAR(20) REFERENCES applications(app_id),
    dependency_type VARCHAR(50),      -- API, Database, File, Message Queue
    protocol        VARCHAR(50),      -- REST, SOAP, JDBC, SFTP, AMQP
    data_flow       VARCHAR(20) CHECK (data_flow IN
                        ('Inbound','Outbound','Bidirectional')),
    criticality     VARCHAR(20),
    description     TEXT,
    UNIQUE(source_app_id, target_app_id, dependency_type)
);

CREATE TABLE app_costs (
    id              SERIAL PRIMARY KEY,
    app_id          VARCHAR(20) REFERENCES applications(app_id),
    cost_category   VARCHAR(50),      -- License, Infrastructure, Support, Labor
    annual_amount   NUMERIC(12,2),
    vendor          VARCHAR(255),
    contract_end    DATE,
    notes           TEXT
);

-- Useful indexes for rationalization queries
CREATE INDEX idx_apps_lifecycle ON applications(lifecycle_stage);
CREATE INDEX idx_apps_time ON applications(time_category);
CREATE INDEX idx_apps_eol ON applications(eol_date);
CREATE INDEX idx_deps_source ON app_dependencies(source_app_id);
CREATE INDEX idx_deps_target ON app_dependencies(target_app_id);

Phase 1 Discovery Checklist (Weeks 1-4)

• Identify executive sponsor and secure mandate for discovery Without top-down authority, business units may not cooperate with data requests
• Deploy automated discovery agents across all network segments Cover production, staging, DR, and DMZ environments
• Extract software asset data from SCCM / Intune / Jamf Desktop and endpoint software is often overlooked
• Pull cloud resource inventories from AWS, Azure, and GCP accounts Use native tools: AWS Config, Azure Resource Graph, GCP Asset Inventory
• Request vendor contract and licensing data from Procurement Include renewal dates, termination clauses, and per-seat costs
• Distribute application owner survey to all business units Keep surveys short: app name, purpose, users, criticality, alternatives
• Correlate CASB and SSO logs to detect shadow IT Flag any discovered app not present in the CMDB
• Establish the CMDB schema and begin populating records Start with automated data; enrich with manual survey results in weeks 3-4
• Validate discovered inventory with infrastructure and security teams Cross-check against firewall rules, DNS records, and load balancer configs
• Publish Phase 1 Discovery Report with app count and coverage metrics Report should include confidence level and known gaps

TIME Model Deep Dive

The TIME model plots every application on a 2x2 matrix. The Y-axis represents business value (strategic alignment, revenue contribution, user satisfaction). The X-axis represents technical fitness (architecture quality, security posture, maintainability, performance).

                        TECHNICAL FITNESS
                   Low                    High
               +------------------+------------------+
               |                  |                  |
   High        |    MIGRATE       |    INVEST        |
               |                  |                  |
               |  High value but  |  Strategic and   |
  BUSINESS     |  poor tech.      |  well-built.     |
  VALUE        |  Modernize or    |  Fund growth.    |
               |  replatform.     |                  |
               +------------------+------------------+
               |                  |                  |
   Low         |    ELIMINATE     |    TOLERATE      |
               |                  |                  |
               |  No value, bad   |  Works fine but  |
               |  tech. Retire    |  not strategic.  |
               |  immediately.    |  Minimal invest. |
               |                  |                  |
               +------------------+------------------+

Business Value Scoring Criteria

Score each application from 1 (lowest) to 5 (highest) across these dimensions, then compute a weighted average:

Technical Fitness Scoring Criteria

Evaluate the technical health of each application across these dimensions:

Scoring Formulas

Compute composite scores and map them to TIME quadrants using threshold values:

# Business Value Score (BVS)
BVS = (Strategic_Alignment * 0.30)
    + (Business_Criticality * 0.25)
    + (Utilization * 0.20)
    + (Revenue_Impact * 0.15)
    + (User_Satisfaction * 0.10)

# Technical Fitness Score (TFS)
TFS = (Architecture_Quality * 0.25)
    + (Security_Posture * 0.25)
    + (Performance_Reliability * 0.20)
    + (Maintainability * 0.15)
    + (Scalability * 0.15)

# TIME Quadrant Assignment (threshold = 3.0)
if BVS >= 3.0 and TFS >= 3.0:  INVEST
if BVS >= 3.0 and TFS <  3.0:  MIGRATE
if BVS <  3.0 and TFS >= 3.0:  TOLERATE
if BVS <  3.0 and TFS <  3.0:  ELIMINATE

# Composite Score (for ranked prioritization)
Composite = (BVS * 0.55) + (TFS * 0.45)

Assessment Questionnaire: Key Questions

Use these questions during stakeholder interviews to gather the data needed for scoring:

Python Assessment Scoring Script

Automate TIME quadrant assignment from CSV survey data:

#!/usr/bin/env python3
"""
Rationalization Scoring Engine
Reads application survey data and assigns TIME quadrants.
Input:  CSV with columns for each scoring criterion (1-5 scale)
Output: CSV with BVS, TFS, TIME quadrant, and composite score
"""
import csv
import sys
from dataclasses import dataclass
from typing import List

# --- Weight Configuration ---
BV_WEIGHTS = {
    "strategic_alignment": 0.30,
    "business_criticality": 0.25,
    "utilization": 0.20,
    "revenue_impact": 0.15,
    "user_satisfaction": 0.10,
}

TF_WEIGHTS = {
    "architecture_quality": 0.25,
    "security_posture": 0.25,
    "performance_reliability": 0.20,
    "maintainability": 0.15,
    "scalability": 0.15,
}

QUADRANT_THRESHOLD = 3.0


@dataclass
class AppAssessment:
    app_id: str
    app_name: str
    bvs: float = 0.0
    tfs: float = 0.0
    quadrant: str = ""
    composite: float = 0.0


def compute_weighted_score(row: dict, weights: dict) -> float:
    """Compute weighted average from survey responses."""
    score = 0.0
    for criterion, weight in weights.items():
        value = float(row.get(criterion, 0))
        value = max(1.0, min(5.0, value))  # Clamp to 1-5
        score += value * weight
    return round(score, 2)


def assign_quadrant(bvs: float, tfs: float) -> str:
    """Map scores to TIME quadrant."""
    if bvs >= QUADRANT_THRESHOLD and tfs >= QUADRANT_THRESHOLD:
        return "INVEST"
    elif bvs >= QUADRANT_THRESHOLD and tfs < QUADRANT_THRESHOLD:
        return "MIGRATE"
    elif bvs < QUADRANT_THRESHOLD and tfs >= QUADRANT_THRESHOLD:
        return "TOLERATE"
    else:
        return "ELIMINATE"


def process_portfolio(input_file: str, output_file: str) -> List[AppAssessment]:
    """Process all applications and write scored output."""
    results = []

    with open(input_file, newline="", encoding="utf-8") as f:
        reader = csv.DictReader(f)
        for row in reader:
            app = AppAssessment(
                app_id=row["app_id"],
                app_name=row["app_name"],
            )
            app.bvs = compute_weighted_score(row, BV_WEIGHTS)
            app.tfs = compute_weighted_score(row, TF_WEIGHTS)
            app.quadrant = assign_quadrant(app.bvs, app.tfs)
            app.composite = round(app.bvs * 0.55 + app.tfs * 0.45, 2)
            results.append(app)

    # Sort by composite score (lowest first = highest priority to act)
    results.sort(key=lambda a: a.composite)

    # Write output
    with open(output_file, "w", newline="", encoding="utf-8") as f:
        writer = csv.writer(f)
        writer.writerow(["app_id", "app_name", "bvs", "tfs",
                          "quadrant", "composite"])
        for app in results:
            writer.writerow([app.app_id, app.app_name, app.bvs,
                             app.tfs, app.quadrant, app.composite])

    # Print summary
    quadrant_counts = {}
    for app in results:
        quadrant_counts[app.quadrant] = quadrant_counts.get(
            app.quadrant, 0) + 1

    print(f"\n{'='*50}")
    print(f"  Portfolio Assessment Summary")
    print(f"  Total Applications: {len(results)}")
    print(f"{'='*50}")
    for q in ["INVEST", "MIGRATE", "TOLERATE", "ELIMINATE"]:
        count = quadrant_counts.get(q, 0)
        pct = (count / len(results) * 100) if results else 0
        bar = "#" * int(pct / 2)
        print(f"  {q:10s}  {count:4d}  ({pct:5.1f}%)  {bar}")
    print(f"{'='*50}\n")

    return results


if __name__ == "__main__":
    if len(sys.argv) != 3:
        print("Usage: python assess.py input.csv output.csv")
        sys.exit(1)
    process_portfolio(sys.argv[1], sys.argv[2])

Assessment Best Practices

TCO Calculation Methodology

Total Cost of Ownership extends far beyond the license fee. A rigorous TCO model accounts for every dollar spent to keep an application running, including costs that never appear on the application's budget line.

Additional hidden costs that are frequently underestimated:

ROI Modeling

The return on investment formula for rationalization is straightforward, but the inputs require careful estimation. Conservative assumptions build credibility with finance teams.

# ================================================
# ROI Calculation for Application Rationalization
# ================================================

# Step 1: Calculate Annual Savings
#   Sum of all costs eliminated when the app is retired
annual_savings = (
    infrastructure_cost       # Servers, storage, network freed
  + license_cost              # Licenses terminated or reallocated
  + support_contract_cost     # Vendor support cancelled
  + labor_cost_reduction      # FTE hours redirected to other work
  + integration_maintenance   # Point-to-point integrations removed
)

# Step 2: Calculate One-Time Migration Cost
migration_cost = (
    data_migration_labor      # ETL development, validation, testing
  + parallel_running_cost     # Dual-environment period (10-20% budget)
  + user_retraining           # Training materials, sessions, downtime
  + consultant_fees           # External expertise for legacy platforms
  + tooling_and_automation    # Migration scripts, reconciliation tools
  + project_management        # PM, change management, communications
  + contingency_buffer        # 20-30% of above for unknowns
)

# Step 3: Compute ROI
roi_percent = ((annual_savings - migration_cost) / migration_cost) * 100

# Step 4: Break-Even Analysis
break_even_months = migration_cost / (annual_savings / 12)

# ================================================
# Example: Legacy CRM Decommission
# ================================================
annual_savings   = 340_000   # $340K/year total cost eliminated
migration_cost   = 480_000   # $480K one-time migration cost

roi_year_1 = ((340_000 - 480_000) / 480_000) * 100  # -29.2% (still paying off)
roi_year_2 = ((680_000 - 480_000) / 480_000) * 100  # +41.7% (cumulative savings)
roi_year_3 = ((1_020_000 - 480_000) / 480_000) * 100 # +112.5%

break_even = 480_000 / (340_000 / 12)  # 16.9 months

Real-World Case Studies

Documented results from organizations that have executed rationalization programs at scale:

Industry Benchmarks

Reference data points for benchmarking your rationalization program against industry norms:

Cost-Benefit Template

Use this template to structure the financial case for each rationalization candidate. Fill in actual values from discovery and assessment data:

Tracking & Reporting Savings

Why Dependencies Matter

Every application exists in a web of connections. Removing one node without understanding its edges creates unpredictable failures downstream. Dependency mapping is the single most important risk-mitigation activity in any rationalization program.

Dependency Discovery Techniques

No single method finds all dependencies. Use a layered approach that combines automated detection with human knowledge:

Dependency Types

Classify each discovered dependency by its integration pattern. The type determines the mitigation strategy required before decommission:

Upstream vs. Downstream Impact

For every application being evaluated, analyze impact in both directions:

Dependency Mapping Tools

Blast Radius Calculation

Quantify the potential impact of decommissioning an application by computing its blast radius score. This combines the number of dependent systems with their criticality:

# ================================================
# Blast Radius Scoring for Decommission Candidates
# ================================================

def calculate_blast_radius(app_id, dependency_graph):
    """
    Walk the dependency graph to find all systems
    that would be impacted by removing this application.
    Returns a risk score and list of affected systems.
    """
    affected = set()
    queue = [app_id]

    # BFS traversal of upstream dependencies
    while queue:
        current = queue.pop(0)
        upstream = dependency_graph.get_upstream(current)
        for dep in upstream:
            if dep.target_id not in affected:
                affected.add(dep.target_id)
                queue.append(dep.target_id)  # Follow chain

    # Score each affected system by criticality weight
    CRITICALITY_WEIGHTS = {
        "Critical": 10,   # Revenue-generating, regulatory
        "High":      5,   # Core business process
        "Medium":    2,   # Departmental tool
        "Low":       1,   # Convenience / reporting
    }

    blast_score = 0
    for system_id in affected:
        system = get_application(system_id)
        weight = CRITICALITY_WEIGHTS.get(system.criticality, 1)
        blast_score += weight

    return {
        "app_id":          app_id,
        "affected_count":  len(affected),
        "blast_score":     blast_score,
        "affected_systems": list(affected),
        "risk_level":      classify_risk(blast_score),
    }

def classify_risk(score):
    """Map blast score to risk tier."""
    if score >= 20:  return "CRITICAL"   # Requires exec approval
    if score >= 10:  return "HIGH"       # Requires architect review
    if score >= 5:   return "MEDIUM"     # Standard CAB approval
    return "LOW"                         # Team-level decision

# --- Risk Matrix ---
# Likelihood: How likely is the dependency to cause failure?
#   HIGH   = Synchronous call, no fallback
#   MEDIUM = Async/batch, partial fallback exists
#   LOW    = Shared library, cached data, redundant path
#
# Impact: What is the business impact if this dependency breaks?
#   CRITICAL = Revenue loss, regulatory violation
#   HIGH     = Major business process disruption
#   MEDIUM   = Departmental impact, workaround available
#   LOW      = Inconvenience, cosmetic, reporting delay
#
#              Impact
#            LOW  MED  HIGH CRIT
# Likelihood +----|----|----|----+
# HIGH       | M  | H  | C  | C  |
# MEDIUM     | L  | M  | H  | C  |
# LOW        | L  | L  | M  | H  |
#            +----|----|----|----+
# L=Low, M=Medium, H=High, C=Critical

Dependency Graph Notation

For each edge in your dependency graph, document these attributes to enable accurate impact analysis:

The 6Rs Framework

Originally developed by Gartner (as the 5Rs) and expanded by AWS, the 6Rs framework categorizes every possible migration outcome. Each application should be assigned exactly one R based on its business value, technical fitness, dependencies, and organizational constraints. The right choice balances speed, cost, risk, and long-term strategic value.

R1: Rehost (Lift & Shift)

R2: Replatform (Lift & Reshape)

Common replatform optimizations:

R3: Refactor (Re-architect)

Common refactoring patterns:

R4: Repurchase (Replace with SaaS)

Common repurchase targets:

R5: Retain (Keep As-Is)

R6: Retire (Decommission)

Strategy Comparison Matrix

Migration Strategy Decision Tree

Walk through this decision tree for each application to arrive at the optimal R:

                    +---------------------------+
                    |   Is the application       |
                    |   actively used?            |
                    +---------------------------+
                       /                  \
                     YES                   NO
                     /                      \
          +------------------+       +------------------+
          | Does it need to  |       | Is data retention |
          | exist in-house?  |       | required?          |
          +------------------+       +------------------+
            /           \               /           \
          YES            NO           YES            NO
          /               \           /               \
  +--------------+  +-----------+  RETAIN         +---------+
  | Is it cloud- |  | SaaS alt  |  (archive       | RETIRE  |
  | ready as-is? |  | available?|  data, then     +---------+
  +--------------+  +-----------+  retire later)
    /        \        /       \
  YES        NO     YES       NO
  /           \     /          \
REHOST    +--------+ REPURCHASE  RETAIN
          | Worth  |             (revisit)
          | re-    |
          | arch?  |
          +--------+
           /      \
         YES      NO
         /         \
    REFACTOR    REPLATFORM

Real-World Portfolio Mix Patterns

In practice, organizations apply a mix of strategies across their portfolio. The ideal mix depends on organizational goals, timeline, and budget. Here are three common patterns:

Strategy Assignment Logic

Use assessment scores and dependency data to recommend the optimal migration strategy programmatically:

# ================================================
# 6R Strategy Assignment Engine
# ================================================
# Inputs: TIME quadrant, technical fitness, business value,
#         dependency count, active users, annual TCO

def assign_strategy(app):
    """
    Recommend a 6R strategy based on assessment data.
    Returns primary recommendation and alternatives.
    """

    # ELIMINATE quadrant -> check if Retire or Retain
    if app.time_quadrant == "ELIMINATE":
        if app.active_users == 0 and app.upstream_deps <= 2:
            return "RETIRE"
        elif app.data_retention_required:
            return "RETAIN"   # Archive data first, then retire
        else:
            return "RETIRE"

    # TOLERATE quadrant -> Retain or Repurchase
    if app.time_quadrant == "TOLERATE":
        if app.saas_alternative_exists and app.tco > app.saas_cost:
            return "REPURCHASE"
        else:
            return "RETAIN"

    # MIGRATE quadrant -> Replatform or Refactor
    if app.time_quadrant == "MIGRATE":
        if app.technical_fitness < 2.0:
            return "REFACTOR"          # Too degraded to just move
        elif app.can_containerize and app.managed_db_compatible:
            return "REPLATFORM"
        else:
            return "REFACTOR"

    # INVEST quadrant -> Rehost or Replatform
    if app.time_quadrant == "INVEST":
        if app.cloud_ready and app.deadline_months <= 3:
            return "REHOST"            # Speed priority
        elif app.technical_fitness >= 4.0:
            return "REPLATFORM"        # Already solid; optimize
        else:
            return "REPLATFORM"

    return "RETAIN"  # Default: revisit later

Phased Approach Overview

Decommissioning is not a single event but a multi-phase process spanning weeks or months. Each phase has defined gates that must be passed before proceeding.

Pre-Decommission Checklist

Complete every item before scheduling the Go/No-Go meeting. Skipping items is the leading cause of decommission rollbacks.

• Stakeholder sign-off obtained (business owner, IT, legal, compliance) All four groups must sign; a missing legal sign-off can halt the entire process
• All dependencies verified and removed or rerouted Cross-reference dependency map from Section 05 with current traffic analysis
• Data backup completed and verified with test restore A backup that has never been restored is not a backup
• Data archival plan executed per retention policy Confirm retention periods meet regulatory requirements (see Section 08)
• Replacement system confirmed operational and load-tested Run parallel operations for a minimum of 2 weeks before cutover
• User migration and retraining complete Track completion rates; aim for 95%+ before scheduling decommission
• Vendor notifications sent per contract timeline Most contracts require 30-90 days written notice; check early termination clauses
• License termination dates scheduled Align with contract renewal dates to avoid paying for unused periods
• DNS TTL lowered 24-48 hours before decommission Allows rapid propagation of record removals on decommission day
• Monitoring and alerting reconfigured Remove old checks; add new alerts for dependent systems that may break
• Rollback plan documented and tested Include snapshot locations, restore procedures, and decision criteria
• Communication sent to all affected users Include decommission date, replacement system URL, and support contact
• Go/No-Go meeting scheduled with all required attendees Schedule at least 48 hours before decommission window; prepare decision matrix

DNS & Certificate Cleanup

Stale DNS records and expired certificates are security risks and operational debt. Clean them up as part of the decommission.

# List hosted zones to find the target zone
aws route53 list-hosted-zones --query "HostedZones[*].[Id,Name]" --output table

# Export current records for audit trail before deletion
aws route53 list-resource-record-sets \
  --hosted-zone-id Z0123456789ABCDEF \
  --output json > /backup/dns-records-$(date +%Y%m%d).json

# Delete A record for the decommissioned application
aws route53 change-resource-record-sets \
  --hosted-zone-id Z0123456789ABCDEF \
  --change-batch '{
    "Changes": [{
      "Action": "DELETE",
      "ResourceRecordSet": {
        "Name": "legacy-app.example.com",
        "Type": "A",
        "TTL": 300,
        "ResourceRecords": [{"Value": "10.0.1.50"}]
      }
    }]
  }'

# Delete CNAME records pointing to the decommissioned host
aws route53 change-resource-record-sets \
  --hosted-zone-id Z0123456789ABCDEF \
  --change-batch '{
    "Changes": [{
      "Action": "DELETE",
      "ResourceRecordSet": {
        "Name": "app.example.com",
        "Type": "CNAME",
        "TTL": 300,
        "ResourceRecords": [{"Value": "legacy-app.example.com"}]
      }
    }]
  }'

# Verify deletion
aws route53 list-resource-record-sets \
  --hosted-zone-id Z0123456789ABCDEF \
  --query "ResourceRecordSets[?Name=='legacy-app.example.com.']"

# Let's Encrypt — revoke and delete certificate
certbot revoke --cert-name legacy-app.example.com --reason cessationofoperation
certbot delete --cert-name legacy-app.example.com

# AWS ACM — delete certificate (must be disassociated from all resources first)
aws acm list-certificates --query "CertificateSummaryList[?DomainName=='legacy-app.example.com']"
aws acm delete-certificate --certificate-arn arn:aws:acm:us-east-1:123456789012:certificate/abc-def-123

# Internal PKI — revoke via OpenSSL
openssl ca -revoke /etc/pki/CA/newcerts/legacy-app.pem -config /etc/pki/CA/openssl.cnf
openssl ca -gencrl -out /etc/pki/CA/crl/ca.crl -config /etc/pki/CA/openssl.cnf

# Verify certificate is no longer valid
openssl s_client -connect legacy-app.example.com:443 -servername legacy-app.example.com 2>/dev/null | \
  openssl x509 -noout -dates 2>/dev/null || echo "Certificate no longer served"

Credential Revocation

Every credential associated with the decommissioned system must be revoked. Orphaned credentials are a top attack vector.

# Identify IAM roles used by the application
aws iam list-roles --query "Roles[?contains(RoleName, 'legacy-app')].[RoleName,Arn]" --output table

# Detach all managed policies from the role
aws iam list-attached-role-policies --role-name legacy-app-role \
  --query "AttachedPolicies[*].PolicyArn" --output text | \
  xargs -I {} aws iam detach-role-policy --role-name legacy-app-role --policy-arn {}

# Delete inline policies
aws iam list-role-policies --role-name legacy-app-role \
  --query "PolicyNames[]" --output text | \
  xargs -I {} aws iam delete-role-policy --role-name legacy-app-role --policy-name {}

# Remove instance profiles
aws iam remove-role-from-instance-profile \
  --instance-profile-name legacy-app-profile --role-name legacy-app-role
aws iam delete-instance-profile --instance-profile-name legacy-app-profile

# Delete the role
aws iam delete-role --role-name legacy-app-role

# List service accounts in the application namespace
kubectl get serviceaccounts -n legacy-app -o wide

# Remove RBAC bindings
kubectl delete clusterrolebinding legacy-app-binding
kubectl delete rolebinding legacy-app-binding -n legacy-app

# Delete the service account
kubectl delete serviceaccount legacy-app-sa -n legacy-app

# Delete the namespace (removes all remaining resources)
kubectl delete namespace legacy-app --grace-period=60

-- PostgreSQL: revoke and drop application user
REVOKE ALL PRIVILEGES ON ALL TABLES IN SCHEMA public FROM legacy_app_user;
REVOKE ALL PRIVILEGES ON ALL SEQUENCES IN SCHEMA public FROM legacy_app_user;
REVOKE CONNECT ON DATABASE appdb FROM legacy_app_user;
DROP USER IF EXISTS legacy_app_user;

-- MySQL: revoke and drop
REVOKE ALL PRIVILEGES, GRANT OPTION FROM 'legacy_app_user'@'%';
DROP USER IF EXISTS 'legacy_app_user'@'%';
FLUSH PRIVILEGES;

# AWS Secrets Manager — schedule deletion (7-30 day recovery window)
aws secretsmanager delete-secret \
  --secret-id legacy-app/db-credentials \
  --recovery-window-in-days 30

aws secretsmanager delete-secret \
  --secret-id legacy-app/api-keys \
  --recovery-window-in-days 30

# HashiCorp Vault — revoke and delete
vault lease revoke -prefix secret/legacy-app/
vault kv metadata delete secret/legacy-app/db-credentials
vault kv metadata delete secret/legacy-app/api-keys
vault policy delete legacy-app-policy

Infrastructure Teardown

Remove infrastructure in reverse dependency order: load balancers first, then compute, then storage. Always deregister before deleting.

# AWS ALB — deregister targets and delete target group
aws elbv2 describe-target-groups \
  --query "TargetGroups[?contains(TargetGroupName, 'legacy-app')].[TargetGroupArn]" --output text

aws elbv2 deregister-targets \
  --target-group-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/legacy-app/abc123 \
  --targets Id=i-0abc123def456,Port=8080

# Remove listener rules pointing to the target group
aws elbv2 delete-rule --rule-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:listener-rule/app/main-alb/abc/def/rule123

# Delete target group after deregistration
aws elbv2 delete-target-group \
  --target-group-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/legacy-app/abc123

# Azure LB — remove backend pool member
az network lb address-pool address remove \
  --resource-group rg-legacy --lb-name lb-legacy \
  --pool-name legacy-app-pool --name legacy-vm-1

# AWS Security Group — revoke ingress/egress and delete
aws ec2 describe-security-groups \
  --filters "Name=group-name,Values=legacy-app-sg" \
  --query "SecurityGroups[*].[GroupId,GroupName]" --output table

aws ec2 revoke-security-group-ingress --group-id sg-0abc123 \
  --ip-permissions '[{"IpProtocol":"tcp","FromPort":443,"ToPort":443,"IpRanges":[{"CidrIp":"0.0.0.0/0"}]}]'

aws ec2 delete-security-group --group-id sg-0abc123

# Azure NSG — remove rules and delete
az network nsg rule delete --resource-group rg-legacy --nsg-name nsg-legacy --name allow-legacy-app
az network nsg delete --resource-group rg-legacy --name nsg-legacy

# iptables — remove application-specific rules (document before removing)
iptables -L -n --line-numbers | grep "legacy-app"
iptables -D INPUT 12    # Remove by line number after verification

# AWS EC2 — create final AMI snapshot, then terminate
aws ec2 create-image --instance-id i-0abc123def456 \
  --name "legacy-app-final-$(date +%Y%m%d)" --no-reboot

# Wait for AMI to be available
aws ec2 wait image-available --image-ids ami-0xyz789

# Terminate instances
aws ec2 terminate-instances --instance-ids i-0abc123def456 i-0def789abc012

# Azure VM — deallocate and delete
az vm deallocate --resource-group rg-legacy --name legacy-vm-1
az vm delete --resource-group rg-legacy --name legacy-vm-1 --yes

# AWS EBS — snapshot before deletion
aws ec2 create-snapshot --volume-id vol-0abc123 \
  --description "legacy-app-final-$(date +%Y%m%d)" \
  --tag-specifications 'ResourceType=snapshot,Tags=[{Key=Retention,Value=90days}]'

aws ec2 wait snapshot-completed --snapshot-ids snap-0xyz789

# Delete the volume after snapshot confirmation
aws ec2 delete-volume --volume-id vol-0abc123

# AWS S3 — empty and delete application bucket
aws s3 rm s3://legacy-app-data --recursive
aws s3 rb s3://legacy-app-data

# Azure Managed Disk — snapshot and delete
az snapshot create --resource-group rg-legacy --name legacy-disk-snap \
  --source /subscriptions/.../disks/legacy-data-disk
az disk delete --resource-group rg-legacy --name legacy-data-disk --yes

Rollback Plan Requirements

Every decommission must have a documented rollback plan. Hope is not a strategy.

Document re-provisioning procedures with estimated restore times:

Go/No-Go Decision

The Go/No-Go meeting is the final gate before execution. All four criteria must be met. A single failure triggers a postponement, not a partial proceed.

Regulatory Framework Overview

Every application handles data subject to one or more regulatory frameworks. Identify applicable frameworks before planning any data destruction.

Data Classification During Decommission

Classify all data in the decommissioned system before choosing archival or destruction methods. Different data classes have different handling requirements.

Archival Strategies

Choose the storage tier based on access frequency requirements and cost constraints. Data that must be queryable needs hot or warm storage; data retained only for compliance can go cold or offline.

Legal Hold Considerations

A legal hold (litigation hold) is a directive to preserve all potentially relevant data when litigation is reasonably anticipated. Legal holds override normal retention and deletion policies.

Secure Data Destruction (NIST 800-88)

NIST Special Publication 800-88 defines three levels of media sanitization. Choose the level based on data classification and the media's next destination.

# Linux — overwrite with random data (3-pass)
shred -vzn 3 /dev/sdX

# Linux — single-pass zero fill (faster, acceptable for most use cases)
dd if=/dev/zero of=/dev/sdX bs=4M status=progress

# Windows — SDelete (Sysinternals)
sdelete -z -p 3 D:\legacy-app-data\

# Verify overwrite (should show only zeros)
hexdump -C /dev/sdX | head -20

# Cryptographic erasure — destroy the encryption key
# (Requires data to have been encrypted at rest)
aws kms schedule-key-deletion --key-id alias/legacy-app-key --pending-window-in-days 7

# SSD Secure Erase via hdparm
hdparm --user-master u --security-set-pass DecomPW /dev/sdX
hdparm --user-master u --security-erase DecomPW /dev/sdX

# NVMe Secure Erase
nvme format /dev/nvme0n1 --ses=1    # User Data Erase
nvme format /dev/nvme0n1 --ses=2    # Cryptographic Erase

# Degaussing: use NSA/CSS EPL-listed degausser for magnetic media
# (No software command — physical device required)

# Physical destruction is performed by certified vendors
# Document the following for each piece of media:

# 1. Media serial number and type (HDD, SSD, tape, etc.)
# 2. Destruction method (shredding, disintegration, incineration)
# 3. Destruction standard met (NIST 800-88, DoD 5220.22-M)
# 4. Vendor name and certification number
# 5. Date and time of destruction
# 6. Witness name(s) and signature(s)
# 7. Certificate of destruction reference number

# Approved destruction methods by media type:
# HDD:  Shredding (cross-cut to <2mm), degaussing + shredding, incineration
# SSD:  Shredding (cross-cut to <2mm), disintegration
# Tape: Degaussing + shredding, incineration
# Optical: Shredding, incineration

Chain of Custody Documentation

Maintain an auditable chain of custody for every piece of data handled during decommissioning. This record is your proof of compliance during audits.

Retention Schedule Template

Use this template to document retention commitments for each data category in the decommissioned system. Fill in during the T-14 data handling phase.

RACI Matrix

Define clear accountability for each phase of the decommissioning lifecycle. R = Responsible (does the work), A = Accountable (makes the decision), C = Consulted (provides input), I = Informed (kept in the loop).

Communication Plan

Structured, timeline-driven communication prevents surprises and builds organizational buy-in. Every milestone has a defined audience, message, and channel.

Change Advisory Board (CAB) Process

Decommissions are changes and must go through your organization's change management process. Here is what CAB typically requires for a decommission request.

Vendor Notification

Vendor relationships require careful unwinding. Contract terms, data export obligations, and early termination penalties must all be addressed before the decommission date.

# Vendor Notification — Formal Termination Letter
# ================================================

Subject: Notice of Service Termination — [Application Name]
Date:    [Current Date]
To:      [Vendor Account Manager]
From:    [Organization Procurement Lead]
CC:      [IT Lead], [Legal Counsel], [Business Owner]

# Section 1: Termination Notice
- Reference contract number and effective date
- State intent to terminate per Section [X] of the agreement
- Specify requested termination date (minimum notice period)

# Section 2: Data Export Request
- Request complete data export in [format] by [date]
- Specify data categories to be exported
- Request written confirmation of export completeness
- Request vendor data destruction certificate post-export

# Section 3: Financial Settlement
- Request final invoice and pro-rated credits
- Address any early termination fees per contract terms
- Confirm return of any prepaid amounts

# Section 4: Transition Support
- Request continued access for [X] days post-termination
- Specify support level needed during transition
- Identify key vendor contacts for transition questions

# Section 5: Confirmation
- Request written acknowledgment within 10 business days
- Provide point of contact for vendor questions

Resistance Management

Resistance to decommissioning is natural and predictable. Users fear change, teams fear loss of control, and leaders fear disruption. Address resistance proactively with these strategies.

Executive Reporting Template

Provide leadership with a consistent, concise view of the decommissioning program. Update this report monthly or at each program milestone.

Post-Shutdown Validation Checklist

Run through every item within 5 business days of shutdown. Incomplete validation leads to orphaned resources, phantom alerts, and cost leakage that erodes the savings you just earned.

• System confirmed unreachable (ping, HTTP, DNS) Test from outside the network — internal DNS caches can mask stale records for hours
• No orphaned cloud resources (EBS volumes, snapshots, S3 buckets, IP addresses) Unattached resources continue billing silently — check every region, not just the primary
• No active network connections to decommissioned IPs Review flow logs and firewall connection tables for 48+ hours post-shutdown
• All DNS records removed and verified via external DNS Use dig or nslookup against 8.8.8.8 and 1.1.1.1 to confirm propagation
• Certificates revoked or expired Revoke immediately — do not wait for natural expiration if the system held sensitive data
• Firewall rules cleaned up Remove allow-rules referencing decommissioned IPs to reduce attack surface
• Load balancer targets deregistered Stale targets cause health check failures that pollute monitoring dashboards
• CI/CD pipelines disabled or removed Orphaned pipelines can trigger builds to non-existent infrastructure
• Monitoring and alerting removed (no phantom alerts) Phantom alerts cause alert fatigue and erode trust in the monitoring system
• Service mesh configuration cleaned (Istio VirtualServices, etc.) Stale mesh routes cause connection timeouts for upstream callers
• CMDB updated (status: Retired, retirement date recorded) If the CMDB still shows Active, the next audit will flag it as a discrepancy
• Documentation archived with DEPRECATED labels Move to an archive folder in Confluence/SharePoint — do not delete, future teams may need context
• License cancellations confirmed with vendors Contact procurement to verify cancellation — auto-renewals can silently re-activate
• Cost savings appearing in financial reports Verify in the next billing cycle — lag between shutdown and cost disappearance varies by provider

Orphaned Resource Detection

Cloud providers do not automatically clean up dependent resources when you terminate an instance. These orphans accumulate cost silently. Run these checks immediately after decommission and again 30 days later.

AWS — Find Unattached EBS Volumes

# List all unattached EBS volumes (available = not attached to any instance)
aws ec2 describe-volumes \
  --filters Name=status,Values=available \
  --query 'Volumes[*].{ID:VolumeId,Size:Size,Created:CreateTime,AZ:AvailabilityZone}' \
  --output table

# Find unused Elastic IPs (not associated with any ENI)
aws ec2 describe-addresses \
  --query 'Addresses[?AssociationId==null].{IP:PublicIp,AllocID:AllocationId}' \
  --output table

# Find stale EBS snapshots older than 90 days with no associated volume
aws ec2 describe-snapshots \
  --owner-ids self \
  --query 'Snapshots[?StartTime<=`2025-01-01`].{ID:SnapshotId,Size:VolumeSize,Start:StartTime,Desc:Description}' \
  --output table

# Find orphaned S3 buckets (empty or last modified > 90 days ago)
for bucket in $(aws s3api list-buckets --query 'Buckets[].Name' --output text); do
  count=$(aws s3api list-objects-v2 --bucket "$bucket" --max-items 1 \
    --query 'KeyCount' --output text 2>/dev/null)
  if [ "$count" = "0" ] || [ "$count" = "None" ]; then
    echo "EMPTY: $bucket"
  fi
done

Azure — Find Orphaned Resources

# Find orphaned managed disks (not attached to any VM)
az disk list \
  --query "[?managedBy==null].{Name:name,RG:resourceGroup,Size:diskSizeGb,State:diskState}" \
  --output table

# Find unused public IP addresses
az network public-ip list \
  --query "[?ipConfiguration==null].{Name:name,RG:resourceGroup,IP:ipAddress,SKU:sku.name}" \
  --output table

# Find empty resource groups (no resources inside)
for rg in $(az group list --query "[].name" --output tsv); do
  count=$(az resource list --resource-group "$rg" --query "length([])" --output tsv)
  if [ "$count" = "0" ]; then
    echo "EMPTY RG: $rg"
  fi
done

# Find orphaned network interfaces
az network nic list \
  --query "[?virtualMachine==null].{Name:name,RG:resourceGroup,PrivateIP:ipConfigurations[0].privateIpAddress}" \
  --output table

GCP — Find Orphaned Resources

# Find unattached persistent disks
gcloud compute disks list \
  --filter="NOT users:*" \
  --format="table(name,zone,sizeGb,status,lastAttachTimestamp)"

# Find unused static external IPs
gcloud compute addresses list \
  --filter="status=RESERVED" \
  --format="table(name,region,address,status)"

# Find orphaned snapshots (source disk no longer exists)
gcloud compute snapshots list \
  --format="table(name,sourceDisk,diskSizeGb,creationTimestamp)" \
  --filter="creationTimestamp<'2025-01-01'"

Cost Savings Tracking

Projected savings are promises. Realized savings are results. Track both rigorously to maintain executive trust and justify future rationalization investment.

Monthly Savings Tracker

Maintain this table for at least 12 months post-decommission. Finance should validate actuals against projections every quarter.

Lessons Learned Framework

Conduct a structured retrospective within 2 weeks of completing each decommission. Document findings in a shared knowledge base so future programs start from a stronger baseline.

Continuous Rationalization Program

One-time rationalization projects deliver short-term wins. Sustainable portfolio health requires an ongoing program with regular cadence, governance controls, and measurable outcomes.

Review Cadence

New Application Intake Governance

Rationalization is futile if new applications enter the portfolio without controls. Every new application request must pass through an approval workflow before procurement or development begins.

Shadow IT Monitoring

Shadow IT undermines every rationalization effort. Applications purchased on corporate cards, SaaS tools signed up with work email, and departmental servers running under desks all expand the portfolio invisibly. Continuous detection is essential.

# SaaS Discovery via DNS/Proxy Logs
# Aggregate unique SaaS domains from proxy logs
awk -F'[ /]' '/CONNECT/{print $5}' /var/log/squid/access.log \
  | sort -u \
  | grep -E '\.(io|com|app|cloud|dev|net)$' \
  > /tmp/saas-domains.txt

# Cross-reference discovered domains against approved catalog
comm -23 \
  <(sort /tmp/saas-domains.txt) \
  <(sort /etc/approved-saas-catalog.txt) \
  > /tmp/shadow-it-candidates.txt

echo "Shadow IT candidates found: $(wc -l < /tmp/shadow-it-candidates.txt)"

# Cloud Account Discovery
# Find AWS accounts not in the organization
aws organizations list-accounts \
  --query 'Accounts[?Status==`ACTIVE`].{ID:Id,Name:Name,Email:Email}' \
  --output table

# CASB (Cloud Access Security Broker) Integration
# Most enterprises should deploy a CASB for automated shadow IT discovery:
# - Microsoft Defender for Cloud Apps
# - Netskope
# - Palo Alto Prisma SaaS
# These integrate with SSO, proxy, and endpoint agents for real-time visibility.

KPI Dashboard

Track these metrics at the program level to demonstrate value and identify areas needing attention.

Program Maturity Model

Assess where your organization sits today and define a roadmap to the next level. Most enterprises begin at Level 1 or 2. Reaching Level 3 typically takes 12-18 months of sustained effort.