By Dídac López (ERNI Spain)
Every organisation that evolves its technology pursues clear objectives: greater scalability, improved user experience, reduced operational costs or the adoption of more sustainable architectures. Yet in many modernisation programmes, one critical factor rarely occupies the centre of the strategic conversation: the migration of the testing system.
Over the years, mature products have come to include more than just code. They have accumulated a validation network composed of unit, integration and end-to-end tests that encapsulate functional knowledge, design decisions and evidence of expected behaviour. This network does more than detect defects; it sustains confidence in every new release and acts as an operational guarantee of the product.
When the technology stack changes – whether through a new language, a new architecture or a new interface paradigm – that testing network becomes exposed. Obsolete frameworks, incompatible dependencies and discontinued tools can quickly transform what was once a strategic asset into a perceived obstacle to progress.
Why testing migration is often underestimated
A common mistake is to treat testing migration as a secondary task derived from the technology change. In practice, its effort can equal or even exceed the effort required to develop the application itself. Rewriting tests from scratch means reconstructing scenarios, reinterpreting behaviours and recovering years of accumulated evidence. It is not merely a technical cost; it is a risk to quality continuity.
This challenge is relevant in any industry, but in regulated environments such as healthcare, industrial systems or defence services, it becomes critical. Tests do not only validate functionality; they constitute structured evidence of traceability, coverage and compliance. Losing or degrading them implies revalidation, documentation rebuild and risks that extend beyond purely technical concerns.
Modernising without a clear strategy to preserve and evolve the testing network means effectively resetting the product’s assurance baseline on a new platform. The question is not whether the system can be rebuilt, but how to do so without losing the validated knowledge that supports it.
Case study 1: Migrating from desktop to web while preserving the testing network
A mature in vitro diagnostic system already established in the market faced the modernisation of its control interface. The product core, including embedded software, processing logic, communication with the instrument, databases, and simulators, remained stable. The transformation affected only the presentation layer, moving from a desktop application to a web-based interface supported by a new architecture.
From a functional perspective, the change was contained. From a testing perspective, it represented the primary risk of the program.
The system relied on more than 1,500 automated test scenarios tracing to approximately 900 formal requirements. Over the years, this testing network had accumulated validated behaviour, structured evidence and operational confidence. It did more than verify functionality. It sustained the assurance that every release would continue to behave as intended.
The challenge was clear. The existing automation framework, designed to interact with desktop applications, could not support the new web environment. The most straightforward option – rewriting the entire test suite – implied significant cost, risk of functional reinterpretation, and the need to rebuild established traceability. In a regulated context, where historical consistency and evidence continuity are essential, such disruption was not acceptable. Moreover, the estimated effort to migrate the tests exceeded the effort required to migrate the user interface itself.
Preserving the testing architecture
The strategic decision was not to migrate the test cases, but to intervene precisely at the point where the framework interacted with the user interface. The functional definition in Gherkin, the validation intent, and the traceability to requirements were preserved in full. All capabilities unrelated to the UI, including database access, simulator integration and test data management, were maintained. The effort focused on replacing the critical component: the interaction engine.
The migration moved to Playwright as the new driver for the web interface. Instead of redesigning the testing architecture, a layer of glue code was introduced to maximise interface backward compatibility between the existing scenarios and the new interaction layer. The objective was to reuse validated assets to the greatest extent possible, minimise structural changes, and reduce impact on the testing network. The goal was not to start over, but to preserve behaviour while evolving the underlying technology.
How AI accelerated the migration
Artificial intelligence played an accelerating role in this transition. Based on the existing interaction patterns, the AI generated initial versions of the new page object model adapted to the web environment and adjusted the connections to the existing step definitions. This provided the team with a functional baseline for each screen, significantly reducing the manual effort required to reconstruct interaction flows. Human supervision remained essential to ensure robustness, consistency and alignment with the real system behaviour, but the mechanical effort of rebuilding page interactions was substantially reduced.
The impact was measurable. Migration time per screen and its subsequent stabilisation was reduced by approximately 60 percent compared to a fully manual approach. The overall testing migration effort decreased by roughly 50 percent relative to a complete rewrite. More importantly, the organisation was able to maintain parallel releases during the transition, validating functional equivalence without interrupting delivery cycles.
Modernising the interface did not require resetting product confidence. The testing network evolved alongside the architecture, preserving traceability, validated behaviour and operational assurance. The key was not rewriting faster, but deciding what should not be rewritten at all.
Case study 2: Migrating between different stacks using natural language as a bridge
In this second scenario, the challenge emerged in the context of technological consolidation. The organisation maintained two applications sharing a part of the same functional domain: Application A, developed in Java, and Application B, developed in .NET. As part of a unification strategy, a significant set of functionalities was migrated from Application B to Application A.
The scope included approximately 300 functional requirements that, in Application B, were covered by around 800 integration tests implemented in MSTest. These tests validated behaviour at a technical layer specific to the .NET stack. Once the functionality was moved to Application A, that technological layer no longer existed. The tests, as originally implemented, were no longer executable and, more importantly, no longer meaningful in the new environment.
Rewriting the tests directly in the Java stack was an obvious option. However, this would have meant replicating technical implementations without ensuring that the underlying functional meaning was preserved consistently. At the same time, Application A already had a well-established functional coverage defined in Cucumber, structured in natural language and aligned with its behavioural model.
Natural language as the migration layer
The strategic decision was to use that natural language layer as a bridge between both worlds. Instead of translating .NET code into Java code, the team extracted the functional intent embedded in the tests of Application B and expressed it as Gherkin scenarios compatible with Application A. The objective was not to move tests between technologies, but to preserve the semantics of the requirements independently of the stack that implemented them.
This process required analysing each existing test, identifying the actual requirement it validated, and translating that behaviour into natural language scenarios. Whenever possible, existing Cucumber steps from Application A were reused. When new definitions were needed, they were introduced in alignment with the existing semantic model, avoiding duplication and maintaining linguistic consistency.
AI-assisted semantic translation
Artificial intelligence played a meaningful role in this transformation. Working on the MSTest codebase, the associated documentation, and the existing Cucumber catalogue, the AI helped to identify behavioural patterns, suggest mappings to already defined steps, and propose appropriate parameterisation strategies. Operating entirely in natural language, it supported the consolidation of a more rationalised and reusable semantic catalogue while reducing the manual effort required for analysis and redrafting.
The impact was tangible. The effort required to migrate the test assets was reduced by approximately 30 percent compared to a fully manual translation approach. More importantly, traceability to the original 300 requirements was preserved throughout the transition, and functional reliability was maintained without interruption. The organisation did not merely relocate validation logic from one platform to another. It strengthened its ability to evolve technologically while safeguarding the meaning, consistency and confidence embedded in its testing assets.
Migrating from .NET to Java ceased to be a problem of technological compatibility and became an exercise in semantic preservation.
Not cutting away the net mid-air
Every technology migration is a leap. It may be carefully planned, well-funded and technically sound. But, like a trapeze act, the success of the jump does not depend only on the take-off or the skill in the air. It depends on the net below.
The testing network is that safety net. It is not visible to end users, yet it supports every movement of the product. It connects requirements to validated behaviour, releases to historical evidence, and teams to operational confidence. It allows organisations to move forward knowing that, if something fails, there is a system capable of detecting it before the impact becomes irreversible.
The challenge is that during a migration, the net moves as well. Frameworks change, architectural layers disappear, programming languages evolve. If the net is woven from the same threads as the technology being replaced, the leap stops being controlled and becomes structurally risky.
The cost of losing that net is not limited to rewriting tests. It is the time required to rebuild confidence. It is the slowdown of the roadmap while revalidating what had already been validated. It is temporary exposure to undetected behaviour. In economic terms, it is the destruction of accumulated validation capital.
The previous cases illustrate that the real challenge is not moving tests between technologies. It is preserving the net while the trapeze artist moves bars.
Keeping functional intent intact
The enabling strategy is clear: decouple meaning from implementation. Preserve functional intent, traceability, and semantic coherence, intervening only where technology acts as the intermediary. Migrate engines, not behaviour. Translate language, not knowledge.
When this separation exists, the net does not break. It adapts.
In this context, artificial intelligence does not replace the team that designs the leap. It acts as an efficiency mechanism to reinforce the net while it is being reconfigured. It can accelerate the reconstruction of interaction layers, assist in translating behaviour across stacks, rationalise scenario catalogues, and reduce the mechanical effort of transformation. It does not decide what must be preserved, but it lowers the cost of preserving it.
The difference between a migration that erodes confidence and one that strengthens it does not lie solely in the new architecture. It lies in the ability to keep the net alive while the change takes place.
Modernising is not only about reaching the next platform. It is about doing so without falling during the transition.
Conclusion: Modernisation that preserves value
The testing network is not a secondary technical artefact. It is the asset that encapsulates years of validated behaviour, traceability and structured evidence. Destroying and rebuilding it at every transformation is not evolution. It is resetting accumulated capital.
The real cost of migration is not only in new development. It lies in losing and reconstructing what was already proven.
Organisations that separate functional intent from technological implementation can evolve without breaking continuity. They can transform architecture without restarting their quality baseline.
Artificial intelligence accelerates the process, reduces mechanical effort and optimises adaptation. But the strategic advantage is not in the tool. It is in the decision to keep the network that sustains the product alive.
Successful modernisation is not about changing platforms. It is about doing so without sacrificing the confidence built over years.
