Moving away from legacy systems
Government uses a lot of older technology that’s tied into costly contracts and it’s likely that your organisation will too.
These technologies, known as legacy systems, can make it hard for you to build a service that brings about real change because:
- it takes time and effort to move away from them
- they do not support real-time queries and changes
- they’re expensive to license and difficult to work with
Before you begin
Before planning to replace legacy systems, you should try to understand:
- the legacy systems your service will need to interact with
- what’s possible within the tech constraints you have
- the scale of any changes that are required and how they compare with other options you have to access the data or services
For example, the team running the Visit someone in prison service worked out a way to provide a good user experience without integrating with the main backend system.
This lets the team provide outcomes for users first and then tackle the backend problem to make things even better.
Talk to other teams
In many cases legacy technology will be subject to other change programmes and you’ll need to coordinate with other teams to have a clear plan.
This is one reason it’s important that your department has a clear joined-up digital, technology and change portfolio.
Make the new technology as flexible as possible
Even if you can find ways to meet initial user needs without directly tackling inflexibility in the underlying technology, it’s important to make sure that you deal with that inflexibility at some point.
Workarounds quickly add up and lead to more complexity, making it still harder to change.
Examine your organisation’s processes
You should use the changeover to take a fresh look at your organisation’s processes.
Start by learning user needs - do not just re-create the same system with new technology.
Make sure your team has the skills you need
Whether you decide to replace legacy technology or make changes to introduce new flexibility, your team needs contractual information, commercial and legal expertise and technical knowledge.
Planning the changeover
Follow these steps to make a plan for replacing legacy systems
- Agree a plan with your stakeholders.
- Set a date for the changeover.
- Allow for delays.
- Avoid dates that are close to the end of a contract.
Agree a plan with your stakeholders
You need to agree a plan with the people that’ll be affected by the changes and those who’ll have to support the new system.
Involve all stakeholders and make sure the person or agency funding your project agrees with your plan.
Set a date for the changeover
When replacing an old system, you should pick a date to turn it off and make sure that all your stakeholders agree to that date.
If you do not set a date and get stakeholder support, you may find that people avoid the final changeover or that they renew contracts with legacy technology suppliers.
This can increase the complexity of your contracts and your architecture, making it even harder to change in future.
Allow for delays
You can allow for a month or two of delays when you pick the date, but make sure you do not allow such a delay that your deadlines no longer have any motivating effect on your team or stakeholders.
Avoid dates that are close to the end of a contract
Do not pick a changeover time that’s too close to the date a legacy contract or licence is due to run out. Otherwise if the new system is delayed, you may find you have no choice but to renew the old contract.
Making the changeover
Follow these steps to make the changeover:
- Choose new technology.
- Design the right APIs.
Choose new technology
There are many ways to stop using legacy systems but most involve choosing new technology and making it work.
It can be difficult to pick the right technology for your users’ needs and to be sure that it’ll work alongside other systems you use.
You should build prototypes to test that your chosen technology can do the job, then make an initial plan for the rest of its development based on regular feedback from stakeholders and users.
It’s also important to build something that’s realistic and not just a simple model. By building a realistic prototype, you can test your technology under lifelike conditions and any feedback you get will be much more practical.
Design the right APIs
APIs are the way that components talk to each other. Whether you’re changing existing technology or replacing it with something else, it’s important to create the right APIs and test that they provide the information and operations you need.
A common option is the strangler pattern, where we initially introduce the API we want as a wrapper around the legacy system and can then replace the legacy system independently of our new code.
Over time you may want to employ a reverse of the strangler pattern. If you have further systems dependent on your legacy technology (and you often will) you can provide new wrappers that present the old interface to them while you migrate them to work with the new system.
Read a Government Digital Service blog post about APIs.
Reducing dependencies
You may need to write temporary code (known as ‘wrapper code’) to get the functionality you need without making immediate changes that might affect other government agencies or parts of your organisation which use your old system.
It’s common, at first, to develop wrapper code that provides a new REST API for the old system that you can design your new code around.
With careful use of these wrappers you can control the pace at which you move from old technology to new with minimal impact on other teams.
This process also allows you to run so-called ‘dark launch’ testing which means you can send queries to the new API. The answer to the query will then be discarded, compared to the old API to make sure it’s correct, or used for load and resilience testing.
You can remove the wrapper code once all systems and government departments have migrated to the new system.
You can also use similar techniques in other areas of your migration so that your changeover stays manageable.
Related guides
You can read further guidance on managing legacy technology.
You may also find the Working with open standards guide useful.
- Last update:
-
Guidance first published