The upgrade of legacy systems in public administration is not just an issue of upgrading software but a problem of maintaining service continuity. The key point of the process is improving the technologies without stopping the processes of making decisions, making payments, keeping records, and providing services.
Why is modernizing public-sector legacy systems so difficult?
The problem is the separation between the technology that is being replaced and the civic duties it serves. The organization needs to know what changes will be necessary, what duties must still be served, and how to show that the new system works before discarding the old one.
In evaluating tribal government software, the assessment should specifically include the government’s governance duties and control over its information. The same service-oriented approach should be taken by all other public organizations. Define the decision-making, access, and operating conditions before designing an architecture.
One such guide is the Application Rationalization Playbook of the Federal CIO Council, which recognizes the difference between business value and technical fit, takes into account the factors of dependencies and interoperability in technical assessment, and suggests taking security risk and total ownership costs into consideration.
It will be helpful in ensuring that one does not consider age alone as the criterion for replacement and selects first a service that has vulnerabilities which expose the operations to unacceptable risks.
Map the service before selecting the replacement
Take, for example, a hypothetical permit office. Reworking the application form will have little impact if the information used for reviewing applications is still inaccessible, and payments cannot be reconciled by financial clerks. The modernization boundary should be established from the standpoint of the entire transaction process, including exceptions, rather than the most obvious computer screen.
Get frontline employees to go through routine transactions, disputes, changes, and breaks in processes. Document where information comes from, who is able to modify it, and what follows from it. Treat undocumented shortcuts as discoveries that require investigation.
Construct a service map that can answer four practical questions:
- Inputs: What documentation is required in order to initiate and finalize a transaction?
- Decisions: Who has the power to authorize, reject, amend, or elevate a case?
- Dependencies: Which systems will share data, and what should happen in case of failure?
- Evidence: Which documents need to be retained and accessible in order for staff to provide an explanation about the outcome?
Develop acceptance criteria using your service map. “The new system imports historical records” is less powerful than requiring staff to find an old case, interpret its status, and understand the reasoning behind it.
Treat legacy system migration as a controlled handover
Focus your legacy system migration process on the transfer of ownership rather than on the mere transfer of data. Identify owners for each data set and figure out how you will manage issues of conflicting values, absent fields, duplicate records, and historical codes. Preserve the uncertainty where necessary rather than silently turning the uncertain record into a certain one.
Set the migration boundary only after verifying its dependencies, and ensure that the staff has the capability to perform the entire service within that boundary. A small release is helpful only when it provides information about operational readiness.
Before delegating the role to the successor, a formal handover should take place:
- Compare records: Check numbers, sums, relations, and sample cases, with named owners of any differences.
- Check services output: Let the employees handle the normal and exceptional cases on test data that should be sufficiently protected.
- Run recovery: Determine conditions under which the recovery will be run, decision-making, reporting, and reconciling transactions formed during the downtime.
- Approve retirement conditions: Clarify the requirements for saving, removing dependencies, and shutting down.
The attention paid to retiring is necessary in the planning from the very beginning. According to the GAO, milestones, modernization descriptions, and legacy system disposal are critical components of the planning process. The findings also show the problems with legacy systems, such as outdated languages, unsupported technologies, and security risks.
Make funding and ownership follow the service
Organize funding requests around the service increment you are going to deliver and the infrastructure necessary to run it. Include discovery, data preparation, testing, training, parallel running, and decommissioning activities in your proposed scope; otherwise, the funding may cover the delivery of the replacement but not the transfer required to be able to use it.
Define a service owner responsible for finding the balance between conflicting demands in technology, operations, finances, and records management. Make sure this person has defined escalation paths instead of relying on cooperation between departments to sort out all issues. The procurement criteria must also provide for such accountability in terms of testable results, data export, documentation, and acceptance.
Protect people's time for involvement. Ask managers to assign resources for testing and learning, not just add these responsibilities to the current workload. Make readiness part of delivery, not an announcement activity.
How should agencies evaluate the ROI of legacy system modernization?
The return on investment from legacy systems upgrades can be determined by comparing the total cost of change against the financial value of the gains made, while recording gains in service and reductions in risk separately. Create a baseline prior to the implementation and determine the person responsible for proving the validity of each gain.
Record measurements like expenditures on maintenance, effort spent on processes, rework, reliability of service, and time required to make the implemented change. Determine whether the cost savings are purely cash savings or just the capacity freed up for other activities. Capture any cost savings that are tied to the shutdown of the old system and do not consider them until the costs cease.
Modernize the service, not just the stack
Any good modernization strategy should explain how public works will be continued during the entire process. Service boundary definitions, revealing any dependencies, running a test takeover, and aligning investments with real results are necessary steps here. And the best possible ending is not the declaration of the new product’s release, but the successful replacement of the old one.
