Let's start with the part everyone already knows. Ask a records clerk or an AP lead about ApplicationXtender and you'll hear that it works and that it looks its age. That reputation is fair for the screens most long-running estates still use. It's also out of date for anyone who has followed the last three release cycles.
The risk now isn't the old interface. It's planning an upgrade around folklore: either "the new UI fixes everything" or "the new UI breaks everything." Neither is what OpenText has published.
What has actually shipped
OpenText has been unusually open about this change on its community site. Read in order, the release notes form a timeline:
2024: fully web. The 24 series made AppEnhancer a fully web offering. OpenText's own summary says that lowers cost of ownership and brings security benefits, and it calls this the step that made the next one possible. That year the product team also ran design surveys with customers to test interface options.
25.2: the new UI arrives, Classic stays. The 25.2 notes list a new UI "built on OpenText JATO Framework," with "Classic mode available for existing users." OpenText describes JATO as an OpenText-wide initiative to bring in new, modern design components, so this isn't a one-off reskin for one product.
25.x: most of the heavy lifting. OpenText's 25-series recap says the move to JATO is happening in phases, that 2025 did most of the work, and that the web UI redesign would be fully completed by 26.2. It also says the Classic interface "will remain available for several releases" to allow a smooth transition.
26.2: JATO UI Phase III. The 26.2 release webinar lists JATO UI Phase III as its first topic. In the recorded session the product team describes running the new web client alongside the existing web access application for now, with the old application to be replaced once the full web UI is complete.
So it isn't one big switch. It's a staged replacement with an overlap period, and OpenText has said so plainly.
What changes for users, and what doesn't
What changes is the screen. Search, retrieval and document review move to the JATO-based web client. People who used the old interface every day will need some orientation, and the people who built cheat sheets for the old menus will need to rebuild them.
What doesn't change is the data. Applications (AppEnhancer's term for its document-type repositories), index fields, security and retention rules sit underneath the interface. A UI phase doesn't redesign your index scheme. That's worth saying out loud in the first steering meeting, because a common fear is that "new UI" means "re-index everything." (The search engine change that arrived in 24.2 is a separate item with its own plan, covered in a companion post.)
There's also a group of users who barely need the web UI at all. OpenText introduced a virtual printer in 24.2 and a new desktop connector in 24.4, rebuilt on REST and, in OpenText's words, taking indexing "from minutes to seconds." The 2025 releases added search, retrieval and an integrated viewer to that connector. Staff who mostly file documents can keep working from their desktop and their native applications.
Who still needs Classic, and for how long
The overlap period is useful only if you plan for its end. Before the upgrade, we'd get specific answers to four questions:
Which teams rely on screens, saved searches or habits that only exist in Classic? Name them. "Everyone" is never true.
Which customizations or integrations assume the old web access application? Anything that deep-links into it or scrapes it needs a test plan.
Who can live on the desktop connector or virtual printer instead? For filing-heavy roles, that's often the smoothest path.
What's your exit date for Classic? OpenText says "several releases." Your plan should name an actual one, confirmed with OpenText against the release you're targeting.
A rollout that respects the people using it
We'd stage it in three waves rather than a cutover weekend.
Wave one: the willing. Start with a team that searches more than it files and is open to change. Use their feedback to fix the training, not the product.
Wave two: the filers. Move indexing-heavy roles to the desktop connector or virtual printer, and keep their web UI use to lookup and review.
Wave three: the holdouts. By now the new UI has a track record inside your own organization. Retire Classic on the date you set, with the integrations already tested.
Throughout, keep one person accountable for collecting UI complaints and sorting them into training issues, configuration issues and real product gaps. OpenText runs customer UX surveys and design workshops for AppEnhancer; real gaps belong there, not in a hallway.
The honest summary
The old AX interface earned its reputation. OpenText has spent two release cycles replacing it, in phases, with an overlap period. That's a sensible way to change a tool people use every day, and it's best used deliberately. Upgrade to a release that carries the new UI, keep Classic only as long as you need it, and set the date it goes away.
