Old systems: When to modernize, leapfrog, shut down or stay the course

The term "legacy modernization" has been around for a few years, but it seems to have gained new currency this spring. As government agencies work to consolidate both IT systems and data centers, vendors seem to have come out of the woodwork pitching different types of legacy upgrades.

That's not necessarily a bad thing. There's much work to be done as systems are migrated and retired. But IT managers need to educate themselves about various paths they might follow when faced with choices about their infrastructures.

Related coverage:

Which cloud services are you eyeing?

Without architecture, cloud is a will-o-the-wisp

When the time comes to make such choices, IT managers often find themselves asking these types of questions:

• Does our mainframe or older Unix (or other) system support our electronic government initiatives? If not, would it take a little or a lot of changes to help the system provide that support?
• Does the older system reliably provide a set of services that could be plugged into our enterprise architecture without expensive reprogramming or reconfiguring?
• If changes are necessary, should you modernize toward a services-oriented architecture or should you leapfrog to a more modern solution, including cloud-based solutions.
• Investment calculations need to be made. Some can be complex enough that you'll need the help of accountants and system planners. Some applications -- or even your full application architecture -- may need to be upgraded. At some point the investment in the old may be greater than the cost of migrating to the new.

It's never easy to know when to upgrade a system, when to leapfrog to new solutions, when to accept the status quo as "good enough" or when to accept the inevitable and shut a system down. Here are some rules of thumb. In considering them, keep in mind that every government solution is a bit different and your own systems may fall outside the basic buckets listed below.

Can modernization work?

Legacy modernization means converting a organization's legacy systems in a way that that keeps those systems useful in its current enterprise architecture.

This can include updated computer programming languages, converting software libraries, upgrading to new protocols or even migrating to a new hardware platform. The main goal is to keep and hopefully broaden the value of the legacy system investments. Sometimes legacy modernization can mean paring down the functions handled by an older system or dedicating it to a handful of high-volume application tasks or database queries.

There is a strong trend in the government market right now toward highly virtualized systems, where individual servers have a minimal identity, replaced by highly virtual environments managed by specific policies. 

Legacy systems often have business logic, presentation logic and data access logic all rolled into the same system. Modernization often separates these. If it's possible to decouple business rules from application functionality in an older system, this can help deal with one of the fundamental problems presented by the architecture of an older system.

Decoupling can place the portion of the system that's most valuable to the organization on a new upgrade path while making the solution more broadly available to other business systems via a service-oriented architecture.

Also, by moving business and policy rules to their own standalone environments, the same logic can be built once and used across multiple applications. For example, in a social services environment the rules engine might cover pre-screening, eligibility, entitlement and other applications, thus enhancing the ability of multiple legacy systems to be dedicated to things such as data management or detecting improper payments. 

Look before leapfrogging

Leapfrogging simply means avoiding the entanglements of legacy migration and upgrades by moving toward a totally new solution. Here's a great example: Many lesser developed countries never built large telephone networks. When some of those countries decided to make investments in their communication systems, they jumped right to cell phone networks, electing not to invest in landline networks.

Government agencies need to calculate whether this is the right time for a similar approach. Rather than upgrading servers and software, is this the right time to move toward cloud-based solutions? Legacy systems may have an entanglement of e-mail servers that link to case management systems and applications that track annual filings. It may be tough to get single pieces of those solutions from the cloud. But if a service provider was able too offer all three in an integrated package, then leapfrogging your system upgrades might be the logical choice.

The shutdown of a system may be done for a number of reasons. It may be because leapfrogging to a cloud solution was productive, or because legacy modernization recruited parts of your legacy system for new assignments. These days it can also mean that a system's functions are now supported as multiple discreet pieces via a larger SOA, with database, business logic, application logic and presentation all handled by component systems that each have their own long-term upgrade path.

The status quo is often the lingering choice, simply because funding for long-term change is not available. As mentioned above, status quo often means "good enough." If the system functions well, it can be nursed along for a few more years. But in the realm of cloud and SOA, it also may mean that a legacy system will spend its final months providing its functions while managers do their ROI analysis and decide if the end will mean migrating or leapfrogging. 

If the legacy system can't be converted into a component for a larger set of IT services, its days will indeed be numbered.