Legacy IT in the age of AI: Start now or wait for the next tool?
Whether you are a soldier doing a military appreciation, a seller carrying out a SPIN analysis to encourage a prospect to commit or the director of an organisation considering a business case, the process is essentially the same:
Do I understand sufficiently the situation in which we find ourselves.
How do I assess the relative importance of the problems that we face.
What resources do I have to address them and how do I balance the call on those resources to solve all the issues that we face.
If I commit those resources what is the probability that the problem will be resolved, how big is the benefit if we succeed and what is the impact of failure?
The challenge of legacy IT is significant:
An organisation has a supplier who is ramping up support and maintenance fees perhaps by 100% “because they can”, from £100k/year 8 years ago to £5m for three years currently and to £10m for 3 years on the next renewal. Is it viable to migrate to a replacement equivalent product.
COTS Web Application Server to open source tomcat?
COTS RDBMS to opensource RDBMS such as MariaDB.
VMWare to another hypervisor or to the cloud.
Our teaser deal to migrate to cloud is ending and the charges are about to escalate. What can we do to be able to migrate between data centres or cloud providers.
We are getting rid of “that” in three years has been the mantra for 10 years and now we are on an old and unsupported version. We then find the hardware is out of support, the OS has vulnerabilities and we have to re-platform, but “that” will not run on the new hardware, requiring an unexpected project to resolve.
Our old applications have out of date interfaces, they are not web enabled so difficult to run in the cloud and discourage new users from engaging. We want to extend usage outside the organisation but that’s difficult.
Every change we request takes increasing time to implement and test, with the risk of bugs arising after rollout impacting reputation as well as consuming spare resource.
Vulnerability scanners have identified excessive vulnerabilities in our systems and we have to patch them, by upgrading product versions, but that’s a complex task.
So what is the answer. To often the thought arises “I would not start from here” yet here is where we are!
Our situation is worse if cutbacks have hollowed out our team so the resource we have are only sufficient to keep the lights on. The staff that wrote the systems are long gone, and no one is available with experience of transformation projects.
So what are our options to resolve these problems?
Historically solutions can be of the following types:
Step by step upgrade of product versions to get to a supported platform.
Stand up a replacement environment with fresh installations of the latest supported version, port the code.
Stand up an alternative product set replacing historic COTS products and port the code.
Purchase a replacement application that does most of what we need.
Re-write the application with a line by line translation to a replacement language.
Document requirements and carry out a complete re-write.
Now AI is on everyone’s lips. The claims of AI possibilities are growing. In recent months AI has allegedly brought new and improving capabilities and suggesting the ability to enhance the productivity for the above strategies. Increasingly AI promises the ability to:
Take a specification and generate code.
Extend that generation process by training to create good code.
Transform existing code to create a replacement in a different language.
Every month we see improvements in the AI tools available. Most developers and many end users have now experienced a range of tools to help with routine tasks, such as Claude, Codex, Cursor and Fable. Products such as AWS bedrock are good at bulk transformation.
A search in Google for “experience of failed AI projects” does though provide details of the number of AI projects that have not delivered, indeed failed, presenting the challenge to decision makers.
Regularly we also hear of questionable successes of AI as capabilities escape the lab and hack existing systems. This article dodges that question - lets leave the ethics issues and next best competition to one side because any specific claim here might easily be out of date in a month!
Focussing on the topic of Legacy IT and the place that AI has in transformation from it, we need to reflect on where we want to arrive. What do we want to achieve? Where do we want to be in a few years. Is the product of our transformation going to fit into our future architecture.
When considering how to develop new applications we have a real challenge. Where is our IPR going to reside? If we accept a particular AI tool, will that tool be superseded in months and any IPR become obsolete, or can we upgrade that IPR into the new tool.
Are we here talking about a race to the top with specification tools and testing tools that generate code that we never need to see. When we wrote C that code was optimised, converted to assembler, then into machine and finally linked into an image. Will we now have requirements tools and test specification tools that generate code that we now never need to see?
Yet we have to meet security standards, usability standards, interface standards. Its going to be a pretty complex tool that achieves all of those outcomes. We can leave that for the future, but if it arrives does that make everything else obsolete and requiring a transformation too.
However the urgent question is what to do with our legacy code and data now to meet the challenges that are identified above.
Possible paths forward:
Can AI be used to transform our applications to alternative technology stacks on the basis of some line by line translation, which once transformed, will be maintained by programmers, just writing their code more efficiently using Claude.
Will AI mine our existing applications to establish requirements then regenerate our applications in a new environment to produce a “better” identical application which we subsequently maintain in the same way?
Or will we have a new declarative specification language and testing language allowing AI to generate business processes, data models, test specifications and all the underlying code, making current programming skills redundant but still using people to define required capability in a new AI declaration mechanism.
Underpinning this is whether any project we start will be completed and delivered before it is obsolete and we need to start again? An IT professional will likely propose the following:
The starting point is governance. All projects need clear deliverables underpinned by a business case that gets delivered.
Likely a need for an architecture will be described, identifying a programme decomposed into smaller projects, factoring in time and risk.
To manage risk we need contingency planning and risk mitigation to reduce risk to an acceptable level.
How though do we manage the business case and ensure a return on investment when an agile approach is the partner of an evergreen approach where the endeavour never finishes because stopping is to fall behind, if that is we ever actually caught up by completing the legacy transformation.
Add to this the risk that the general adoption of AI is extremely low cost at the moment and once its proven, the AI companies will want a return on their investment, so prices will rise!
Its concerning. As Bilbo Baggins said “the journey that takes the longest is the one that is never started” but does waiting for the next tool mean never getting started, and perhaps delaying starting means you have no staff trained to go on the journey.
Time in reconnaissance is seldom wasted. Can we persuade our young people to join organisations like the BCS to learn from others outside their organisation so they are at least primed to start? How many IT professionals have the foresight to evolve their skills to be good architects able to manage changing technologies?
Or is our 1.9T lines of COBOL actually good enough and does not need transformation, just resurfacing with a replacement UI?
An interesting journey or looking over the precipice?
