67 production robots moved to Linux — while $8.4M in annual economic value kept flowing through every one of them
How a tier-1 bank ran a full Linux infrastructure migration across its entire robot estate without interrupting a single business process — and grew the programme to 120 robots on the other side.
Banking · Regulated banking · Orchestrator · Studio · Robot · 12-min readAbout the customer
A tier-1 banking group operating across retail, corporate, and investment banking. The group first deployed software robots in 2018, starting with financial reporting automation, and built one of the larger enterprise RPA programmes in regulated banking over the years that followed.
In 2021, the bank ran a structured platform evaluation: all available enterprise RPA platforms were assessed against 150 criteria across seven dimensions — architecture, security, total cost of ownership, and integration capability among them. Primo ranked at the top of that evaluation. The bank introduced Primo alongside the existing platform and ran both in parallel through the transition. By 2023, the full switch to Primo was complete: 120 production robots running across more than 200 business processes, freeing more than 350 FTE-equivalent capacity across the organisation.
The processes Primo automates cover the document-heavy, regulated parts of banking — foreign trade contract handling, electronic archiving, KYC case assembly, branch back-office reconciliation — and the high-volume internal operations that do not appear on customer-facing dashboards.
Linux was the strategy — and the robots couldn't stop while it happened
The bank's server estate was already predominantly Linux — consolidated for per-VM licensing cost, security hardening baseline, and unified operational standards. A structured programme was working through 45+ information systems. The RPA workload was the last significant Windows dependency in it.
That last dependency was also the most critical. 67 production robots were running the most economically valuable parts of the automation programme — $8.4M in annual economic effect. Any migration approach that required downtime, even briefly, was off the table. The robots had to keep running while the infrastructure changed under them.
The architecture team had two requirements that ruled out most vendors. First: native Linux — not a containerised Windows layer. Several vendors' "Linux support" meant Windows under the hood with a thin compatibility wrapper; the team rejected this entirely. The activity library and connectors had to compile and run on Linux natively, without a shim. Second: full reversibility at every step. If any robot failed on Linux in production, the Windows version had to remain live and re-promotable without delay.
How the migration ran
Phase 1 — Inventory and parallel runtime
Every production robot was catalogued in Primo Idea Hub: business owner, integration points, dependencies, runtime environment, change history. The output was a sequenced migration order — which robots moved first, based on dependency depth and business criticality.
A Linux runtime environment was provisioned alongside the existing Windows fleet, connected to the same Primo Orchestrator instance. A single orchestrator managing both OS runtimes made the parallel phase possible without forking the platform or running two separate control planes.
Phase 2 — Robot-by-robot cutover
Each robot was redeployed to Linux, run in parallel against the Windows version, validated against a process-specific success rubric, and cut over. The cutover remained reversible throughout: the Windows version stayed live until Linux had demonstrably earned its keep on that specific robot.
Primo's cross-platform Studio meant developers did not rewrite workflows. The same workflow definition compiled for either runtime — the activity library is identical across operating systems. The work was validation, not redevelopment.
Robots touching legacy Windows-only applications via screen automation were moved to a hybrid configuration: orchestrator and core logic on Linux, the screen-interaction step on a minimal reserved Windows environment. This kept the Windows footprint contained without forcing legacy applications to migrate on the same timeline.
Phase 3 — Decommissioning
Once all 67 robots were running stably on Linux, the Windows fleet was decommissioned. The hybrid robots — those with a remaining screen-interaction dependency — continued on their split configuration.
What made the migration possible was that we never had a moment where the bank was running on a single runtime version. We always had Windows running until Linux had earned its keep on each specific robot. And the orchestrator did not care which one was answering the queue.
The numbers
What changed for the team
The CoE had been carrying a permanent operational tax for running on a non-strategic runtime — separate Windows patching cycles, separate audit scope, separate licensing renewals. That tax went to zero. The team that had been split between keeping the existing estate running and building new automations got a meaningful share of that capacity back.
A second-order effect was on the bank's broader infrastructure direction. The RPA programme had been an outlier: a Windows-only workload inside a server estate trending hard toward Linux. With the migration complete, RPA stopped being the argument against further Linux consolidation in adjacent areas and became part of the case for it.
The programme continued to grow. The team expanded the fleet from 67 to 120 robots — with the confidence that the runtime would not become a constraint again.
One orchestrator managing Linux and Windows in parallel
Deployment architecture — dual-runtime migration
What's next for this customer
The team is extending the automation programme into AI-assisted document processing — adding Primo AI Server to the same Linux fleet. The first target processes are the document-heavy banking workflows already running on RPA: foreign trade contract handling and compliance documentation, where AI Server adds extraction and gap-detection steps that previously required manual review.
At the infrastructure level, the approach used in this migration — parallel runtime, process-by-process validation, reversible cutover — has become the reference model for other large platform transitions inside the bank.