Language selection

Françaisfr

Search

Sign in

Legacy Information Technology in the Public Service

Digital Transformation•11-01-2023

Legacy information technology (IT) refers to outdated software and hardware that is no longer supported by its manufacturer. In the federal public service, legacy IT systems continue to play an important role in day-to-day operations. These outdated systems, however, pose many challenges, including security vulnerabilities, obsolescence issues, and growing costs, which can lead to system failures if not addressed promptly.

Why do we need to address legacy IT at all?

Unmanaged scale: The ability to scale legacy systems up or down is often forgotten. As a result, legacy systems often find themselves in either of these two states: overwhelmed or overprovisioned. When a legacy system takes on more users than it can effectively endure, it gets overwhelmed, running out of processing time, network speed, or storage space. When a legacy system has the capacity for more users than necessary, it is overprovisioned.
Abandoned defences: No IT system is built using just in-house technology. Programming languages, operating systems, and even physical hardware are necessarily acquired from outside the public service. The lifecycle of every product includes an end date. Once that end date has passed, companies typically stop providing product support, such as fixing security issues and fixing bugs.
Frozen costing models: As technology progresses, computing resources become more powerful, more efficient, and less expensive. For example, cloud computing services are paid for when they are used. This is much more cost effective than traditional servers that run 24 hours a day, 7 days a week. Unfortunately, legacy IT systems must be re-engineered to take advantage of the cloud model. Moving unmodified legacy systems into a cloud provider can sometimes cost even more than self-hosting.

Where does legacy IT come from?

1980s style office interior with vintage computers, desks and plants.

In large, long-standing organizations (like governments), software systems that have the longest lives tend to be the most central to the organization’s core business. Because they exist for so long, these systems take on characteristics that make them more necessary and more difficult to replace.

Organizational lore: Legacy IT systems accumulate functions with backstories and rationales that are lost as staff leave or move. For instance, a policy change or an executive request might have the development team make changes—often workarounds—in the supporting IT system. Over time, these functions become part of “just how it is” in an organization, and employees are unable to distinguish the necessary from the irrelevant.
Endangered expertise: As time moves on, so do the experts who work with any technology. Whether they retire or move onto something new, the talent pool with knowledge and experience in an established technology generally shrinks.
“If it ain’t broke…”: Performance metrics for IT service managers are often tied to the stability and availability of their services. Therefore, resources tend to focus on maintaining the current state of a service. Efforts to update the platform are seen as a risk rather than an investment. This, in addition to competing priorities and resource constraints, will shift any long-term investment to the back burner.

What not to do with legacy IT systems

Technology industry leaders should now be well-versed in the nature of legacy IT systems. A seasoned technologist will have seen enough legacy integrations and migrations that they’ll wince at the thought of doing one. The following common knee-jerk reactions to legacy technology are not recommended.

Burn it down and start over: Understanding the inner workings of a legacy system can seem daunting, and one of the most common reactions is to start from scratch. This is not recommended for two reasons. First, the legacy system will still need to be maintained while the replacement system is in development. This leads to duplicate effort. Second, once the legacy system is set aside, some of the unexpressed functional requirements encoded within it may be lost.
Lift-and-shift: When offering a new platform or model, vendors will often provide a mechanism to run older technologies on the newer platform or model—usually through virtualization or emulation. Be very careful when looking at these options, as the compatibility mechanism can often offset the benefits of the new platform.
Often, this means transferring a traditional application to the cloud. To do this, you will need to purchase a virtual machine to replace the physical hardware used to host the application. Operating a virtual machine 24/7 can cost many times more than the original hardware.
Put it in a glass box: Because of the security risks with keeping a legacy system online, it can be tempting to move it to an isolated network and provide access through a remote-access solution. This is not recommended. If you isolate the service from migration efforts, expertise and functional requirements will likely be lost over time. Doing this will also increase the eventual cost of migration and, in the meantime, worsen the user experience when accessing the service.

What you can do

Managing legacy IT systems can be a real challenge. Those responsible for the migration away from these systems are rarely those who originally implemented them. Here are some concrete actions that organizations can take to get their legacy IT under control.

Nail down quality: Tools like screen-scrapers, browser automation, and robotic process automation can be used to make tasks run automatically. Think of it like having a robot that helps you check if an older computer system always behaves the way it should and helps you understand how it behaves.
Your quality assurance team might call this procedure automated system testing. It's a method usually used when creating software internally, but it can also be used for older computer systems. Don't worry if you can't figure out every little detail right away. Start by looking at the basic things, like turning the system on and off, before looking at the more specific actions. These routines are like regular check-ups for your computer system to make sure it's healthy.
If your older system is made up of smaller subsystems that you can access, like a database server, think about doing another set of automatic checks, which quality assurance teams call "integration tests." These checks can confirm if all the inside parts of your system are working correctly. They can also help make a clear list of what the old system really does, which might not be the same as what the people who use or take care of it think it does.
Make the elephant in the room easier to accept: Legacy technology is part of technical debt—the accumulated cost of deferring full investment into fixing or reworking an IT system. Technical debt doesn’t appear on an organization’s balance sheets and can be challenging to bring to light. Often, the most palatable way to discuss legacy IT is through the lens of risk management.
No half-measures: Addressing legacy systems should be treated as a project and not just something to do off the side of your desk. Resources should be formally assigned to the effort, with metrics and targets. Legacy IT migration projects often experience surprises midstream. Time and resource buffers should be allocated with this in mind.

How you can do it

Graphic depicting the migration of data to the cloud infrastructure.

When the time comes to migrate away from a legacy system, there are a lot of technology and planning techniques that can help ease the process.

Seek help: Your organization is not alone in dealing with legacy systems. Reach out to other organizations that have rolled out successors to the same (or similar) legacy systems and ask about their experiences. These conversations can sometimes be uncomfortable, so reassure them that their experiences are not being judged.
Wrap with a standard: Often, systems that exist past the end of their lifetime are replaced by systems that implement some kind of interoperability standard. If you have access to the inside of your legacy system, there are opportunities to ease the transition away from using it. You can do this by procuring or creating a wrapper that lets you access the legacy system in a standard way while the migration takes place. A wrapper is a software that makes it possible to connect to an old or nonstandard service using a standard protocol, such as the HDMI add-on you can buy to connect your old Nintendo video game console to a high-definition smart TV. If your migration includes moving content out of a legacy system, make sure that it is in a standard format and that it can be used without the legacy system.
Break up the monolith: Long-lived systems tend to get big, and moving away from them is often too large a step to take all at once. However, there are many ways to divide the system into discrete “chunks.” The simplest option is to break the migration up by organizational unit, moving discrete teams of users across one at a time. Another option is to break the migration up by time period, to be actioned in a certain order. First, you dispose of the legacy content. Then, you freeze the legacy system as you switch users to the new system. Finally, you migrate the active files in the legacy system over to the new system before decommissioning the legacy system.

The cleanest, most ambitious option is to break the migration up by “layer.” Software systems are typically broken up into layers, each taking care of a particular job. If your legacy solution has distinct components with well-defined interactions, you can replace the layers one at a time. Your users won’t experience any impact until you make changes to the user interface.

When breaking up a migration, you need to make sure that the work chunks are not dependent on one another. For example, you can’t break up your migration by time if your current content links to content will soon be disposed of.

How to get ahead of legacy IT

Whew! So, legacy IT is big and complicated, and it’s something we should try to avoid accumulating. The key is to identify and take control of the technology we use before it falls out of support. Below are some ways you can do this.

Performing regular check-ups: Take a look at the systems you use on a regular basis and identify their support timelines. For solutions that are open-source, in-house, or customized, look beyond the first layer. What does the solution depend on and who supports it? Your IT team will have a practice called application portfolio management. It comes with the relevant tools to perform check-ups.

Note that software as a service solutions are prone to having short support timelines. When vendors end support for a product, that end typically comes very quickly with minimal and short notice.
Expanding your vision: Add maintenance metrics to how you report on the performance of your solutions. Metrics like “days since last supported upgrade” and “days remaining until (or since) end of support” are just as important as uptime and response time.
Keeping your eyes on the horizon: If your business line depends on a technology solution (and let’s face it, we all do), you should have some idea of what the future holds. Be curious. Reach out to your technology colleagues and start a conversation.
Reassessing system suitability for users: Once a legacy IT system is built, they’re often treated as complete. However, as business practices and requirements evolve over time, the system may no longer fit users’ needs. This typically manifests as users exporting information to an Excel spreadsheet and doing manual work there. Reach out to colleagues who interact with the legacy IT system to reassess the system’s suitability for their needs.

Before you go, some food for thought

What is the oldest technology you use on a regular basis?
Who do you depend on to maintain your work tools?
What new tool is your organization adopting, and, in response, how will you adapt your work?