No matter how process-driven and tech-savvy, every IT department supports at least a few unmaintainable software applications. Whether it’s a minor, non-strategic application used by someone in a cost center that has long been abandoned by the vendor, or a custom application written by some long-departed “clever” programmer, or worst of all, a commercial application customized by staff at the requests of the users, it’s a heritage application; meaning, the IT department inherited responsibility for supporting it. Fortunately, specialty vendors of Software as a Service (SaaS) are offering hosted, generic solutions for a growing number of business processes that depend on these odd, heritage applications. And the IT departments, desperate to shed responsibility for supporting these unmaintainable applications, are joining forces with the users to finally retire them. As always, it is the job of the practicing IT project manager to figure out how to get there.
To begin, let’s consider the current state from the point of view of the user. That heritage application represents more than just junky old code. It is:
- A data repository, for both work in progress and historical records.
- A business process, tailored to the needs of the software (and sometimes vice-versa)
- A generator of reports, which might actually be vital to the users and their customers
- A familiar user interface, no matter how clunky it might be compared to the state of the art
- A well-understood security model, even if it is completely inadequate
- In some cases, it might even be some administrator’s bread and butter
While most users will agree that their familiar, old heritage application has to be replaced, all of these attributes of their current application must be addressed by any replacement candidate, or they might decide they’d rather keep what they’ve got. So let’s consider each of these points, beginning with the data repository, and continuing over the next few weeks.
“Data assumes the shape of its container.” — Gordon’s Law
Any heritage application eventually accumulates data records; usually, a lot of them. It’s been my observation that unmaintainable applications tend to acquire a de facto exemption from data retention policies, since it’s too much trouble to purge ancient records. Consequently, the migration to a new system is an excellent time for the users and their partners in IT to consider questions such as:
- What do we actually need to retain, going forward?
- How many people actually need access to historical data?
- If we don’t regularly review history, but need to retain it, can we convert it to some searchable read-only format, like PDF files?
- Is it possible to complete all open transactions in the heritage system and then begin all new transaction in the new system, with all the historical records stored separately?
- If we really, really need to migrate current data, e.g. incomplete transactions, is it possible to simply enter them by hand? If not, is it possible to easily export the current data from the heritage system?
- If data must and can be exported , how much format conversion will be required to rationalize the records for import? In other words, is the data represented in a peculiar or irregular fashion, thus requiring a lot of tortured business rules be interpreted before loading it into the target?
- If the data can’t be cleanly exported, but must be loaded into the target system, can all of the needed data elements be produced via the report writer? Don’t laugh; that’s how we loaded HR and payroll data from a heritage MS-DOS based system into PeopleSoft on one project, years ago.
These issues will drive a lot of the implementation effort, so it’s best to confront them at the beginning. More than one project has failed because the users had the expectation that they could “take their data along,” and the vendor couldn’t adequately support that requirement.
Next week, I’ll continue this theme with some thoughts about business processes and reports, and how moving to a new SaaS application might present some valuable opportunities for both the user community and their customers.
Part Two
