If your organization still runs document capture on Kofax Capture and Kofax Transformation Modules (KTM), you have probably been told that TotalAgility is where the platform is going. Kofax is now Tungsten Automation, Kofax Capture is sold as Tungsten Capture, and new development is focused on TotalAgility. Sooner or later, the question becomes how to move.
The first thing to know is that a migration is not a straight copy. Tungsten provides migration tooling and a migration guide, and some parts of your solution do carry over. Others have to be rebuilt, and a few are better retired. This note walks through which is which, based on our experience moving capture solutions between these products. Always check the details against Tungsten’s migration guide for the release you are moving to.
Two different ways of thinking
Kofax Capture is built around batches moving through a fixed series of modules: scan, recognition, validation, verification, export. Each batch class defines its own path through those modules, and customization happens by adding custom modules, workflow agents, and scripts at points along the way.
TotalAgility is a process platform. Capture is one part of a business process that can also include decisions, approvals, integrations, and people outside the capture team. Instead of a module sequence, you design a process map, with activities, forms, rules, and integration steps.
That difference explains most of what follows. Anything that describes your documents tends to move well. Anything that depends on Kofax Capture’s module pipeline or its scripting object model has to be translated into TotalAgility’s way of working.
What usually carries over
- Document classes and index fields. The definitions of what you capture, the document types and the fields on each, map naturally to TotalAgility document types and fields.
- KTM projects. TotalAgility uses the same transformation technology for classification and extraction, so the bulk of a KTM project (classes, locators, formatters, validation rules) can usually be brought across in some fashion. However, some elements, especially custom code will have to be adjusted for TotalAgility. Expect to test and adjust it rather than rebuild it.
- The shape of each batch class. The migration tooling gives you a starting point that reflects your existing structure, which you then refine into a TotalAgility process.
What usually needs rework or a rebuild
- Custom modules and workflow agents. These were written against Kofax Capture’s pipeline. In TotalAgility, the same jobs become process activities, .NET components, or integration steps.
- Scripts that use the Kofax Capture object model. Validation and recognition scripts that read or set batch fields, folders, or Capture-specific properties need to be rewritten for TotalAgility. KTM scripts that only work on document fields generally need less change than those that reach into the batch.
- Export connectors. Release scripts to databases, content management systems, and business applications are rebuilt as TotalAgility export or integration activities. This is often where the most hidden business logic lives.
- Validation and verification screens. Custom validation forms become TotalAgility forms. It is a good moment to simplify them.
- Separation and scanning setup. Patch codes, separator sheets, barcode rules, scan profiles, and scanner stations all need to be set up again in TotalAgility’s capture configuration and tested with your real paper.
- Users, groups, and queues. Who works on which batches becomes TotalAgility resources, roles, and work queues.
- Reports and monitoring. Anything that queried the Kofax Capture database directly, or relied on its analytics, needs a TotalAgility equivalent.
What to retire instead of migrating
Every long-lived capture environment collects things nobody uses: batch classes for processes that ended, document types that never arrive, scripts written to work around a limitation that no longer exists. Moving them costs money and adds risk. An inventory, checked against real volumes, usually shows a meaningful share of the environment that can be switched off instead of migrated.
Start with an inventory
Before any estimate means anything, list what you actually have. A useful inventory covers:
- Batch classes, with monthly volumes for each, so you know what matters most
- Document classes, form types, and index fields
- KTM projects, and which batch classes use them
- Custom modules and workflow agents, and what each one does
- Scripts, by batch class and by event, and whether anyone still understands them
- Export connectors, their targets, and any database tables or file formats they depend on
- Separation methods: separator sheets, patch codes, barcodes, page counts
- Scanning: stations, scanners, profiles, and who scans
- Users, roles, and queue assignments
- Integrations: lookups, databases, content management, line-of-business systems
- Service levels, peak periods, and reports people rely on
Expect surprises. The most common ones we see are scripts nobody remembers writing, hard-coded file paths and connection strings, export connectors tied to a specific database schema, and recognition settings tuned years ago for documents that have since changed.
Plan a migration that keeps production running
- Move in phases. One process or department at a time is usually safer than a single cutover, and it lets the team learn TotalAgility on a smaller scale first.
- Run old and new side by side. Process the same real documents through both systems and compare the results field by field, until the new solution matches or beats the old one.
- Plan the cutover. Freeze changes on the old system, let open batches finish, switch scanning and exports to TotalAgility, and keep a way back until the new process has run cleanly through a busy period.
- Review licensing and infrastructure early. TotalAgility is licensed and deployed differently from Kofax Capture. Talk to your Tungsten account team and plan the servers, databases, and environments (development, test, production) before the build starts.
- Hand over properly. Document the new solution and train the people who will support it, so you don’t end up with another system only one person understands.
How long does it take?
It depends far more on what is in your environment than on its size. A few batch classes with standard exports can move quickly. Many custom modules, heavily scripted validation, and exports into several business systems take longer. After an inventory, a written plan with a realistic timeline is possible; before it, any number is a guess.
The short version
- What describes your documents (document types, fields, KTM projects) mostly carries over.
- What depends on Kofax Capture’s pipeline (custom modules, Capture scripts, export connectors, scanning setup) is rebuilt.
- A good share of an older environment can be retired instead of migrated.
- An inventory comes first, then a phased plan with side-by-side testing on real documents.
If you would like a second opinion on your own environment, our Kofax Capture and KTM migration work starts with exactly this inventory and plan.
Founder of Skiff & Associates Consulting and a former Kofax engineer, with more than 20 years in document capture on Kofax and IBM platforms. More about John