Many don’t realise it, but legacy systems power a significant portion of the technology we rely on daily. Industries like healthcare, finance, manufacturing, and utilities still depend on outdated software in production environments. In fact, legacy systems are so widespread that even critical banking infrastructure runs on COBOL-based systems from the 1960s. While modern apps provide sleek user experiences; for example, the app you use to check your balances, the backend doing the work of transferring money, providing you with a statement, etc – runs on technology that is literally more than half a century old.
A very common example of this is the UK’s NHS, which is still known to operate air-gapped Windows XP and Windows 98 machines to control critical healthcare equipment such as MRI and X-ray equipment. Testing these systems (as well as any other type of legacy system) presents unique challenges: XP is a well-documented security risk, and software running on such outdated platforms often lacks modern integration points like APIs, webhooks, or automation interfaces.
Additionally, many legacy applications use outdated UI frameworks (e.g., Delphi, Oracle Forms) that modern testing tools struggle to support. When you factor in the significant technical debt these organisations likely carry as well as the system complexity involved in maintaining these old systems, testing becomes even more fragile—so much so that many modern testing frameworks simply won’t work.
But what does work? Well, in this article, we’ll break down the key challenges of legacy system testing, explore effective strategies, discuss the right tools, and provide practical solutions to make testing legacy applications easier and more reliable.
Table of Contents
Why testing legacy systems poses unique challenges
We’ve touched on a few of these points already, but let’s explore them in depth.
A lack of modern integration points
Many legacy applications don’t have APIs or webhooks, meaning they simply cannot be tested via modern API-based automation. In fact, if we go back to our COBOL example which is still widely used in finance, banking and even in airline ticketing systems, these systems would have been developed and deployed even before widespread adoption of the internet, meaning that the whole concept of an API or a webhook hadn’t even been invented yet. It’s impossible to communicate with these systems this way.
Even in the case of legacy applications still running older versions of Windows, for example, while theoretically you could connect these systems to the internet and use a RESTful or GraphQL endpoint, or even cloud-based integrations such as AWS Lambda or Azure, doing so is a massive security risk. Windows 7 in particular hasn’t had security patches for over 5 years, and systems like Windows XP and 98 much further beyond that. If you connect these systems to the internet you open the door to having your systems compromised which could be massively damaging to your infrastructure and your customer trust.
Instead, you have no choice but to rely on UI-based testing tools (like T-Plan) which simulate real user interactions by driving the app as if a real user was in control, and collecting test data in a way that works without requiring direct system integration.
Outdated UI frameworks
Legacy applications, by definition, rely on outdated technologies that modern automation tools often struggle to support. If you’re testing a legacy system, you may encounter frameworks such as:
- VB6 – Microsoft ended support in 2008, yet it remains in use for business-critical applications in finance and logistics.
- Delphi – A Pascal-based framework still found in CRM, ERP, and industrial automation tools.
- Oracle Forms – A database-driven UI framework, still common in banking, insurance, and government applications.
- PowerBuilder – Known for its tightly coupled business logic and UI, making modernization difficult.
- COBOL-based UIs – Still prevalent in banking, mainframe processing, and airline reservation systems, often using text-based or green-screen interfaces that modern tools can’t automate.
Beyond these frameworks, thick-client desktop applications (running on, for example, Windows, UNIX, or AS/400 mainframes) further complicate testing. Unlike modern SaaS or web-based apps, these require direct OS-level interaction, making remote access impractical (and unsafe) and automation difficult.
Additionally, many legacy applications have custom-built proprietary interfaces that don’t follow modern UI standards. Issues such as fixed-resolution UIs, hardcoded text fields, and unpredictable element IDs make automation unreliable. Because of these challenges, OCR and image-based testing tools like T-Plan are often the only viable approach, allowing testers to interact with visual elements as a human would, without relying on standard UI locators.
Security and compliance issues
While we’ve discussed the security issues that come from simply using a legacy system, there are compliance concerns that you should be aware of. Many legacy systems are not compliant with modern security regulations like GDPR, HIPAA or SOC 2, posing risks for industries handling sensitive data. Unlike modern applications these systems often lack encryption, strong authentication and access controls; which makes security testing essential. For example, older applications may store data in plaintext, lack multi-factor authentication or rely on hardcoded credentials, have weak role-based access meaning that users may have excessive permissions, or have obsolete or even non-existent security logging which makes it difficult to detect breaches or unauthorised access.
Many of these weaknesses stem from these systems’ reliance on outdated UI-based workflows, which are not testable with modern tools. However, something like T-Plan, which is image-based, can be used to help verify security measures like login flows, access control enforcement and encryption. Additionally, the direct UI interaction methodology that T-Plan uses can help to verify compliance issues, even when traditional security testing tools might fail.
Fragility, automation and technical debt
Legacy systems were never designed for automation, making them fragile and difficult to test. Years of patches, quick fixes, and undocumented changes have created unstable environments where even small modifications can cause catastrophic failures.
One major issue is UI instability—legacy applications often lack structured identifiers, meaning automated scripts must rely on image recognition or fixed coordinates, both of which break easily if the UI shifts. Traditional automation tools struggle with dynamic UI elements, unpredictable layouts, and missing object locators, leading to flaky tests that require constant maintenance.
Additionally, many legacy applications have deep technical debt, with hidden dependencies and poor documentation making them difficult to debug. Since many of these systems were built decades ago, modern debugging tools don’t always work, and tracing errors is time-consuming. Without clear test coverage maps, teams often don’t know which workflows to prioritise, increasing the risk of missed defects.
This is where OCR and image-based tools like T-Plan provide a critical advantage—allowing testers to interact with applications visually, just like a human would, without requiring structured UI elements or code modifications.
Strategies for testing legacy systems
UI automation testing
Since legacy systems often lack APIs, UI-based automation is the most effective testing approach. Unlike modern applications where automated tests can interact with structured code and standardized UI elements, legacy applications must be tested in ways that replicate human interaction.
Image-based automation tools, like T-Plan, identify buttons, text fields, and UI elements visually, allowing tests to interact with the application even when there are no standard object locators available. OCR-based automation is another useful approach, particularly for legacy applications with text-based interfaces or green-screen systems. These methods allow automation scripts to function even when the UI structure is outdated or inconsistent.
If you have a legacy application you need to test and are interested in how T-Plan will be able to help you do it, we’ll happily demonstrate it to you for free if you sign up using the link below.
Resilience testing (ensuring stability)
Many legacy applications suffer from UI instability, requiring test strategies that can handle unpredictable behaviours. Resilience testing focuses on making sure automation scripts can recover from pop-ups, unexpected dialog boxes, and UI delays. Older systems may take longer to load elements, so implementing smart wait times and retry logic is crucial to preventing false test failures.
Another key aspect of resilience testing is handling layout changes. Unlike modern applications that use responsive design principles, legacy applications may have fixed resolution interfaces that behave differently on different screens. Testing across multiple display settings and resolutions ensures that automated tests remain reliable under different conditions.
Regression testing (avoiding breakages)
Regression testing is critical for legacy applications that still receive occasional updates or security patches. Since these applications often lack structured test cases or historical records, a key strategy is Golden Master Testing (Characterization Testing)—where system outputs are captured before changes and compared after updates to detect unintended modifications.
For legacy applications that run on different operating systems or hardware configurations, multi-version testing is essential. A workflow that functions correctly on Windows XP may not work on Windows 7 in compatibility mode, so testing across multiple versions helps prevent compatibility issues.
Hybrid automation (mixing manual & automated testing)
Because many legacy applications are too fragile for fully automated testing, a hybrid approach—combining manual intervention with automation—often produces the best results. Certain tasks, like navigating complex workflows or validating unpredictable UI behaviours, may still require human oversight, while repetitive processes can be automated to improve efficiency.
Record-and-playback tools can help teams capture test executions for reuse, reducing the manual effort needed for future tests. Semi-automated execution—where tests run automatically but allow a tester to intervene when necessary—can also be highly effective in maintaining control over fragile workflows.
Final thoughts
Testing legacy systems is far from straightforward. The lack of modern integration points, outdated UI frameworks, security vulnerabilities, and deep-rooted technical debt make traditional automation approaches ineffective. However, with the right strategies, organizations can still achieve reliable and scalable testing.
By leveraging UI-based automation, OCR tools, and resilience testing, teams can effectively validate critical workflows without requiring direct system modifications. Ultimately, the best approach depends on the specific constraints of your legacy system. While image-based testing solutions like T-Plan provide a viable path forward in most cases, you could also explore alternative strategies such as database validation, reverse engineering APIs, and virtualisation to maximize coverage and efficiency.
As businesses continue to modernise, legacy systems won’t disappear overnight. The key is not just keeping them functional but ensuring they remain secure, stable, and testable. With the right tools and methodologies, you can confidently maintain your business’ legacy applications while gradually transitioning toward modern architectures.
Interested in what T-Plan can do for your legacy testing needs? Check out our free trial below:
