TotalAgility: The Clarity Series • 5 min read

TotalAgility: Cloud vs. On-Premise - How to Choose Your Architecture for Long-Term Scalability

Should you choose Tungsten TotalAgility Cloud or On-Premise? Choose Tungsten TotalAgility Cloud (SaaS) if you want to offload Windows Server, SQL database, and upgrade maintenance to Tungsten’s managed Azure infrastructure. Choose TotalAgility On-Premise (or Customer-Hosted Private Cloud) if your workflows depend on real-time local database queries, server-level custom .NET/COM libraries, direct SQL access to system tables, or strict data-residency rules that prohibit documents from leaving your private network.

When an architecture board is torn between Tungsten TotalAgility (TTA)—formerly Kofax TotalAgility (KTA)—in the Cloud versus On-Premise, the worst mistake is deciding based on initial license price alone. Here is the practical decision framework we use in our Tungsten TotalAgility consulting and architecture reviews.

1. The Baseline: What Actually Changes Between Cloud and On-Premise?

Before diving into workflows, clarify who owns what in each model:

• TotalAgility Cloud (SaaS): Tungsten manages the servers, Azure SQL databases, storage, high availability, and platform upgrades. Your team focuses on workflow design, business rules, and connecting external systems through supported interfaces.

  
  

• TotalAgility On-Premise (Customer-Hosted): You manage the Windows servers, SQL Server databases, clustering, backups, and version upgrades—even if you host those virtual machines inside your own corporate AWS or Azure tenant.

2. The 3-Question Decision Framework for Architecture Boards

If your team is on the fence between Cloud and On-Premise, start by answering these three operational questions:

Question 1: Do you have a dedicated DBA and Windows Server infrastructure team?

If No → Go to the Cloud. Running a multi-node enterprise TotalAgility cluster requires ongoing Windows Server patching, SQL Server index and archive maintenance, load-balancer tuning, and disaster recovery testing. If your IT team doesn't want to own that day-to-day infrastructure burden, the SaaS model safely offloads it.

Question 2: Does your process require real-time, low-latency queries against on-premise legacy databases?

If Yes → Customer-Hosted (On-Premise or Private Cloud) is usually more efficient. While TotalAgility Cloud can talk to local systems through an on-premise Integration Server, constant synchronous lookups across firewalls introduce network latency. Keeping the platform close to your heavy legacy databases avoids building complex cross-network tunnels for every keystroke validation.

Question 3: Are you in a regulated sector with strict private-network data residency mandates?

If Yes → On-Premise remains the standard. TotalAgility Cloud is highly secure (including FedRAMP High authorization in the US and enterprise encryption standards). However, if your internal InfoSec policy in Defense, Government, or specialized Healthcare strictly mandates that unredacted documents can never leave your private network perimeter, self-hosted On-Premise is the clear path.

3. Three Architectural Realities of TotalAgility Cloud

If the three questions above point you toward the Cloud, remember that patterns built for a local server behave very differently in a multi-tenant SaaS environment. Before migrating an existing KTA system or designing a new workflow, audit your architecture against these three realities:

Reality 1: ERP Validation Boundaries Shift from Real-Time to Asynchronous

• How It Works On-Premise: A Business Rule or form event instantly queries your local ERP database on the same network to validate a vendor, PO number, or invoice line item while the operator types.

  
  

• How It Works in the Cloud: Your corporate firewall sits between TotalAgility Cloud and your on-premise ERP. To bridge this securely without opening inbound firewall ports, you deploy a local TotalAgility Integration Server in your data center or synchronize ERP master data to the cloud.

  
  

• The Architectural Adjustment: Because Integration Server operations execute across network boundaries (often asynchronously), you should adjust your process maps so heavy ERP validations run as background workflow steps rather than blocking real-time UI events.

  
  

Reality 2: The Custom Code Sandbox

• How It Works On-Premise: Developers have full administrative access to the application servers—installing third-party PDF manipulation tools, legacy COM objects, or custom .NET DLLs that read and write directly to the local Windows file system.

  
  

• How It Works in the Cloud: SaaS environments are strictly sandboxed for security and stability. You cannot install executables on the cloud hosts, touch the local file system, or drop unsupported third-party libraries onto the managed servers.

  
  

• The Architectural Adjustment (Keep, Move, or Modernize): You don't have to abandon custom code, but you must classify every custom dependency before migrating:

  
  

  • Keep: Native TotalAgility expressions and cloud-supported configurations

    
    

  • Move: Supported .NET DLLs and WCF/REST calls that can execute cleanly on your local Integration Server.

    
    

  • Modernize: Legacy COM components or file-system utilities, which must be refactored into external REST Web APIs. Our TotalAgility application development and integration team regularly re-engineers these legacy extensions for cloud readiness.

    
    

Reality 3: TotalAgility System Database Restrictions

• How It Works On-Premise: Your team owns the SQL Server instances. Writing direct SQL queries against TotalAgility system tables, building custom SQL views for troubleshooting, or connecting BI tools directly to the database schema is common operational practice.

  
  

• How It Works in the Cloud: To protect tenant isolation and platform performance, SaaS environments prohibit direct SQL access or schema changes on the underlying TotalAgility system and reporting databases.

  
  

• The Architectural Adjustment: Decouple your reporting and monitoring from raw SQL tables. Instead, pull operational data through supported public interfaces such as the TotalAgility SDK / REST APIs, scheduled data exports, or Tungsten Insight (KAFTA) analytics.

  
  

4. The Bottom Line: Assess Your Dependencies Before Picking a Label

Never choose between TotalAgility Cloud and On-Premise based on a sales brochure or initial license quote. Base your decision on your internal IT team’s capacity, the latency of your ERP integrations, and the footprint of your custom code and SQL dependencies.

If you are running an existing Kofax TotalAgility (KTA) or Capture environment and want to know exactly which workflows, DLLs, and database calls would need refactoring for the Cloud, running an automated scan with TA Audit gives your architecture board a complete dependency map before you commit to a TotalAgility migration or upgrade.

TotalAgility Cloud vs. On-Premise FAQ

What is the main difference between TotalAgility Cloud and On-Premise?

TotalAgility Cloud is a fully managed SaaS platform hosted by Tungsten on Microsoft Azure where the vendor manages servers, databases, and upgrades. TotalAgility On-Premise is customer-managed (on local servers or your own AWS/Azure VMs), giving your team full control over infrastructure, custom DLLs, and SQL databases.

Can TotalAgility Cloud connect to on-premise ERP systems and databases?

Yes—TotalAgility Cloud connects securely to on-premise ERPs (like SAP, Oracle, or Dynamics) and local databases over HTTPS/TLS using a customer-hosted TotalAgility Integration Server or by synchronizing master data to the cloud.

Can I run custom .NET code and third-party DLLs in TotalAgility Cloud?

While you cannot install arbitrary executables or file-system utilities directly onto the sandboxed SaaS servers, you can execute supported custom .NET assemblies and WCF/REST services through a local Integration Server or externalize them as Web APIs.

Can I run direct SQL queries against the TotalAgility Cloud database?

No—direct SQL access and custom schema modifications on the underlying TotalAgility system databases are restricted in the SaaS environment. Teams must use the TotalAgility SDK/API, scheduled data exports, or Tungsten Insight for custom reporting.

How do I know if my existing Kofax TotalAgility environment is ready for the Cloud?

Before migrating to TotalAgility Cloud, conduct an architecture assessment using a diagnostic tool like TA Audit to inventory all custom .NET DLLs, local file-system paths, synchronous ERP lookups, and direct SQL reporting dependencies that require refactoring.