Migrating From HP UFT To Selenium: A Step-By-Step Guide
Many organisations still rely on HP Unified Functional Testing, now commonly known as Micro Focus UFT or OpenText UFT, for dependable regression coverage across web, desktop and enterprise applications. It remains familiar to testers, especially in Microsoft-heavy environments, but licensing costs, limited language flexibility and changing delivery practices often encourage teams to consider Selenium. Learn more about The Top Five Security Testing Tools For Net Applications.html.
Moving to Selenium is not a simple tool replacement. It is a test engineering transition involving framework design, test selection, skills, environments, reporting and maintenance. For Australian delivery teams working across Sydney, Melbourne, Brisbane or Perth, the migration also needs to account for distributed squads, local data obligations and the time-zone gaps that can affect shared test environments.
Establish The Migration Case
Begin by documenting why the organisation wants to move. Common drivers include UFT licence costs, slow execution, difficulty integrating with modern CI/CD pipelines, limited support for new browser capabilities and a shortage of experienced UFT specialists. Selenium WebDriver offers open-source browser automation, broad language support and strong integration with tools such as Jenkins, Azure DevOps, GitHub Actions and GitLab CI.
A clear business case should compare the current cost of ownership with the expected investment in framework development, training, infrastructure and ongoing maintenance. Selenium itself has no commercial licence fee, but a reliable implementation still requires engineering effort. Cloud browser platforms, parallel execution capacity, reporting tools and test data services may also create operating costs.
Include compliance and operational considerations early. An Australian bank may need evidence aligned with APRA expectations, while a government department may require systems and test data to remain within approved jurisdictions. The Australian Privacy Act also makes careless handling of customer information a serious concern. These factors influence whether tests can run in a public cloud, which identities can be used, and how screenshots, logs and reports are retained.
Audit And Prioritise Existing Tests
A UFT repository often contains a mixture of valuable business checks, duplicated scripts, obsolete scenarios and tests that are too fragile to automate. Do not migrate every action line by line. First, classify each test by business risk, execution frequency, stability, data complexity and suitability for browser automation.
High-value candidates usually include smoke tests, critical customer journeys, repeatable regression scenarios and workflows that must be checked after every release. Low-value candidates may include one-off scripts, tests that depend heavily on desktop pop-ups, or cases that duplicate effective unit and API coverage. A traceability matrix can connect requirements, UFT assets, proposed Selenium tests and defect history.
Map the existing UFT architecture as well as its test cases. Record shared functions, object repositories, environment variables, recovery scenarios, test data sources and integrations with ALM or other test management platforms. This inventory reveals hidden dependencies. A script that appears to test a web form may also rely on a local spreadsheet, a Windows service, a browser setting or a specific user profile.
Run a baseline before rewriting anything. Capture current pass rates, average duration, failure reasons and maintenance effort across several releases. This provides a realistic comparison later. Teams in Melbourne and Sydney may run the same suite against different environments, so separate infrastructure failures, application defects and automation defects rather than treating every red result as a product failure.
Design The Selenium Framework
Choose the programming language based on the team and the wider engineering ecosystem. Java, C#, Python and JavaScript or TypeScript are common options. C# can be a practical choice for a Microsoft-focused organisation already using .NET and Azure DevOps, while Java or TypeScript may align better with existing platform engineering standards. The best choice is the one the team can maintain consistently.
Build a framework around clear layers rather than copying UFT’s keyword structure. A typical design includes page or screen components, test data services, configuration management, reusable assertions, browser and driver setup, logging, reporting and test tagging. Page Object Model can help separate locators from business actions, though it should be used carefully. Overly large page classes become difficult to understand and often reproduce the same maintenance problem in a different form.
Use robust locator practices from the beginning. Prefer stable identifiers such as dedicated data attributes over long XPath expressions or visual text that changes frequently. Establish standards for waits, retries, screenshots, browser sessions and failure handling. Selenium should wait for meaningful application states rather than relying on fixed sleeps, which tend to create slow and unreliable suites.
Plan for modern browser automation. Selenium Grid, containerised runners and cloud device platforms can support parallel execution across Chrome, Edge, Firefox and Safari. WebDriver is suitable for browser interactions, while API clients, database utilities and service mocks can prepare data more quickly. Keeping setup and verification at the right testing layer reduces the number of slow end-to-end journeys.
Rebuild In Small, Useful Increments
Select a pilot that is important enough to prove value but contained enough to control risk. A login and core transaction flow may work well if it represents a genuine business path and has stable test data. Avoid choosing the largest end-to-end process first. The goal is to establish coding standards, pipeline execution, reporting and defect triage before expanding the scope.
For each selected UFT test, define the intended behaviour before writing Selenium code. Remove redundant steps, clarify assertions and decide which checks belong in unit, API, integration or UI tests. Convert the scenario into maintainable test cases rather than performing a mechanical translation from VBScript into another language.
Run the old and new suites in parallel for a limited period. Compare functional coverage, execution time, false failures, defect detection and diagnostic quality. When results differ, investigate the reason: the application may have changed, UFT may have masked a synchronisation issue, or the Selenium implementation may contain an incorrect assumption.
Make migration progress visible through useful measures. Track the percentage of critical scenarios automated, pass rate on clean builds, average duration, flaky-test rate, mean time to diagnose failures and maintenance hours per sprint. A “green” pipeline has little value if testers spend every morning rerunning unstable checks. Australian teams split between Perth and the eastern states should also define who owns overnight failures and how handovers are recorded.
Connect Quality To Delivery And Risk
Integrate the Selenium suite with the delivery pipeline in stages. Start with a small smoke pack on pull requests or deployment gates, then schedule broader regression runs after successful deployments. Publish screenshots, videos, logs and structured results so developers can investigate failures without reproducing every issue locally.
Use tags to separate smoke, critical path, regression, accessibility, cross-browser and extended tests. Parallelise independent scenarios, but do not create artificial concurrency where tests share accounts, records or environments. Reliable test data is often the deciding factor in automation success. Seed isolated data through APIs where possible, reset state between runs and avoid using production customer records.
Security should be part of the migration design rather than a late-stage check. Protect credentials in a secrets manager, mask sensitive values in reports and restrict access to test artefacts. Selenium does not replace security testing, so pair browser checks with dependency scanning, penetration testing and focused application assessments. Teams working on .NET applications can also review specialist guidance on [security testing tools](https://nfoc ussoftwaretesting.com/news/the-top-five-security-testing-tools-for-net-applications.html) when shaping a broader quality strategy.
Training and operating ownership need equal attention. A short workshop may introduce WebDriver APIs, but sustainable capability requires code review, framework documentation, pairing and agreed support arrangements. Recruitment can help where specialist skills are missing, while managed testing or mentoring can reduce delivery risk during the transition. Make the new framework part of normal sprint work instead of treating it as a side project for a single automation champion.
The migration can also be affected by local working patterns. A Brisbane team may share a platform with colleagues in Perth, and a public holiday in one state can change support coverage. A straightforward handover process, central dashboards and documented escalation paths keep test failures from waiting until the next morning or an “arvo” catch-up.
| Area | HP UFT | Selenium |
|---|---|---|
| Licensing | Commercial licensing and vendor agreements | Open-source WebDriver with related infrastructure costs |
| Primary strength | Integrated functional automation with a mature IDE | Flexible browser automation across languages and platforms |
| Best fit | Existing UFT estates and teams centred on its workflow | Agile, DevOps and CI/CD-oriented engineering teams |
| Language options | Primarily UFT’s established scripting model | Java, C#, Python, JavaScript and TypeScript |
| Maintenance model | Centralised tool features and object repositories | Team-owned framework, code standards and supporting tools |
| Scaling | Possible, but may require additional licensing and setup | Grid, containers or cloud execution support parallel runs |
| Migration risk | Existing scripts may hide technical and data dependencies | Poor framework design can create flaky, hard-to-maintain tests |
A controlled retirement plan should follow successful parallel running. Freeze new UFT development except for urgent coverage, migrate priority scenarios in waves, and keep an exception register for tests that remain temporarily on the legacy platform. Retire scripts only when equivalent coverage, evidence and ownership are confirmed. Preserve historical results where they support audit, release or incident analysis.
The strongest outcome is usually a balanced test portfolio rather than a Selenium-only estate. Selenium can handle valuable browser journeys, while unit tests, API checks, contract tests, performance tools and security assessments cover other risks more efficiently. This approach reduces the pressure on UI automation and gives delivery teams faster feedback.
Start by assessing your UFT repository, delivery pipeline and testing capability. A structured assessment can identify migration candidates, framework choices, skills gaps and compliance constraints before expensive rework begins. With a prioritised roadmap and practical engineering support, your organisation can move from legacy automation to a maintainable, scalable quality practice.