TL;DR: Microsoft is removing VBScript, the language every UFT One test is written in, from Windows. The official Microsoft timeline disables it by default around 2026 to 2027 and removes it entirely after that. That puts a hard expiry date on every VBScript-based suite, and a deadline on your UFT migration. This guide covers what actually breaks and when, what staying costs, the three realistic exit paths, and a 90-day plan to get off UFT without gambling your release calendar.
Last updated: July 3, 2026
Quick answers
Is UFT One going away? UFT One itself is still sold and supported by OpenText. The problem is underneath it: Microsoft is retiring VBScript, the language UFT tests are written in, in three phases. Windows disables it by default in the 2026 to 2027 window, and removes it entirely after that. The product survives. Your scripts are the question.
What is the best way to migrate off UFT One? The fastest UFT migration path is regenerating tests from your application flows on an AI-native platform, at weeks per application instead of quarters. A manual rewrite to Playwright or Selenium gives you full code ownership and costs 6 to 18 engineer-months for a typical enterprise suite. Renewing UFT buys time and solves nothing.
Can UFT scripts be converted to another framework automatically? No reliable automatic converter exists. UFT tests depend on the object repository, VBScript idioms, and add-in specific behavior that do not map one-to-one onto any modern framework. Every credible migration starts from the user flows the scripts encode, not from the script files themselves.

Why UFT teams are planning their exit now
Two separate clocks started ticking on UFT One, and neither is controlled by the QA teams who depend on it.
The first is corporate. Micro Focus, UFT’s longtime owner, was acquired by OpenText for approximately $5.8 billion in January 2023. Within weeks, OpenText announced a workforce reduction of roughly 8 percent tied to the deal. UFT One is now one product inside a portfolio of hundreds at a company built on acquiring mature software and running it for margin. That is a fine business model. It is not a model that produces the engineering investment a testing tool needs to keep pace with AI-assisted development.
The second clock is technical, and it is the one with a hard stop. UFT tests are VBScript. Microsoft has been telling developers since 2023 that VBScript is finished, and as The Register put it in September 2025, Microsoft keeps reminding everyone that VBScript really is going away. The deprecation is not a rumor or a maybe. It is a published, phased removal plan for the language your regression suite is written in.
What happens to UFT scripts when Microsoft removes VBScript?
They stop executing. Not gradually, not partially. A UFT One suite is VBScript from the first line to the last, and a Windows image without VBScript has nothing to run it with.
The phases matter for planning. In the current phase, VBScript ships with Windows 11 as a Feature on Demand and stays enabled, so suites run normally and the risk hides. In the second phase, which Microsoft schedules for approximately 2026 to 2027, VBScript is disabled by default. Every workstation, every CI runner, every fresh VM image in your test grid then needs the feature manually re-enabled before a single test runs. IT teams that image machines at scale know exactly how much silent breakage that produces. In the final phase, the VBScript libraries are removed from Windows entirely, and re-enabling stops being an option.
Here is the planning reality: an enterprise UFT migration takes 6 to 18 months. Phase 2 has already begun rolling out inside the same window. Teams that start planning when the first CI runner fails have started too late.
Is UFT One still supported in 2026?
Yes. OpenText sells and supports UFT One today, and nothing in this article says otherwise. Support is not the issue. Economics and dependency are.
On cost: OpenText does not publish UFT pricing. User-reported figures on PeerSpot put UFT licensing at roughly $8,000 to $10,000 per user license, before the annual support contract on top. A ten-seat team is carrying a six-figure licensing line for a tool whose scripting language has a published removal date. That is the number to bring to the renewal conversation, because every renewal is now a decision to spend that budget on borrowed time.
The dependency math is worse than the license math. Renewal does not stop the VBScript clock, because that clock belongs to Microsoft, not OpenText. Whatever OpenText ships next, the VBScript assets you own today still have to run on Windows machines that are scheduled to lose VBScript.
What are the best UFT One alternatives in 2026?
There are exactly three realistic paths, and the right one depends on how much engineering capacity you can spend and how fast you need to be out. I compared the full tool landscape in our 15 best test automation tools guide; this section is specifically about the UFT migration itself.
Path A: Renew and wait
Renewing is the default because it requires no decision. It is also the only path that leaves you exposed to both clocks at once: you keep paying per-seat licensing at the numbers above, and your VBScript dependency keeps aging toward the removal date. Renew once more if your UFT migration plan needs the runway. Renew on autopilot and you are funding the problem instead of solving it.
Path B: Rewrite in Playwright or Selenium
The open source path trades money for engineering time. Playwright is the momentum choice: it runs at over 30 million weekly npm downloads in 2026, more than ten times selenium-webdriver. Selenium remains the right call for teams with deep Java or C# investment. Either way you own every line, pay no license, and inherit the full maintenance burden that comes with hand-written UI automation, including the flaky test triage that consumes automation teams.
Budget honestly: a UFT migration by rewrite is a re-authoring project, not a port. Our Selenium to Playwright migration guide covers the mechanics for teams already on open source; coming from UFT, add the object repository unwinding on top. For a typical enterprise suite that lands at 6 to 18 engineer-months, and the old suite needs feeding the whole time.
Path C: Regenerate on an AI-native platform
The third path skips the script-to-script translation entirely. Instead of rewriting 800 VBScript files, you rebuild coverage from what those files actually encode: user flows. On an AI-native platform you record or describe each flow in plain English, the platform generates and runs the tests, and self-healing locators absorb the UI changes that used to mean object repository triage. Coverage rebuilds in weeks per application because flows number in the dozens where scripts number in the hundreds.
The honest trade-off is vendor dependency, and the honest answer to it is an exit clause you can verify: pick a platform that gives you exportable test code, so the work you build is portable if you ever leave. That is the exact lock-in lesson UFT just taught the industry. Do not relearn it with a newer logo.
Can you convert UFT scripts to Playwright or Selenium automatically?
No. There is no converter that reliably turns UFT scripts into working Playwright or Selenium code, and the reason is structural. A UFT test is not self-contained: it leans on the object repository for element identification, on VBScript-specific idioms for logic, and on per-technology add-ins for application access. A modern framework has none of those constructs, so a line-by-line translation produces code that compiles and then fails on contact with the application.
Every UFT migration that works starts one level up, at the flow the script encodes. “Log in as a claims adjuster, open a claim, approve it, verify the status change” is portable. The 400 lines of VBScript implementing it are not. Inventory the flows, rank them by business risk, and rebuild the flows. Whether you rebuild them by hand in code (Path B) or generate them on a platform (Path C) is the real decision, and it is a validation coverage decision, not a syntax one.
How long does a UFT migration actually take?
For a typical 800-test enterprise suite: about 8 months with 3 dedicated engineers on a manual rewrite, or weeks per application when regenerating flows on an AI platform. Here is the math behind both numbers.
The left column understates the true cost of a rewrite in one important way: it counts the build and ignores the bleed. Through all 8 months, the legacy suite still runs, still breaks, and still needs the specialists who were supposed to be doing the migration. Teams consistently discover that the parallel-maintenance period, not the rewrite itself, is what stretches 8 months into 14.
The right column is not magic. It is a different unit of work. An 800-script suite typically encodes 60 to 120 distinct business flows, because scripts accumulate as copies with variations. Rebuild at the flow level and the workload shrinks by an order of magnitude before anyone writes or generates anything.
How do you evaluate a replacement without betting the release calendar?
Run a scoped proof of concept on your own applications, not the vendor’s demo app. Take one real application, pick its 10 highest-risk flows, and rebuild them on the candidate platform in a fixed two-week window. Measure four things: how long each flow took to automate, how many survived the next real UI change untouched, what the failure diagnostics actually told you, and whether your existing team did the work without vendor hand-holding.
Insist on seeing enterprise technology coverage during the trial, not on a slide. If your UFT suite touches SAP, Salesforce, or Citrix-delivered apps, those are the flows to pilot first, because they are where legacy tools earn their keep and where thin modern tools quietly fail. Our AI testing platform buyer’s guide has the full 12-question evaluation checklist for this stage.
Where ContextQA fits in a UFT exit
ContextQA is built for exactly the Path C profile: tests created from plain-English flow descriptions or recordings, self-healing maintenance instead of object repository upkeep, and coverage across web, mobile, API, and the enterprise apps UFT teams actually test. Two design decisions matter specifically for former UFT teams. First, tests are portable: ContextQA exports real code, so the no-lock-in requirement above is a feature, not a negotiation. Second, the same platform tests AI agents and LLM features, which is the workload arriving on QA teams right as the legacy tooling ages out.
The UFT migration motion is the flow-based one this article describes: inventory the flows your UFT suite encodes, rebuild the highest-risk flows first in plain English, run both suites in parallel for one release cycle, then retire the VBScript. Teams doing this app by app get each application off UFT in weeks. Book a demo and bring your gnarliest UFT flow to the call; building it live is the fastest way to judge whether the claim holds for your stack.
The 90-day UFT exit plan
Days 1 to 30: Inventory and rank. Extract the business flows from your UFT suite. Expect 60 to 120 flows per 800 scripts once duplicates and variations collapse. Rank them by revenue risk and change frequency. Kill the tests nobody can explain; every legacy suite carries dead weight, and migrating it is paying to move garbage.
Days 31 to 60: Pilot on one real application. Choose the path (rewrite or regenerate) and prove it on your highest-risk application using the two-week POC structure above. Exit criteria before you start: automation time per flow, survival rate through one UI change, and diagnostics quality. A pilot without pre-agreed exit criteria is a demo.
Days 61 to 90: Scale and set the retirement date. Roll the winning approach across the next two applications, run old and new suites in parallel for one full release cycle, and put a written VBScript retirement date on the calendar that lands before Microsoft’s Phase 2 reaches your Windows fleet. A UFT migration without a retirement date is a second suite you now maintain forever.
Common UFT migration mistakes to avoid
Five failure patterns show up in almost every stalled UFT migration, and all five are avoidable.
Converting scripts one to one. Teams that try to translate 800 VBScript files into 800 Playwright files inherit a decade of duplication and dead weight in a new syntax. Migrate flows, not files.
Migrating everything. Every mature suite carries tests nobody can explain. If a test has not caught a real defect in a year and nobody owns it, retire it instead of paying to move it.
Skipping the parallel run. Cutting over without one full release cycle of old and new suites running side by side turns your first post-migration release into the validation you skipped.
Ignoring the people plan. Your UFT specialists know the application better than anyone. A plain-English platform keeps that knowledge working; a code-only rewrite benches it until they retrain.
Running a pilot without exit criteria. Decide the pass bar before the trial starts: automation time per flow, survival through one UI change, and diagnostics quality. Otherwise the pilot is a demo.
The UFT migration checklist
The condensed version of this guide, in execution order. Copy it into your planning document.
1. Confirm your VBScript exposure: count workstations and CI runners that execute UFT suites. 2. Pull your renewal date and per-seat spend; that is your decision deadline and your budget baseline. 3. Extract the business flows from the script inventory; expect roughly one flow per seven scripts. 4. Rank flows by revenue risk and change frequency; retire the unexplainable ones. 5. Choose the path: rewrite for maximum ownership, regenerate for maximum speed. 6. Run the two-week pilot on your hardest application with written exit criteria. 7. Verify enterprise coverage live: SAP, Salesforce, Citrix, whatever your suite actually touches. 8. Demand exportable test code in the contract before signature. 9. Parallel-run old and new suites for one full release cycle. 10. Put the VBScript retirement date in writing, before Microsoft’s Phase 2 reaches your fleet.
How do you sell the UFT migration internally?
The engineering case is made above; the budget case needs three numbers and one sentence.
The three numbers: your annual UFT spend at $8,000 to $10,000 per seat, the engineer-hours currently consumed by object repository maintenance, and the date Microsoft disables VBScript by default. The sentence: “We can migrate on our schedule now, or on Microsoft’s schedule later, and later costs more.” Finance responds to deadlines with owners attached, and this one has a vendor-independent deadline published by Microsoft itself.
Expect the incumbent counter-offer: OpenText discounts at renewal when migration risk appears on the account. Price it against the math in this guide, because a discounted license does not stop the VBScript clock; it just makes the waiting room cheaper. The UFT migration decision is ultimately a timing decision, and every quarter of delay transfers negotiating power from you to the calendar.
The bottom line
UFT One is not dying this quarter, and nobody serious should tell you it is. But the language it runs on has a published removal plan from Microsoft, the vendor behind it is optimizing a mature portfolio rather than racing AI-assisted development, and the per-seat economics only make sense for capability you cannot get elsewhere. That capability gap has closed. The teams moving now are not panicking; they are reading two very public clocks and choosing to run their UFT migration on their own schedule instead of Microsoft’s. Start the flow inventory this month, run the pilot next month, and make the renewal conversation a formality instead of a hostage negotiation.
Sources
- Microsoft Windows IT Pro Blog: VBScript deprecation, timelines and next steps. The official three-phase removal plan.
- PR Newswire: OpenText buys Micro Focus. The $5.8 billion acquisition announcement, January 2023.
- BetaKit: OpenText closes Micro Focus acquisition, makes workforce reduction. The roughly 8 percent post-acquisition reduction.
- The Register: Microsoft reminds developers VBScript really is going away. September 2025 coverage of the deprecation.
- PeerSpot: user-reported UFT One pricing and costs. The $8,000 to $10,000 per license figures.
- npm trends: Playwright vs selenium-webdriver weekly downloads. Live adoption data.