67 robots de producción migrados a Linux — mientras $8.4M en valor económico anual seguía fluyendo a través de cada uno de ellos
Cómo un banco Tier-1 ejecutó una migración completa de infraestructura Linux en todo su conjunto de robots sin interrumpir ni un solo proceso de negocio — y expandió el programa a 120 robots al otro lado.
Banca · Banca regulada · Primo Orchestrator · Primo Studio · Primo Robot · Lectura de 12 minAbout the customer
Un grupo bancario Tier-1 que opera en banca minorista, corporativa y de inversión. El grupo desplegó por primera vez robots de software en 2018, comenzando con la automatización de informes financieros, y construyó uno de los programas RPA empresariales más grandes en banca regulada en los años siguientes.
En 2021, el banco realizó una evaluación estructurada de plataformas: todas las plataformas RPA empresariales disponibles fueron evaluadas contra 150 criterios en siete dimensiones — arquitectura, seguridad, costo total de propiedad y capacidad de integración, entre ellas. Primo ocupó el primer lugar en esa evaluación. El banco introdujo Primo junto a la plataforma existente y ejecutó ambas en paralelo durante la transición. Para 2023, el cambio completo a Primo estaba terminado: 120 robots de producción ejecutándose en más de 200 procesos de negocio, liberando más de 350 FTE de capacidad equivalente en toda la organización.
Los procesos que Primo automatiza cubren las partes de la banca regulada con documentos intensivos — gestión de contratos de comercio exterior, archivo electrónico, ensamblaje de casos KYC, reconciliación del back office de sucursales — y las operaciones internas de alto volumen que no aparecen en los paneles de cara al cliente.
Linux era la estrategia — y los robots no podían detenerse mientras sucedía
El parque de servidores del banco ya era predominantemente Linux — consolidado por costo de licencias por VM, línea base de endurecimiento de seguridad y estándares operativos unificados. Un programa estructurado estaba avanzando a través de más de 45 sistemas de información. La carga de trabajo RPA era la última dependencia significativa de Windows en él.
Esa última dependencia era también la más crítica. 67 robots de producción ejecutaban las partes económicamente más valiosas del programa de automatización — $8.4M en efecto económico anual. Cualquier enfoque de migración que requiriera tiempo de inactividad, incluso brevemente, estaba descartado. Los robots tenían que seguir funcionando mientras la infraestructura cambiaba bajo ellos.
El equipo de arquitectura tenía dos requisitos que descartaban a la mayoría de los proveedores. Primero: Linux nativo — no una capa Windows en contenedor. El "soporte de Linux" de varios proveedores significaba Windows bajo el capó con un envoltorio delgado de compatibilidad; el equipo rechazó esto por completo. La biblioteca de actividades y los conectores tenían que compilar y ejecutarse en Linux de forma nativa, sin un intermediario. Segundo: reversibilidad total en cada paso. Si algún robot fallaba en Linux en producción, la versión Windows tenía que permanecer activa y ser repromocionable sin demora.
Cómo se ejecutó la migración
Fase 1 — Inventario y entorno de ejecución paralelo
Cada robot de producción fue catalogado en Primo Idea Hub: propietario del negocio, puntos de integración, dependencias, entorno de ejecución, historial de cambios. El resultado fue un orden de migración secuenciado — qué robots se movían primero, basado en la profundidad de dependencia y la criticidad del negocio.
Se aprovisionó un entorno de ejecución Linux junto a la flota Windows existente, conectado a la misma instancia de Primo Orchestrator. Un único orquestador gestionando ambos entornos de ejecución de SO hizo posible la fase paralela sin bifurcar la plataforma ni ejecutar dos planos de control separados.
Fase 2 — Cambio robot por robot
Cada robot fue redesplegado en Linux, ejecutado en paralelo con la versión Windows, validado contra un criterio de éxito específico del proceso, y transferido. El cambio se mantuvo reversible en todo momento: la versión Windows permaneció activa hasta que Linux había demostrado su valía en ese robot específico.
El Studio multiplataforma de Primo significó que los desarrolladores no reescribieron flujos de trabajo. La misma definición de flujo de trabajo se compilaba para cualquier entorno de ejecución — la biblioteca de actividades es idéntica en todos los sistemas operativos. El trabajo era validación, no redesarrollo.
Los robots que tocaban aplicaciones heredadas solo de Windows a través de automatización de pantalla fueron movidos a una configuración híbrida: orquestador y lógica principal en Linux, el paso de interacción de pantalla en un entorno Windows mínimo reservado. Esto mantuvo la huella de Windows contenida sin forzar a las aplicaciones heredadas a migrar en el mismo cronograma.
Fase 3 — Desmantelamiento
Una vez que los 67 robots estaban funcionando establemente en Linux, la flota Windows fue desmantelada. Los robots híbridos — aquellos con una dependencia restante de interacción de pantalla — continuaron en su configuración dividida.
Lo que hizo posible la migración fue que nunca tuvimos un momento en que el banco estuviera ejecutando en una única versión del entorno de ejecución. Siempre teníamos Windows funcionando hasta que Linux había ganado su lugar en cada robot específico. Y el orquestador no le importaba cuál estaba respondiendo a la cola.
The numbers
What changed for the team
El CoE había estado cargando un impuesto operativo permanente por ejecutar en un entorno de ejecución no estratégico — ciclos de parcheo de Windows separados, alcance de auditoría separado, renovaciones de licencias separadas. Ese impuesto llegó a cero. El equipo que había estado dividido entre mantener el conjunto existente funcionando y construir nuevas automatizaciones recuperó una parte significativa de esa capacidad.
Un efecto de segundo orden fue en la dirección de infraestructura más amplia del banco. El programa RPA había sido un caso atípico: una carga de trabajo solo de Windows dentro de un parque de servidores con tendencia fuerte hacia Linux. Con la migración completada, RPA dejó de ser el argumento en contra de una mayor consolidación de Linux en áreas adyacentes y se convirtió en parte del argumento a favor.
El programa continuó creciendo. El equipo expandió la flota de 67 a 120 robots — con la confianza de que el entorno de ejecución no volvería a ser una restricción.
Un orquestador gestionando Linux y Windows en paralelo
Deployment architecture — dual-runtime migration
What's next for this customer
El equipo está extendiendo el programa de automatización hacia el procesamiento de documentos asistido por IA — añadiendo Primo AI Server a la misma flota Linux. Los primeros procesos objetivo son los flujos de trabajo bancarios con documentos intensivos que ya se ejecutan en RPA: gestión de contratos de comercio exterior y documentación de cumplimiento, donde AI Server añade pasos de extracción y detección de lagunas que anteriormente requerían revisión manual.
A nivel de infraestructura, el enfoque utilizado en esta migración — entorno de ejecución paralelo, validación proceso por proceso, cambio reversible — se ha convertido en el modelo de referencia para otras grandes transiciones de plataformas dentro del banco.