Most automation conversations reach a point where someone in the room says it: "Our system is too old for this." The comment usually comes from a person who knows the platform well, has watched previous integration attempts stall, and has good reason to be cautious. The reservation system has been running for over a decade, the ERP was customized by a contractor who left years ago, and most of the documentation lives in one engineer's head. Against that backdrop, automation starts to sound like something that can only happen after a full rebuild.
That caution deserves to be taken seriously, though it tends to locate the problem in the wrong place. What automation actually needs is a reliable way for data to move in and out of a system, and there are far more ways to achieve that than most teams assume. Plenty of platforms that look impossible to work with from the outside turn out to have an accessible database, a scheduled export, or internal services that new tools can build on.
In this article, we'll look at what "too old" usually means in practice, why replatforming first often carries more risk than the problem it's meant to solve, and how you can add automation one capability at a time while the core system keeps running. The aim is to map out a path that delivers results, without asking your business to pause and rebuild its foundation first.
What "too old" usually means in practice
When a team says a system is too old for automation, the phrase usually stands in for a specific limitation they've run into, often more than once. Separating those limitations matters, because each one points to a different workaround, and some are far easier to solve than the objection suggests.
The most common is the absence of an API. Many older platforms were built before external integrations were expected, so there is no documented way for another tool to request or send data. In many cases, the data itself is still perfectly accessible. It sits in a database that can be read directly or through a thin service layer built on top of it, which gives new tools a controlled point of access without changes to the original system.
A related constraint is data that only leaves the system through batch exports. A property management system might produce a nightly file of bookings, or an ERP might export orders once an hour. This limits how quickly automation can react, but it rarely rules automation out. Many valuable processes, such as reconciliation, reporting, and supplier updates, run comfortably on scheduled data. The real question is which processes truly need real-time information and which have simply never been tried without it.
Some systems can only be operated through their user interface. Staff log in, click through screens, and re-enter information by hand because there is no other way in. This is the hardest constraint, and it is where robotic process automation, software that mimics those clicks, becomes an option. It works, though it tends to break whenever the interface changes, so it is best treated as a bridge while a more stable connection is built.
Then there is undocumented custom code. Years of modifications by different developers leave behavior that nobody fully understands, and the fear of breaking something makes every change feel risky. This is a legitimate concern, and it makes a strong case for building automation around the system. New capabilities that read from the platform without altering its logic leave the fragile parts untouched.
Once the constraints are named, the objection usually becomes smaller and more specific. "Our system is too old" turns into "our booking engine only exports once a night" or "our ERP has no API, but its database is readable." Those are problems with known solutions, and they make it possible to weigh the real cost of automation against the option most teams reach for next: replacing the system entirely.
Why replatforming first is often the riskier path
Once a system has been labeled too old, replacing it can feel like the responsible choice. A new platform promises clean data, modern integrations, and an end to workarounds, and it lets everyone postpone the automation conversation until the foundation is ready. The instinct is understandable. The track record of large system replacements, however, suggests that waiting for a new platform often carries more risk than working with the one you have.
Large technology projects have a well-documented habit of running over budget and past their deadlines. The longer a project is scheduled to last, the more room there is for costs to grow and priorities to shift before anything goes live. Full replatforming projects are exactly the kind of long, far-reaching initiatives where these risks concentrate, and legacy modernization has a particularly difficult history. For example, a survey of large enterprises by the IT services provider Advanced found that 74% of organizations had started a legacy modernization project but failed to complete it.
Part of the reason is that replatforming asks a company to get everything right at once. Data has to be migrated without loss, staff have to be retrained, integrations have to be rebuilt, and years of undocumented custom behavior have to be reproduced in a new system, often before anyone fully understands what that behavior does. Each of those tasks carries its own risk, and they all have to come together on the day the new system goes live.
Meanwhile, the business keeps running on the old platform for the entire duration of the project. The manual work that prompted the automation conversation in the first place continues, sometimes for years, and the team leading the migration is usually the same team keeping daily operations afloat. If the project stalls, the company ends up paying for both the old platform and the unfinished new one, with none of the operational gains it was hoping for.
The existing system also has value that is easy to overlook. It works well enough to run the business today, your team knows how to use it, and it holds business rules that took years to refine. Automation built around that system keeps all of this intact while removing the manual steps that slow people down.
For a business weighing its options, this is good news. Improving operations can start with a single process, show its value quickly, and expand from there, with each step small enough to adjust or reverse. And if a full replacement does become necessary later, the work done along the way makes it easier, because data flows are documented, processes are mapped, and part of the old system's workload has already moved elsewhere. That gradual approach has a well-established method behind it, which is where we turn next.
Automating around the core
The method in question is called incremental extraction, and its premise is straightforward. The work a legacy system does is shifted elsewhere one function at a time, handed to a new service or automation, while everything else continues to run as before. Engineers often call this the strangler fig pattern, after a vine that grows around a host tree until it can stand on its own. For a business, the practical meaning is the following: the old system keeps doing what it does well, and new capabilities grow around it.
The first step is giving new tools a reliable way to reach the old system. In most cases, this means building an API layer on top of it, a thin service that reads from the existing database or internal services and makes that data available in a structured, controlled way. Automations and new applications connect to that layer and leave the legacy system's internal logic untouched, which also gives your team a single place to manage access, security, and future changes.
From there, the choice of what to extract first matters most. The best starting points are processes that are repetitive, well understood, and costly to handle manually, yet sit outside the very core of how the system works. In travel, that might be booking confirmations and supplier notifications, which draw on reservation data without needing to change it. In ecommerce, it could be order status updates or returns processing that currently require someone to copy information between the ERP and other tools. These processes deliver visible savings quickly and carry little risk, because the core system remains the source of truth.
As each extracted capability proves stable, the next one can build on the same foundation. Processes that only read data come first, followed by ones that write data back into the system, and eventually more complex workflows that combine several sources. Every step is small enough to test properly and roll back if something goes wrong, and each one produces a measurable result before the next begins.
Over time, the balance shifts. More of the daily workload runs through the new layer, the legacy system handles less, and your team learns exactly what the old platform does and why. Some companies eventually retire the original system once little is left inside it. Others keep it running indefinitely as a stable core, surrounded by automation that handles everything it was never designed for. Either outcome counts as a success, because the business improves its operations the whole way through and never has to bet everything on a single launch day.
Starting with the system you have
All of this changes what the objection we started with actually calls for. When someone in the room says the system is too old for automation, the most useful response is a follow-up question: too old in what way? Once the answer is specific, the path forward usually becomes clearer as well, and more often than not it begins with a single process that can be improved while the core platform keeps running.
In case you're not sure which of these constraints apply to your own system or where the best starting point lies, we'd be glad to help you work it out. In a short consultation, we'll look at how your current setup handles data today, what it can realistically support, and which processes make the most sense to automate first. Book a call to talk it through with our team.
.png)
.png)
.png)