67 robôs de produção migrados para Linux — enquanto $8.4M em valor econômico anual continuava fluindo por cada um deles
Como um banco Tier-1 executou uma migração completa de infraestrutura Linux em todo o seu conjunto de robôs sem interromper um único processo de negócio — e expandiu o programa para 120 robôs do outro lado.
Bancos · Bancos regulamentados · Primo Orchestrator · Primo Studio · Primo Robot · Leitura de 12 minAbout the customer
Um grupo bancário Tier-1 que opera em bancos de varejo, corporativos e de investimento. O grupo implantou robôs de software pela primeira vez em 2018, começando com automação de relatórios financeiros, e construiu um dos maiores programas RPA empresariais em bancos regulamentados nos anos seguintes.
Em 2021, o banco realizou uma avaliação estruturada de plataformas: todas as plataformas RPA empresariais disponíveis foram avaliadas com base em 150 critérios em sete dimensões — arquitetura, segurança, custo total de propriedade e capacidade de integração, entre elas. A Primo ficou no topo dessa avaliação. O banco introduziu a Primo ao lado da plataforma existente e executou ambas em paralelo durante a transição. Em 2023, a mudança completa para a Primo estava concluída: 120 robôs de produção rodando em mais de 200 processos de negócio, liberando mais de 350 FTE de capacidade equivalente em toda a organização.
Os processos que a Primo automatiza cobrem as partes regulamentadas e com muitos documentos dos bancos — tratamento de contratos de comércio exterior, arquivamento eletrônico, montagem de casos KYC, reconciliação de back office de agências — e as operações internas de alto volume que não aparecem nos painéis voltados ao cliente.
Linux era a estratégia — e os robôs não podiam parar enquanto isso acontecia
O parque de servidores do banco já era predominantemente Linux — consolidado pelo custo de licenciamento por VM, linha de base de endurecimento de segurança e padrões operacionais unificados. Um programa estruturado estava avançando por mais de 45 sistemas de informação. A carga de trabalho RPA era a última dependência significativa do Windows nele.
Essa última dependência era também a mais crítica. 67 robôs de produção estavam executando as partes economicamente mais valiosas do programa de automação — $8.4M em efeito econômico anual. Qualquer abordagem de migração que exigisse tempo de inatividade, mesmo que brevemente, estava fora de questão. Os robôs tinham que continuar funcionando enquanto a infraestrutura mudava sob eles.
A equipe de arquitetura tinha dois requisitos que descartavam a maioria dos fornecedores. Primeiro: Linux nativo — não uma camada Windows em contêiner. O "suporte a Linux" de vários fornecedores significava Windows por baixo com um wrapper de compatibilidade fino; a equipe rejeitou isso completamente. A biblioteca de atividades e os conectores tinham que compilar e rodar no Linux nativamente, sem um shim. Segundo: reversibilidade total em cada etapa. Se algum robô falhasse no Linux em produção, a versão Windows tinha que permanecer ativa e ser repromocionável sem demora.
Como a migração foi executada
Fase 1 — Inventário e ambiente de execução paralelo
Cada robô de produção foi catalogado no Primo Idea Hub: proprietário do negócio, pontos de integração, dependências, ambiente de execução, histórico de mudanças. O resultado foi uma ordem de migração sequenciada — quais robôs se moveriam primeiro, com base na profundidade de dependência e criticidade do negócio.
Um ambiente de execução Linux foi provisionado ao lado da frota Windows existente, conectado à mesma instância do Primo Orchestrator. Um único orquestrador gerenciando ambos os ambientes de execução de SO tornou a fase paralela possível sem bifurcar a plataforma ou executar dois planos de controle separados.
Fase 2 — Transferência robô por robô
Cada robô foi reimplantado no Linux, executado em paralelo com a versão Windows, validado contra um critério de sucesso específico do processo e transferido. A transferência permaneceu reversível durante todo o processo: a versão Windows ficou ativa até que o Linux tivesse demonstravelmente cumprido sua função naquele robô específico.
O Primo Studio multiplataforma significou que os desenvolvedores não reescreveram os fluxos de trabalho. A mesma definição de fluxo de trabalho compilava para qualquer ambiente de execução — a biblioteca de atividades é idêntica em todos os sistemas operacionais. O trabalho era de validação, não de redesenvolvimento.
Robôs que tocavam aplicações legadas somente Windows via automação de tela foram movidos para uma configuração híbrida: orquestrador e lógica principal no Linux, a etapa de interação com a tela em um ambiente Windows mínimo reservado. Isso manteve a pegada do Windows contida sem forçar as aplicações legadas a migrarem no mesmo cronograma.
Fase 3 — Descomissionamento
Depois que todos os 67 robôs estavam rodando estavelmente no Linux, a frota Windows foi descomissionada. Os robôs híbridos — aqueles com uma dependência restante de interação com a tela — continuaram em sua configuração dividida.
O que tornou a migração possível foi que nunca tivemos um momento em que o banco estava rodando em uma única versão do ambiente de execução. Sempre tínhamos o Windows rodando até que o Linux tivesse cumprido sua função em cada robô específico. E o orquestrador não se importava com qual estava respondendo à fila.
The numbers
What changed for the team
O CoE havia carregado um imposto operacional permanente por rodar em um ambiente de execução não estratégico — ciclos separados de patches do Windows, escopo de auditoria separado, renovações de licença separadas. Esse imposto foi a zero. A equipe que havia sido dividida entre manter o conjunto existente funcionando e construir novas automações recuperou uma parcela significativa dessa capacidade.
Um efeito de segunda ordem foi na direção de infraestrutura mais ampla do banco. O programa RPA havia sido um caso atípico: uma carga de trabalho somente Windows dentro de um parque de servidores com tendência forte para Linux. Com a migração concluída, o RPA deixou de ser o argumento contra uma consolidação adicional do Linux em áreas adjacentes e se tornou parte do argumento a favor.
O programa continuou crescendo. A equipe expandiu a frota de 67 para 120 robôs — com a confiança de que o ambiente de execução não se tornaria uma restrição novamente.
Um orquestrador gerenciando Linux e Windows em paralelo
Deployment architecture — dual-runtime migration
What's next for this customer
A equipe está expandindo o programa de automação para o processamento de documentos assistido por IA — adicionando Primo AI Server à mesma frota Linux. Os primeiros processos-alvo são os fluxos de trabalho bancários com muitos documentos já rodando em RPA: tratamento de contratos de comércio exterior e documentação de conformidade, onde o AI Server adiciona etapas de extração e detecção de lacunas que anteriormente exigiam revisão manual.
No nível de infraestrutura, a abordagem usada nesta migração — ambiente de execução paralelo, validação processo por processo, transferência reversível — tornou-se o modelo de referência para outras grandes transições de plataforma dentro do banco.