Subscribe to the Free Print Edition!
Celebrating 25 Years

GCN Home > April 2, 2001 issue

Legacy-to-Web tools put your data in place

BY JOHN MCCORMICK | SPECIAL TO GCN

Migrating legacy systems to the Web can be like transplanting a tree. Only when you try it do you find out how deep and in how many directions the roots run.

Most agencies have a variety of legacy data and applications, found on platforms ranging from old IBM 360s to modern minicomputers. It’s not possible to convert everything at once, so the first challenge managers often face is deciding which data and applications should go online first. Unlike gardeners, network managers don’t have to move the whole thing at once.

The year 2000 triage, which everyone went through to decide which systems and data got upgrade priority, can be used as a starting point in prioritizing this legacy-to-Web conversion effort, with some important exceptions:

  • The way agencies prioritized mission-critical work that had to continue right through midnight Jan. 1, 2000, might not be the approach you want to take in migrating legacy systems to the Web or an intranet.


  • High-priority data destined for enterprisewide accessibility might already have been converted to a modern system during year 2000 work and probably will be the easiest to move onto a TCP/IP network.


    •
  • Pay careful attention to old data that did not get year 2000 priority because it was not deemed mission-critical. It’s difficult, if not impossible, to know what legacy data will be important 20 years from now, so don’t leave behind data tapes that are unreadable or drives that can’t be repaired.


 Most familiar legacy-to-Web tools are middleware products that actively manage the conversion of input and output between old applications running on old hardware and new Web-enabled front ends. In deciding whether to use middleware tools or to rewrite the code in a Web-friendly language, your primary consideration often is how intelligent the legacy apps are.

Time to upgrade

Many have been upgraded frequently during the decades they’ve been in use; they might be old, but they’re much more than mere interfaces between users and databases or raw data. The more auditing and management tools these applications have, the more difficult and less practical it is to recode the software. Legacy-to-Web middleware becomes the best bet.

The Lowdown
  • What is it? Legacy-to-Web tools are middleware that manage the conversion of data and applications between old systems and Web front ends.

  • Why would I need it? Content is the mother lode in any electronic initiative; the trick is gaining Web access to it. Unless you’re taking on the job of recoding your legacy systems, using legacy-to-Web tools is the best method.

  • What’s the first step? Know your legacy systems. Shopping for a conversion tool before conducting a thorough inventory of your applications and data is a waste of time.

  • What’s the price? It varies widely with the extent of the job—publishing fixed, read-only data to the Web is relatively easy, for instance, but moving applications to the Web and building interactive functions is difficult. You can pay several hundred, several thousand or tens of thousands of dollars—and get your money’s worth in each case.

    But don’t buy an elephant gun to shoot a mouse—even shareware and freeware tools can build Web pages and publish files. Some of them are quite sophisticated.

  • Must-know info? A good tool must preserve the integrity of legacy applications and data, have an easily customizable interface and be highly scalable because there will always be more users and data, not fewer users and less data.


    •  You also should consider whether the legacy applications are running on very old, difficult-to-maintain hardware. If they are, you’re looking at an eventual rewrite; the only choice is when.

    Some agencies have no resources for a major new effort to convert legacy applications to Web-based applications at the code level. Others might have developed a cadre of hot programmers during the year 2000 frenzy who are looking for a big, new project and could handle a relatively fast conversion with in-house resources.

    Although data is often the first thing that comes to mind when you think of legacy-to-Web migration, applications also are being moved into the enterprise to support agencies’ full slate of users, including telecommuters.

    Data conversion and publishing are relatively straightforward, with lots of tools available to access old databases via browsers. Converting legacy applications is far more complex.

    The most common legacy applications operate on IBM 5250 and 3270 terminals, or are OpenVMS or Unix applications running on various terminals.

    User-friendliness is a nebulous term, but in this case it’s easy to define: Simplify the process and provide extensive error-handling routines.

    Think twice, though, before you carry your desire for simplicity to the point of outsourcing a conversion.

    Such services are available, and you could be tempted to take advantage of them. But doing it yourself will develop in-house conversion skills and build a knowledge base among your programmers that can be applied to the next conversion project, which will almost certainly come along.

    The Web is evolving, with new features being added to browsers and new languages such as Extensible Markup Language replacing or complementing Hypertext Markup Language, so legacy-to-Web conversion isn’t a one-time job. Once XML is in widespread use, you can bet that new metalanguages will come along and be adopted.

    John McCormick is a free-lance writer and computer consultant. E-mail him at poweruser@mail.usa.com.

    1 2 >> Next



    GCN Popup