Every IT Head encounters the following issue at some point in his career: what to do with a system which is still used by business but no changes or error fixes are actually viable any more? It applies most frequently to a custom-made system developed long ago. Its source codes are still available, but the team which developed and maintained them no longer exists. The IT Department would be keen to disable such a system; since, however, the business needs do not allow for such a solution, there are two options left: reconstruct the development team or rewrite the system anew.

If you asked the programmers what to choose, they would probably have no doubts. “Let’s write the system anew, but let’s do it better than our predecessors. Let’s use the new technologies we know well, improve the system architecture and bury the old system. We would be able to clear the error list, implement the new functions that business has requested for months and add some bells and whistles in the user interface.” The benefits of such a scenario are clear: the IT department will regain capability to introduce efficiently changes to the system, new integration possibilities will emerge and the issue of solution obsolescence will be solved for many years to come.

But the IT Manager would not be usually so enthusiastic about the idea. First of all, he or she could imagine the look of the system’s business owner when told: “well, you’ve been waiting for the completion of your urgent requests for months, but, please, do accept this budget of several hundred thousand and we will be able to perform them for you in a year… or two years at most”. He or she will also know, especially if experienced with similar projects, that the cost of re-implementation and time for production launch are usually way underestimated.

On the other hand, the scenario of creating a team to maintain and develop the code for the existing system does not look optimistic either. Obviously, the benefits brought about by a success are worth it. The IT Department may soon set about fixing the most problematic errors and fulfilling new business needs. Further, the improvement and development costs of a stable system usually account for a small percentage of its cost price, so it is much easier to allocate the company budget. Yet the gateway to success seems much more narrow than in the system re-implementation variant. First, you need to find programmers who will be willing and competent to delve into tens of thousands of lines of code lines with hardly any documentation there. It is already a challenge and if we now add that the code is usually written in an older programming language and with libraries or tools no longer developed, the case becomes truly difficult. And it does not get any easier later on, because you need to maintain the team: for such a competitive market, CVs which read “development of a new mobile application in React Native” sound much better than those reading “correction of errors in a legacy system in Visual Basic 6”.

So, what should we do to solve the system development issue, when both scenarios generate major difficulties? Above all, you need to be aware that a technological update will be necessary in the long term, as the cost of supporting legacy solutions will grow every year, while the possibility to adapt them for the changing business needs will shrink. It is essential, however, to form such a project team who will both have the adequate technical competence and know well the genuine business needs underlying the system.
And now we get to the heart of the issue, as the best method to obtain the expertise is… to spend several months maintaining and developing the legacy system. With such training, the team will get substantially better preparation for making viable plans of technological migration. They will also be able to discuss needs with business an a peer-to-peer basis and distinguish legitimate business needs from nice-to-have requirements which are costly but provide little value.

With such an approach, you may obtain benefits from both scenarios described above: in the short run, you will be able to respond to errors and changes needed, as they appear, while in the long run, you will solve the technical debt problem and get enhanced possibilities of development and integration. Some issues will disappear along the way: a well-prepared team will plan migration without excessive optimism, business will perceive direct results from the budget and programmers will not look for job opportunities with more attractive technologies. The remaining issue is to find the right members for the team. It is certainly vital for the team members to be willing to keep learning both as regards technology and business know-how. For programmers, the command of various languages and tools plus the ability to work on a third-party code count more than for instance 10-year experience in developing CRM systems in JEE on Oracle. The selection of the right people from the multitudinous offers on the market is not an easy task, but it is possible – this topic, however, deserves a separate article. In any case, you may always get support from third parties, which will handle the issue themselves.