Research leads to identification of three main issues around move away from ageing digital systems
The Government Digital Service (GDS) is looking at developing a high level strategy for dealing with legacy technology throughout the public sector.
The move is part of a package of steps that it has said it needs to research in a new blogpost. They also include finding suitable case studies, identify legacy patterns and anti-patterns, and creating a community to help each other in dealing with legacy tech.
While it has not yet provided clues on any details of the strategy, it has said that it should provide more comprehensive information than it currently provides for compliance with the Digital Service Standard.
The move follows a discovery project – involving a mixture of interviews and workshops involving central and local government, the NHS and Network Rail – that identified three main issues around the move away from legacy systems.
One is that it is often hard to define what should be covered, although there are widely held views that it tends to apply to technology that is impossible to update, no longer receiving support from the supplier, presenting unsolvable problems, inherited with inadequate documentation, unable to meet current standards or no longer the most efficient option.
Difficulties
A second is that migrating is often very difficult, usually due to non-technical factors such as how to manage the data involved, who makes the decisions, where the money for the change will come from, and the fact it is tied in with the current processes and culture of an organisation.
Thirdly, there is no ‘one size fits all’ approach to migrating away from legacy tech, with organisations using looking at a combination of strategies depending on their size and the complexity of the infrastructure. A common tactic is to migrate the business away from legacy in small parts rather than all at once.
The existing advice includes an emphasis on understanding the legacy systems in use, what is possible within existing constraints, the scale of changes required and how they compare with other options for accessing data or services.
Further details include avoiding dates for migration close to the end of a contract, allowing for delays, designing the right APIs for new technology and building prototypes.
