We are replacing an old service. When can we switch it off?

Unverified retirement readiness

Confirm that required users, records, integrations, and support responsibilities have moved or have an approved alternative. Consider retention, access, communication, and recovery requirements with the appropriate owners. Retire the service through a documented decision, not merely because the replacement launched.

What to do now

Inventory remaining users data and dependencies
Verify migration and required retention arrangements
Communicate the retirement and support plan
Authorize shutdown and verify the result

Recommended action flow for unverified retirement readiness: Inventory remaining users data and dependencies then Verify migration and required retention arrangements then Communicate the retirement and support plan then Authorize shutdown and verify the result. Escalate when a critical dependency or required record still relies on the old service.

When to escalate

Escalate when

A critical dependency or required record still relies on the old service.

Who decides

The service owner and authorized operational decision maker

Example

A legacy portal remains read-only until record access and downstream exports are verified.

Mistake to avoid

Deleting the old environment immediately after the new launch announcement.

Prevent a repeat

Test whether receiving teams can operate and recover the service without depending on informal project-team support.

Suggested ApprovedFlow setup

Tasks
Documents
Approvals

Keep handover tasks, operating evidence and the acceptance decision linked to the project while retaining monitoring and incident control in the actual service tools. See the platform