Upgrade, Move Up, or Leave? The Kofax Decision, Without the Sales Gloss
Capture and KTM are marked Discontinued. There’s no Capture 12 coming. You have four real options, and one of them is honestly “not yet.” Here’s how to pick, including what each path costs.
Get an independent read, freeCompare the options
The conversation you keep having
“Every conversation with the vendor turns into an upsell. I need someone to tell me what this actually costs.”
“Our AP invoices and remittances run on this stack. I can’t gamble them on a rushed platform decision.”
“We write off errors nobody can trace back. Migrating the same broken process to a new platform fixes nothing.”
Your four real options, side by side
1. Upgrade within Capture
- A real project: environment build, batch class regression testing, script remediation.
- All of it spent on a product that dies March 2027.
- Applies to 11.0/10.x → 11.1 moves.
2. Move Up to TotalAgility
- Migration project: rebuild batch classes as processes, retrain extraction, rewrite integrations.
- License cost offset by Tungsten’s formal Move Up incentive. Get current terms in writing.
3. Leave the Kofax stack
- Full re-implementation on another IDP/capture approach.
- No Move Up credits. You walk away from existing license value and 20 years of tuning.
4. Do nothing
- Nothing upfront. Then: no security patches, no OS/SQL compatibility fixes, no vendor escalation, on the system processing your invoices.
- Running past EOS by default, not by decision.
the real question isn’t which platform. it’s whether you decide this year or under 2027 deadline pressure.
Prefer the table view?
| Option | What it costs | Risk | Who it suits |
|---|---|---|---|
| 1. Upgrade within Capture (11.0/10.x → 11.1) |
A real project (environment build, batch class regression testing, script remediation) for a product that dies March 2027. | Buys ≤12 months | Teams with an urgent audit finding who need supported status now while the bigger decision is made. A bridge, never a destination. |
| 2. Move Up to TotalAgility | Migration project: rebuild batch classes as processes, retrain extraction, rewrite integrations. License cost offset by Tungsten’s formal Move Up incentive. Get current terms in writing. | Underscoping KTM rework is the classic failure mode | Organizations where document capture is core and volumes justify a modern document-intelligence platform. The vendor-supported long-term path. |
| 3. Leave the Kofax stack | Full re-implementation on another IDP/capture approach. No Move Up credits. You walk away from existing license value and 20 years of tuning. | Highest one-time effort | Organizations already committed to a platform consolidation where capture becomes a feature of a bigger system. |
| 4. Do nothing (run past EOS) |
Nothing upfront. Then: no security patches, no OS/SQL compatibility fixes, no vendor escalation, on the system processing your invoices. | Grows every year | Only defensible as a documented, time-boxed decision. Never defensible as a default. |
Want this table filled in with your numbers?
Free 60-minute session: your components, your dates, your options, and our honest read in writing. We’ve recommended all four paths before.
How big is the migration, really?
The honest answer: it depends almost entirely on your KTM layer, not your Capture layer. Rough sizing from our project history:
| Profile | Typical footprint | What drives the effort | Indicative timeline |
|---|---|---|---|
| Small | 1–5 batch classes, ≤2 document types, little KTM customization | Config rebuild, connector mapping, user acceptance | Weeks. Often a quarter end-to-end including testing |
| Medium | 5–20 batch classes, KTM classification + extraction, custom validation scripts, 2–4 integrations | KTM rework is the bulk: retraining classification, rebuilding locators as modern extraction models | One to two quarters; KTM scripting depth is the swing factor |
| Large | 20+ batch classes, multi-site scanning, heavy scripting, custom modules | All of the above, plus custom-module replacement and phased cutover by document type | Multi-quarter program. Phase by document class, never big-bang |
- Count your scripts. VB/WinWrap scripts and KTM validation rules don’t port. They get redesigned. The script inventory is the single best pre-migration investment.
- Weigh your extraction. Hand-tuned locators built over years usually get replaced, not migrated. Trainable extraction reaches better accuracy with far less rule maintenance. Effort saved, if you plan to retrain rather than transliterate.
- Count your integrations. Every export connector and downstream handoff needs mapping and testing. Count them before you estimate anything.
The part most migration pitches skip: your one chance to make 20 years of documents AI-ready
Your Capture/KTM environment has processed millions of documents and produced images plus a handful of index fields. Built for retrieval, not understanding. The extraction logic covers only the fields someone needed in 2009.
A migration forces you to touch every document type and field definition anyway. Done deliberately, the same project can:
- Replace rule-based locators with trainable extraction, so adding a field later becomes training, not a scripting project.
- Normalize your document taxonomy across sites while every batch class is on the table.
- Pull richer structured data (line items, tables, entities) from the same documents, so write-offs become traceable instead of mysterious.
- Build confidence scoring and human-in-the-loop validation as a designed workflow, so accuracy is measured instead of assumed.
None of this requires believing any AI marketing. Retrofitting it after the migration means touching everything twice. Building it in costs a design decision, not a second project.
What this looks like when it works
Fewer manual errors, by rebuilding instead of porting
A financial services back office processed high-volume customer documents with heavy manual indexing and correction. Rebuilding the extraction layer on trainable document intelligence (instead of porting old zone-and-locator rules) cut manual errors by 98% and returned 100+ hours a month of staff time. Compliance cared about the error number, not the speed.
Payback inside the support window
A mid-sized enterprise used its migration window to consolidate document types and retire per-document custom scripts. The rebuilt invoice and order flow delivered $50–70k in annual savings, and the migration paid for itself in 6–12 months, inside the gap between Limited Support and End of Support. That’s why starting in 2026 matters.
Questions everyone asks
Should I upgrade to Capture 11.1 first, then migrate?
Usually no. 11.1 buys supported status only until March 3, 2027, and costs a real regression-testing project. The same effort pointed at your destination platform gets you there once instead of twice. Exception: an urgent audit finding that requires supported software now, while the larger migration runs in parallel.
Does the Move Up incentive actually save money?
It reduces the licensing component: credits or discounts for existing Capture/KTM entitlements against TotalAgility. It does not reduce the migration services effort, which is usually the larger number. Get current terms in writing; they’re negotiated per account and change over time.
When is waiting actually the right call?
Three honest cases: the process Capture serves is being retired within 12–18 months; a larger ERP/ECM program will absorb capture before your risk tolerance runs out; or you’re on 11.1 with a small, isolated footprint and can use 2026 to decide properly. In every case, write the decision down with a date. “We’ll deal with it later” without a date is how you end up running unsupported capture in 2028.
How long does a typical migration take?
Small (a few batch classes, standard connectors): roughly a quarter. Medium (KTM projects, custom validation, several integrations): one to two quarters. Large multi-site with deep scripting: a phased multi-quarter program. Working backward from March/May 2027, a medium deployment should be scoping by mid-2026, which is now.
We rely on Kofax Import Connector. Does its 2028 date buy us time?
No. KIC 2.11 runs to March 2028, but it exists to feed Capture, which loses support in March 2027. An import layer with nothing supported behind it isn’t a plan. Treat the Capture/KTM dates as your deadline.
Automation work like yours, delivered
Real engagements from the portfolio: same platforms, same problems.
Get a written recommendation in 60 minutes
We inventory your footprint, map it against the 2027 dates, and hand you a one-page recommendation (upgrade, Move Up, leave, or wait) with the reasoning attached. Free, no pitch, yours to keep.
Dates from the Tungsten Software Lifecycle Policy v12 and sunset schedule. Kofax rebranded to Tungsten Automation in January 2024; contracts and lifecycles were unchanged. Verify current dates and Move Up terms with Tungsten before contracting.