Full-text search is the feature people only notice when it fails. A clerk types a vendor name she knows is on an invoice, gets nothing back, and goes looking in the paper file instead. After that, nobody trusts search, and the repository quietly turns into a filing cabinet with a login screen.
If your ApplicationXtender estate is on an older release, its full-text search runs on Xplore. Upgrade to AppEnhancer 24.2 or later and it doesn't. That change is easy to miss in a version plan, and it deserves its own line.
What OpenText changed
OpenText's 24-series summary calls IDOL's arrival in 24.2 “one of the biggest innovations of 2024 for AppEnhancer,” replacing what the same post calls “the out-dated Xplore.” IDOL is OpenText's indexing and search technology, which has its own place in the OpenText portfolio under the Knowledge Discovery name. Inside AppEnhancer it does a narrower job: it is the engine under indexing, viewing and rendering.
The post lists three practical effects:
Broader format coverage. IDOL works with a larger variety of document formats for indexing, viewing and rendering.
Full-text indexing on the new engine.
OCR in the viewer. In 24.4 that produced rubber-band OCR. A user draws a rectangle around a value on a scanned page, such as an invoice number, and grabs it as a metadata value for the document.
The 26.2 release webinar adds “unified rendering services” to the list, which continues the same consolidation.
Why this belongs in the upgrade plan, not the footnotes
Swapping a search engine is not the same as patching one. Even when the user-facing search box looks familiar, the work underneath is different. These are the questions we'd put to the project before it picks a weekend:
Full-text index — Will the existing full-text index be rebuilt on IDOL, and how long will that take at your document volume? Check the upgrade guide for your target release. Owner: AppEnhancer admin.
Servers — Does the new engine change server count, sizing or placement compared with your Xplore setup? Owner: Infrastructure.
Monitoring — What does “healthy” look like for the new indexing service, and who gets the alert when it isn't? Owner: Operations.
Search behavior — Do results come back in a different order, or match differently, for your most common searches? Owner: Department leads.
Formats — Which document types were never searchable before and now will be? Is that welcome, or does it raise access questions? Owner: Records / security.
Packaging — What, if anything, needs to be licensed or configured for IDOL in your agreement? Confirm with OpenText. Owner: Contract owner.
None of those is exotic. All of them are cheaper to answer before cutover than after a help-desk queue fills up.
Test with your own searches
Vendor demos use clean documents. Your repository has twenty years of skewed scans, faxed forms and PDFs generated by systems that no longer exist. So build a small test set before the upgrade:
Pull the 25 searches your heaviest users run most often. Ask them; don't guess.
Record what each returns today on Xplore, including the ones that fail.
Run the same searches in a test environment on the target release once the IDOL index is built.
Compare. Better recall is the usual hope. A different ranking or a surprising match is fine as long as somebody knows about it before go-live.
That last step also gives you the evidence for the steering committee. “Search improved” is a claim. “This many of our top 25 searches now return the right document first, compared with that many before,” filled in with your own counts, is a result.
Where rubber-band OCR earns its keep
For indexing-heavy teams, the rubber-band feature may matter more than full-text search. Manual indexing usually means reading a value off a scanned page and typing it into a field. Drawing a box and letting OCR fill the field removes a keying step and a class of typos. It won't replace a capture system for high-volume intake, and OpenText doesn't pitch it that way. For a records clerk correcting a few dozen documents a day, it's a real improvement.
What not to overread
The same OpenText post describes roadmap items that build on IDOL: barcode support, and IDOL's Eduction capability for summarizing documents and extracting key data as metadata. Those were roadmap statements in 2024. Some of that thinking shows up in the 26.2 release, which is covered separately. For an upgrade decision, plan around what your target release actually ships, and treat roadmap slides as roadmap.
The plain version: if you're moving off an older AX release, you're also moving off Xplore. Give the search engine its own test plan, its own owner and its own line in the cutover checklist. Search is the reason people open the repository at all.
