“We need to replace this 20-year-old software.” Those are words to make a manager’s blood run cold. Upgrading legacy technology is always a headache and sometimes a nightmare. Most efforts fall short of their hopes. Companies have to fall back to their old tech. There are many ways to fail, but careful and thorough planning can improve the odds of success. Follow these guidelines to stay on the path to a smooth software upgrade.
Define the Requirements Anew
The obvious requirements set is “do what the old software did”, but it makes the task harder than it has to be. The fact that the old software did something isn’t enough of a reason to require it in the new application.
It’s not tasks that matter, but goals. The old way of reaching the goal may have been a compromise with the software’s abilities. New software may offer a different way to do what the business needs. Some tasks may be convenient but not necessary.
At the same time, it’s necessary to make sure that the new software covers everything that has to be done. Discovering too late that it doesn’t support an important need is a common source of failure.
The software upgrade process should start with a fresh definition of business requirements. It needs to be complete, but it shouldn’t assume that things need to be done the way the old software did. The planning stage of an upgrade is a good time to consider operational changes. Making things easier for people involves not just new code, but new ways of getting work done.
Plan Out Dependencies
Software depends on other software. Dependencies can make an upgrade a much bigger task than it seemed at first. An old application may require an even older database. Either the new software has to work with the old supporting software, or both of the old components need to be replaced.
It may be possible to keep using the old components. Creating a piece of adapter code may let them work together. That may keep things going, but usually, it’s better to upgrade as much as possible at the same time. One-off fixes make for a fragile mix of software, and they put off the day when the old pieces can no longer be supported.
Sometimes, though, replacing all the old dependencies makes the task too big to manage. The important thing is not to get stuck with an unmaintainable mix of components. Mixing old and new can work, with sufficient care.
If a company rolls out new software without giving its employees enough training, trouble is sure to follow. They’ll use it inefficiently, make mistakes, and resent the inconvenience. Training should start well before switching to the new system. Employees should learn what the advantages are of the new system and what changes they’ll need to deal with. The change should be presented as a positive experience, something that will make their jobs easier.
The rollout should start with a pilot group. They’ll be the trial group for the training, and they’ll discover any rough spots in the system. Some points will need better explanations, and the training materials will be better for their experience.
Consider Running Both Side-by-Side
It may not be necessary to phase out the old software completely. A few tasks may be easier to do with it than with the new code. Moving all the work to the new software may be a gradual process, till enhancements let the new version do everything which is needed. It’s important, though, for information handled by the old and the new software to stay in sync. The long-term goal should be to replace the old software completely for a successful software upgrade.
At a minimum, the old system should be kept in place, with all its data, until a successful transition is signed off.
Plan for Success with a Software Upgrade
A major software upgrade isn’t easy, but good planning makes it easier. Clearly defined and complete requirements, awareness of the technical issues, and a good training program are essential parts of the plan. Paying close attention to them will allow a smooth transition and let employees do their jobs better than before.