Skip to content

Phase 4: Sunset & migrate

When to use: any time the company retires an AI tool, a framework practice, or a vendor. Sunset is not failure; it is inevitable given the pace of change in this space.

What sunset includes

  • Tool deprecation (vendor EOL, end of contract, poor performance, regulatory change).
  • Practice retirement (a framework component superseded by a better one).
  • Vendor change (Copilot → Cursor, Cursor → Claude Code, etc.).
  • Model upgrade requiring changes to existing prompts, agents, or integrations.

Outputs

  • Migration plan: target state, cut-over date, rollback plan.
  • Evidence continuity plan. Where the audit trail from the old tool lives after it's decommissioned, and for how long.
  • Communication plan: who is told, when, how.
  • Retrospective. What the retirement taught us.
  • Decision Record: rationale, alternatives, who signed off.

The five moves

1. Document why, now (week 1)

Before anything changes, write down:

  • What is being retired?
  • Why? (Technical, contractual, regulatory, cost, performance.)
  • What is the replacement, if any?
  • What's the deadline, and what's driving it?

This document is the anchor for every subsequent decision.

2. Map dependencies (week 1–3)

What uses the thing being retired?

  • Users, teams, business units.
  • Repositories with integrations (CI/CD, IDE plugins, agents).
  • Prompt library entries pinned to the tool.
  • Training materials.
  • Runbooks and IR playbooks that reference it.
  • Audit evidence referencing it.

A tool that looked isolated rarely is.

3. Plan cut-over and rollback (week 2–4)

  • Cut-over: waves, similar to Phase 2 scale but in reverse. Start with the teams most able to tolerate disruption.
  • Rollback: what would trigger one, and what does it look like? If rollback is "impossible," treat that as a risk to escalate to the exec sponsor.
  • Data preservation: export audit logs, usage history, contract artifacts. Store per your retention policy.

4. Communicate (week 3–6)

  • Upstream. Notify the exec sponsor, CISO, Legal, Procurement.
  • Sideways. Notify other CoEs or platform teams who interact with the tool.
  • Downstream. Notify every engineer and every team using the tool, with dates and support channels.
  • External. If customers or regulators need to know (for regulated industries, often yes), the comms plan must include them.

5. Retire, retrospect, record (week 4–12)

  • Decommission on the planned date.
  • Hold a retrospective within two weeks.
  • Write the Decision Record: what was retired, why, what replaced it, what it cost, what we learned.
  • Post a changelog entry on the public site.

Evidence continuity

Even though the tool is gone, the audit trail it produced likely still has retention requirements. Before decommission:

  • Export logs to the organization's central logging system.
  • Index exports with a label identifying the retired tool and the dates it was in use.
  • Update the IR playbook to describe how to retrieve historical evidence.
  • Note in the Regulatory crosswalk that the controls previously attested via this tool are now attested via its successor (or replaced by compensating controls).

Anti-patterns

Don't

  • Don't decommission without an evidence export. Audit trails are often required for years beyond the tool's life.
  • Don't leave prompt-library entries pinned to the retired tool. Mark them retired; users will hit them otherwise.
  • Don't treat a vendor change as "we just flip a switch." Prompts, workflows, and habits that developed around tool A rarely translate to tool B without retraining.
  • Don't skip the Decision Record because "it's just a retirement." Retirements are exactly when rationale matters most; future teams will ask why.

Next

After retirement is complete, you're back in Phase 3. If the retirement was large enough to change the shape of the program (e.g., adopting a very different tool class), consider looping through a short Phase 0: Readiness pass on just the affected scope.