Closing down your digital service

Closing down an application, platform or technology ecosystem is a natural part of its lifecycle.

When closing a digital service, you should consider user needs in the same way you did when building it. Plan carefully to reduce disruption and make sure users know what to do next.

Closing down a service is sometimes referred to as ‘retiring’ or ‘sunsetting’ a service.

Understand why the service is closing

A service may need to close because:

• users no longer need it
• a new service will replace it
• a different team or organisation will take it over

Before making a decision, talk to technical teams and stakeholders to explore your options.

You may need to write a report to document your findings. Clearly define the reasons why the service is closing. For example, it might be to:

• reduce costs
• improve performance
• free up resources
• move to another organisation

Check what other systems rely on the service. List any connected applications, databases, or technologies.

Consult the people affected

Talk to users, stakeholders, and partner organisations to understand how the closure will affect them. Other people affected might be:

• technical teams
• external partners
• government teams and ministers

If another service or organisation will take over, work with them to make sure users have clear guidance on where to go next.

If the service is shutting down completely, explain what is happening and why.

Users who rely on assisted digital support may need extra help. Work with support organisations and use appropriate communication channels to make sure they understand the changes.

If another team or organisation takes over

If another team or organisation will take over the service, work with them to share knowledge and support users through the transition.

Provide documentation on:

• how the service works
• past user research
• any known issues

If possible, arrange a transition period where both teams work together before the handover.

Create a timeline

Once you decide to close the service, set a clear timeline for the process. Plan important steps, including when to notify users, set up redirects, and shut down the service.

Your plan should cover:

• whether you will fully or partially close the service
• key steps like designing new processes, migrating data, and training users
• who is responsible for each stage

Plan how to communicate the closure

Plan how you will inform users and stakeholders about the closure. Decide:

• what information different user groups need
• how and when to communicate updates
• if training or support is needed to help users with the change

Work with user research teams or look at previous service closures to find the most effective communication methods. Examples of different methods are:

• in-service notifications
• emails and letters
• website and social media updates
• physical notices in places like public offices or transport hubs

Notify users and stakeholders

Users need clear, timely information about:

• what is changing and why
• what they need to do
• what will happen to their data

If users access the service directly, tell them through notifications, web pages, or other relevant channels.

If users rely on APIs (which let different software applications communicate, such as Google Maps displaying locations), give them enough time to update their systems. Contact API users early, as some may need long lead times.

If the service is listed on a government website, update or remove links. If it has a public-facing page, work with content teams to ensure users are redirected to the correct place.

Redirect users to the right place

Some users will still try to access the old service after it closes. Manage this by:

• updating or removing links on government websites and other platforms
• keeping the web address active with a redirect for a set period
• ensuring error messages explain what has happened and where users should go

If the service has been live for a long time, consider keeping the redirect for at least a year.

Keep SSL security certificates running during the transition period to maintain security. These certificates ensure that URLs starting with https:// remain encrypted, protecting user data.

Manage user data

Follow data protection rules to make sure user data is handled properly. You may need to:

• retain, archive or securely delete information
• make sure you comply with legal and organisational policies
• tell users what will happen to their data

If another organisation is taking over the service, make sure data transfers follow legal and security guidelines.

Decide what data to transfer, how to format it, and where to store it securely.

Make sure data integrity and accuracy are maintained throughout the process.

Test new processes and systems

Before shutting down the service, carry out testing to ensure:

• new processes meet requirements
• security risks are addressed
• users can successfully transition

Use functionality testing, security testing, and user acceptance testing before proceeding.

Decommission the service

Once all data has been migrated and users have moved, decommission the service. This includes:

• securely deleting or archiving data (following organisational policies)
• making sure backups are in place
• testing to confirm that no residual data or access remains

Review what you have learned

After closing the service, document lessons learned and share them with other teams. This will help improve future service development.

Even after closure, monitor new processes for any issues. Provide ongoing support to address user questions and concerns.

Finally, document the entire process. This includes:

• challenges faced
• lessons learned
• recommendations for future service closures