Challenges of Testing Legacy Systems in a CI/CD World
Most Australian organisations now expect software to change continuously, yet much of their most valuable business software is old. Core banking platforms, superannuation systems, SAP estates, clinical applications and operational tools often contain decades of accumulated logic. In Sydney, Melbourne, Brisbane and Perth, those systems regularly sit alongside cloud services and modern APIs, creating hybrid delivery landscapes rather than clean cutovers.
CI/CD promises fast, repeatable feedback, but testing legacy systems in a CI/CD world can expose hidden dependencies, long batch cycles and brittle regression suites. The practical answer is not to automate every screen or force the mainframe into a cloud-shaped process overnight. It is to create a controlled path from change to evidence, so teams can release safely while progressively modernising the parts that create the greatest delivery risk.
Why legacy estates resist continuous delivery
Legacy platforms rarely fail because they are simply old. They fail because their behaviour depends on a web of undocumented interfaces, scheduled jobs, vendor packages and data conditions that modern delivery diagrams tend to hide. A small code change in a customer-facing application may trigger overnight batch processing in an operations platform, then alter a report consumed by another team days later.
The risk is often organisational as well as technical. Business owners may rely on a release window, shared test environments or an original vendor for scripts nobody else can maintain. In regulated Australian environments, the cost of an incorrect release can include missed settlement activity, customer harm or a breach of reporting obligations, so teams naturally become cautious.
Continuous delivery makes that caution harder to sustain when every change waits for a large test cycle. If feedback arrives days after a merge, developers batch work, release managers accumulate scope and testing becomes a ceremonial approval step. Modernising the interface without improving feedback simply relocates the bottleneck rather than removing it.
Where CI/CD pipelines break around legacy applications
A common failure pattern begins when teams place a slow end-to-end suite in every pipeline. Long-running scripts, unstable third-party endpoints, timeouts and scarce databases make builds flaky, so engineers begin rerunning failures. A queue that was meant to shorten feedback now delays it, and the pipeline becomes a place where teams hide uncertainty.
Shared integration environments create another fault line. Several teams compete for the same data, and one deployment can invalidate another team’s test run. Production-like batch schedules cannot be replayed on demand, while external vendors may offer limited sandbox access. The result is a pipeline that proves the application can start, but not that the connected business service behaves correctly.
Australian geography can make coordination harder. Sydney and Melbourne are major delivery hubs, while Brisbane and Perth teams often join the same stand-up at a different point in the morning and, in Perth’s case, later in local working hours. The response should be explicit ownership, recorded decisions and asynchronous handoffs rather than more meetings.
Automation should follow business risk
Teams often begin modernisation by selecting a browser automation tool and scripting thousands of user-interface paths. This may create activity without creating confidence. Object identifiers change, screen layouts differ across environments, and assertions focus on implementation details instead of business outcomes. Maintenance can then exceed the value of the coverage.
A more durable strategy starts with business capabilities and critical journeys. Characterisation tests record current behaviour around high-value functions before it is changed. Contract tests verify interfaces between modern services and legacy dependencies. API-level checks cover batch hand-offs, while a smaller set of browser journeys confirms that important workflows remain usable.
An agile testing approach helps teams fit this work into incremental delivery. Each sprint can add a modest slice of automated evidence, review its maintenance cost and use the result to decide what deserves further investment. The aim is a trustworthy safety net, not a headline automation percentage.
Test data and environments determine pipeline speed
Test data is frequently the real constraint in a legacy estate. Accounts contain years of linked records, and realistic scenarios may require weeks of processing before a condition appears. Teams that copy production data also inherit privacy obligations and data-quality problems. Under the Australian Privacy Act and, for some financial institutions, APRA requirements, access, masking and retention need deliberate controls.
Synthetic and masked datasets can make tests repeatable, but only when they preserve the relationships that drive the behaviour under test. Domain specialists may need to define representative transaction volumes, edge cases and settlement states, while engineers handle the generation and reset process. Treating data preparation as shared infrastructure prevents test cases from becoming a collection of fragile, one-off scripts.
For Azure DevOps users, effective test cases should connect each case to a requirement, risk or defect and state its data and environment needs. Clear traceability helps testers and developers share ownership. Containerised dependencies, service virtualisation and schedulable batch emulators can further remove queues and waiting.
Compare delivery models before choosing the target
The right target is not a fully automated legacy estate; it is a delivery model in which release decisions use evidence that is fast enough to influence the change. Comparing the operating characteristics makes the trade-offs explicit.
| Delivery concern | Batch-oriented legacy practice | CI/CD-aligned legacy approach |
|---|---|---|
| Change size | Large releases with accumulated scope | Small, independently controlled changes |
| Test feedback | Late regression cycle | Fast automated lane plus scheduled broad regression |
| Environments | Shared and manually configured | Provisioned, isolated and reset automatically |
| Test data | Production copies and ad hoc extracts | Synthetic, masked and version-controlled fixtures |
| Failure diagnosis | Manual reruns and team handoffs | Traceable evidence with clear ownership |
| Security and performance | Separate periodic exercises | Targeted checks tied to normal releases |
| Release control | Central approval near the end | Automated gates and explicit risk acceptance |
This comparison shows that CI/CD alignment is an operating change, not simply a new pipeline screen. A fast lane can cover smoke, API and critical journey checks, while a scheduled suite retains broader regression coverage. Security and performance checks can then run against the same realistic environments used by delivery teams.
A sensible roadmap usually progresses through discovery, protection, acceleration and expansion. Discovery maps critical business services, dependencies, release risks and current failure patterns. Protection establishes characterisation tests, test data controls and traceable acceptance criteria. Acceleration introduces fast pipeline gates, environment automation and reliable diagnostics. Expansion adds broader regression, security, performance and selective modernisation.
Build a legacy feedback loop teams can sustain
Success should be measured by release confidence and feedback time, not by the number of scripts. Useful indicators include the percentage of changes receiving fast automated checks, the time from commit to actionable evidence, flaky-test rates, escaped defects and the proportion of critical journeys covered without manual setup.
Ownership must also be shared. Developers should help maintain tests beside the code, business specialists should clarify critical behaviour, and testing specialists should design the framework, data strategy and quality gates. Australian teams often favour direct, pragmatic discussions; a quick squiz can expose an assumption quickly, provided the outcome is documented and assigned.
Review nFocus Software Testing’s practical testing insights, then arrange a focused legacy testing assessment for one critical service or release path. Start with the riskiest feedback gap, establish a measurable baseline and deliver an initial automated slice. From there, scale the approach only where it improves control, speed and customer confidence across the wider estate.