Resources · 105
Retiring a digital service: remaining needs, data and handover
Organise closure without abandoning ongoing cases, users or retention responsibilities.
· 2 min
What this guide helps achieve
- Qualify remaining needs
- Resolve open cases
- Prepare data
- Inform and test handovers
- Close dependencies
Quick check
- Is closing the interface enough?
- Should everything be retained?
Step-by-step method
- 01
Qualify remaining needs
Separate disappearance of need, service replacement and transfer to another organisation. Inventory direct users, API integrations and people supported offline.
Deliverable: populations and remaining needs.
- 02
Resolve open cases
List orders, requests, disputes and deferred processing. Give each an outcome, owner and post-closure contact; disabling a screen does not close a case.
Deliverable: ongoing-case register.
- 03
Prepare data
Classify what should be transferred, exported, retained or deleted under applicable rules. Test export readability and evidence access; avoid an ownerless complete archive.
Deliverable: decisions for each dataset.
- 04
Inform and test handovers
Explain changes and next steps in needed languages. Check older links, contact details, support and integrations; test replacement with people having different needs.
Deliverable: communication and transition acceptance.
- 05
Close dependencies
After validation, retire scheduled work and unnecessary access under the authorised plan. Retain owners for domains, archives and residual contacts; inspect access attempts after closure.
Deliverable: closure evidence and residual monitoring.
Close without leaving ownerless responsibilities
Check the observed state before choosing next steps.
Case still open
Assign outcome, owner and contact.
Need handled elsewhere
Test handover with affected people.
Data retained
Name an owner and retention rule.
Reusable worksheet
Complete with your authorised observations. These fields are a working template, not observed results.
| Field | Information to record |
|---|---|
| Population | Uses, handover and contact |
| Case | Outcome, owner and evidence |
| Data | Destination, access and retention |
Worked example
Illustrative situation
Illustrative case: a portal disappears while requests are still being processed and an integration still receives events.
Decision and expected evidence
Retain a contact for cases, inform integrators and separately confirm cessation of deferred processing.
Distinguish the mechanisms
| Mechanism | Purpose | Check or limitation |
|---|---|---|
| Replacement | Need handled elsewhere | Test access and transfer |
| No successor | Need not taken over | Explain limits and resolve cases |
| Archive | Necessary retention | Assign access and expiry |
Management indicators
| Indicator | What it measures | First action |
|---|---|---|
| Open cases | Cases without assigned resolution | Handle orphan cases |
| Dependencies | Components with closure decisions | Check forgotten work |
Common pitfalls
- Confuse screen closure with case resolution
- Leave an ownerless archive
- Forget users receiving offline support
Frequently asked questions
Is closing the interface enough?
No. Processing, integrations, data or requests can remain active. Verify these dependencies separately.
Should everything be retained?
No. Apply rules for the datasets and actual obligations; avoid an assumed uniform period.
Official references
References consulted: . The method and worksheet propose checks to adapt to your context; they do not constitute certification.
Continue exploring
Related analysis
