It goes without saying that to upgrade from legacy software, IT managers need to know what it does. Often that’s harder than it sounds. The documentation of old software is often poor or incomplete. Users may have discovered features that it doesn’t mention. An upgrade to new software may result in unpleasant surprises when users can’t do things they did before.
In cases like this, it’s necessary to go beyond the documentation and “reverse engineer” their legacy software. They’ll get a more complete picture of what it does, and the new system will present fewer problems.
Understanding Legacy Software
The aim isn’t to understand everything the software does, just everything that the users do with it. This requires understanding existing workflows and the functionality they need. Indeed, the plan for migration should enumerate all the uses which employees make of the software. Without that, it’s impossible to be sure the replacement application does everything required.
People are used to the old system. They know tricks it can do which aren’t actually supported. Further, they might be using the application’s scripting language to streamline their work. Going to the new system will require rewriting those scripts. If individuals have written their own, covering them all will take some work.
The key is understanding the workflow, not just individual actions. The new software will provide different ways of doing things, but it has to allow people to carry out all the tasks which are part of their job.
Exploring the Documentation
The legacy software’s official documentation may not be the only source of information or even the best source. Other resources include training materials, procedures, instructions, and notes. The people who use the software know best where the information is. The official documentation could be less reliable than other materials. It might not have been updated along with the software.
Replacing a legacy application may involve more than what the vendor or in-house developer created. The software as it’s used may include scripts and plugins, written locally or provided by third parties. They’re part of the software’s operation, and it’s important to know how they work and how they’re used.
Finding Equivalent Functionality
Again, what’s important is the workflow. The new software will have different ways of doing many things. What’s needed isn’t step-for-step equivalence, but the ability to carry out the same work. Nothing should be harder to do than before. The undocumented features and scripts may provide shortcuts that greatly increase efficiency. The replacement system should make things at least as easy.
Not every feature from the old software needs to be duplicated. Some shortcuts may actually be bad ideas. They may bypass the audit trail, increase the chance of mistakes, or reduce security. Features should be retained only if they’re justified. Increased privacy requirements could make old techniques unadvisable. For instance, if regular employees at their desks have been using administrator accounts because it was the only way to get things done, the upgrade needs to find a better way.
No one ever uses all the features of a complex application. In fact, a good upgrade plan will recognize what features can be safely ignored. The list should be conservative; the organization can write off a feature only if it’s sure it won’t be needed.
Learn More About Reverse Engineering Your Legacy Software
Doing a legacy upgrade requires a thorough understanding of how the old software works. It can call for some imaginative research. The people using the software should be closely involved. They know their jobs best, and they’ll be the judges of whether the new features are an adequate replacement. A successful upgrade gives everyone a way to do their jobs, as well as before or better. Contact us to learn more.