Legacy Application to Windows - Challenge of design

I’ve discovered the greatest challenge of my application programming and design career,  (Hopefully I haven’t met my match!).  My latest project involves a rather large legacy character-based system which has evolved over the past 20 years or so.  The source code directory lists some 800+ pieces of source code, with close to 500 being actively used, and others that were basically copies of some “active” source with minor modifications - mostly in the screen layouts for entry programs, and header footer changes on reports.  In all, a lot of code to evaluate.

Of course, being a procedural language (thank goodness it isn’t cobol — I’m too rusty with that!), the source seems to have the expected number of “goto’s” and returns to “markers” in the code - all of which has reminded me of some of the cobol spaghetti code I’ve seen - and also early day Progress 4GL code.  Flow seems to twist and turn, help is non-existent, BUT — it has worked day in and day out for years!

Well then, why change?  Certainly going to a graphical interface with ability to have easy “lookups” for data, more capability to “cram” a screen with more information than can possibly be used (there’s my sarcasism again), scrolling windows, mouse clicks, right clicks, double clicks, mis-clicks — why not update?  Then of course there is the “tab” key instead of the “Enter” key.  Ever watched users as they move from character based entry screens to a windows entry screen? (It’s often not a pretty sight !).

All of these challenges with a little under 3 months to have a working program “live”, running a “real” business, “real” time!  The new program is to mimic the existing application entry screens as closely as possible so that users working with the legacy system will not be totally “lost” when trying to utilize the new application.  This probably is not the “best practice”, but I suspect that the users will come up to speed with the new application much faster and with less stress.