Skip to content

Delivery Kit: Technology Reduction

This kit defines the shared data model and the templates used to deliver the engagement. Do not duplicate fields; all templates render from the Common Data Model.


1. Common Data Model

Every item evaluated during the engagement is stored as a Reduction Candidate Record with the following schema:

ITEM: [Name/Identifier]
BUSINESS_PURPOSE: [What business outcome does this serve?]
CURRENT_OWNER: [Team/Person responsible]
WHO_USES_IT: [Stakeholders/Systems]
WHY_IT_WAS_BUILT: [Historical context]
CURRENT_MAINTENANCE: [Estimated annual burden]
CREDENTIALS_OR_ACCESS: [Associated secrets/permissions]
UPGRADE_IMPACT: [Friction caused during updates]
SECURITY_IMPACT: [Surface area/Risk]
KEY_PERSON_DEPENDENCY: [Yes/No/Details]
EXISTING_PLATFORM_REPLACEMENT: [Native alternative]
REPLACEMENT_MATURITY: [Is the native feature proven?]
REPLACEMENT_EVIDENCE: [Docs/Examples]
REMOVAL_DIFFICULTY: [High/Med/Low]
REMOVAL_RISK: [High/Med/Low]
VERDICT: [KEEP | RETIRE | REPLACE | CONSOLIDATE | INVESTIGATE]

2. Maintenance Review Method

Objective: Answer "What are we maintaining that we don't need anymore?"

Process: 1. Execute discovery across the defined scope. 2. Populate the Common Data Model for every custom system, script, or integration found. 3. Classify each item with a VERDICT.


3. Deletion Plan Template

Objective: Drive customer decisions on items marked for action.

Structure (For each item): * CURRENT_THING: * WHY_IT_EXISTS: * WHAT_REPLACES_IT: * WHY_REPLACEMENT_IS_PREFERRED: * CURRENT_ANNUAL_BURDEN: * REMOVAL_EFFORT: * REMOVAL_RISK: * SECURITY_SURFACE_REMOVED: * CREDENTIALS_CLOSED: * UPGRADE_TESTING_REMOVED: * ROLLBACK_PATH: * CUSTOMER_APPROVAL: [Pending/Approved/Rejected] * STATUS: [NOW | NEXT | LATER | KEEP]


4. Safe Removal Playbook

Objective: A repeatable delivery playbook to safely remove the technology.

Steps: 1. Establish baseline performance/behavior. 2. Configure existing replacement natively. 3. Run old and new side by side. 4. Compare required business outcomes. 5. Document differences. 6. Obtain customer approval for cutover. 7. Switch old implementation off. 8. Retain bounded rollback capability (Default: 30 days). 9. Verify production behavior. 10. Revoke old credentials/access. 11. Remove old implementation source/infrastructure after rollback period expires. 12. Record the ownership removed.


5. Verification Contract Template

Objective: Prove that the outcome works with less machinery.

Structure: * BEFORE: * AFTER: * BUSINESS_OUTCOME: * FUNCTIONAL_EQUIVALENCE: [Yes/No] * KNOWN_DIFFERENCES: * CUSTOMER_ACCEPTANCE: [Sign-off] * ROLLBACK_TEST: [Passed] * PRODUCTION_READBACK: [Stable] * OLD_CREDENTIALS_REVOKED: [Yes/No] * OLD_RUNTIME_DISABLED: [Yes/No] * OLD_SOURCE_RETIRED: [Yes/No] * DOCUMENTATION_UPDATED: [Yes/No]

  • FINAL_VERDICT: [PASS | FAIL | ROLLED_BACK]

6. Maintenance Watch Template

Objective: A short quarterly deliverable (max 2 pages) to prevent complexity regression.

LIST 1: WHAT CAN YOU STOP MAINTAINING NOW?

(For each newly redundant item) * NEW_PLATFORM_CAPABILITY: * CURRENT_CUSTOM_IMPLEMENTATION: * WHY_IT_MAY_NOW_BE_REDUNDANT: * RECOMMENDED_ACTION:

LIST 2: WHAT ARE YOU ABOUT TO BUILD THAT YOU SHOULDN'T?

(For each proposed custom work caught in review) * PROPOSED_CUSTOM_WORK: * EXISTING_CAPABILITY: * DUPLICATION_RISK: * RECOMMENDED_ACTION:


7. Demonstration Example

Scenario: A company has a custom Slack approval integration for deployments created 5 years ago. The current platform (GitLab) now provides native approval environments.

Data Model / Review: * ITEM: Custom Node.js Slack Approval Bot * BUSINESS_PURPOSE: Approves production deployments. * CURRENT_OWNER: DevOps Team * WHY_IT_WAS_BUILT: GitLab didn't have environment approvals in 2021. * EXISTING_PLATFORM_REPLACEMENT: GitLab Protected Environments & Native Slack Integration. * VERDICT: REPLACE

Deletion Plan / Removal: * CURRENT_ANNUAL_BURDEN: ~40 hours (Node updates, server patching, Slack API changes). * REMOVAL_RISK: Low. * CREDENTIALS_CLOSED: 2 (Slack Bot Token, GitLab PAT). * ROLLBACK_PATH: Keep Node app disabled but intact for 30 days.

Side-by-Side Proof & Cutover: * Configured GitLab native approvals on staging. Verified Slack notifications and approval gates work equivalently. * Customer approved. Disabled Node.js bot. * 30-day window passed with no issues. * Final Result: Node.js server decommissioned, repository archived, tokens revoked. * ANNUAL_BURDEN_REMOVED: 40 hours + 1 server instance.