Making a big jump forward from legacy software is always hard. It's difficult enough when doing it at a reasonable pace, but it's worse when circumstances force a transition. Even if a deadline is looming, a successful legacy migration requires a systematic approach. Rushing the job in a panic will only make it harder.
The challenges of legacy modernization include both technical and human issues. The transition has to reach completion without breaking anything (which is obviously necessary). That includes effective workflows as well as compatible functionality.
A migration plan should start with a clear understanding of what constitutes the end goal. This provides a standard for measuring the success of the process. It also helps to identify where the risks are. These are some of the most common reasons a migration is necessary:
Some upgrades may be for custom software, written especially for the company. Others are for software which already exists commercially. These are at two ends of a continuum, and with either situation, there's always some development work to do. An upgrade to software which is already available will generally require some custom coding for importing data, tailoring the user interface, or adding custom functionality.
Broadly speaking, there are two types of challenges of legacy modernization. There are technical issues, relating to functionality, interfaces, and compatibility. There are also user issues, concerning the software's usability and acceptance.
If the new software can handle the legacy software's data with no changes, that's a huge help. More often, there are data compatibility issues. They could be subtle ones that no one recognizes at first.
Individual fields may cause issues. The format of dates or currency amounts could be different. The old software might have full names in one field while the new one wants separate first, last, and middle names.
Missing data is also a frequent source of aggravation. The legacy software may make assumptions about blank fields which are different from the new code's interpretation. There might be a difference between a missing and a blank field, or not. The data might include bad fields which the legacy software cheerfully ignores. It may be necessary to generate new indexes and unique identifiers.
Data cleanup can become a project in itself before the migration can proceed. (Those of you who have been through this process can attest to this fact.)
The documentation for a legacy system is often incomplete, inaccurate, or simply missing. Documentation of the internals is generally the worst. It can essentially be a 'black box' of sorts. There may be features which are essential to current operations but aren't documented. Not knowing exactly what the existing system does makes it hard to preserve its functionality in the upgrade.
Software rarely operates in complete isolation. It usually exchanges information with other tools that the business uses. Both sides have to agree on a protocol or API. Either the replacement software has to match the legacy software in exchanging information, or the other tools have to adapt. Sometimes several tools need to be updated at once to keep everything working.
If the legacy software uses services to get or store data or to make network connections, the replacement code has to do the equivalent. This may require writing adapters for the upgrade code. It may require changing the way the services work. The issues are similar to data migration, but they're ongoing rather than a one-time conversion.
Some of the challenges which turn up in an upgrade are better classified as "people issues" rather than technical ones. Some challenges may have technical solutions, but others are more a matter of good communication and training.
When people are familiar with a system, they don't like change unless they're facing serious problems. Getting them to accept the new software will take some effort. Presentations and materials showing how the upgrade will make their jobs easier will help.
Sometimes it's not just a matter of disliking change. The existing system may fit their workflow very well. The new one, even if its features are individually better, won't always work as smoothly with processes which employees have used for years. If the upgrade isn't a good fit, it could reduce productivity. If the transition team is aware of this, it should be able to find ways to improve the new system so it's friendly to business workflows.
The old system may have features which are hard to duplicate. They may not be strictly essential, but people are used to them and like to have them. Sometimes retaining them isn't worth the cost, and employees should learn how to do things differently. Sometimes it's possible to keep those features, or something close, without too much extra effort.
An upgrade plan should cover the whole process, from initial planning to the retirement of the legacy system. It needs to be comprehensive yet flexible enough to adjust to unexpected changes. It needs to allow enough time that the inevitable complications don't wreck the schedule. These are the main steps the plan should cover:
Top-quality planning and analysis tools make the process go more smoothly. SMART TS XL helps teams to modernize their software with a minimum of trouble. It covers all phases from initial planning to continuing maintenance. Your team will better be able to understand the requirements of the upgrade, document the required functionality, and bring information together.
With good planning and tools, even a complex legacy upgrade can reach a conclusion that makes all participants happy.