Migrar a cloud en una fintech argentina no es lo mismo que migrar a cloud

Hay una conversación que se repite. Una fintech argentina con tres o cuatro años de operación, producto probado, base de clientes creciente, llega a un punto en que la infraestructura empieza a frenar al negocio. El equipo técnico sabe que tiene que pasar a cloud. Consiguen presupuesto. Contratan una consultora — a veces una global, a veces un equipo freelance — y arrancan la migración.

Seis meses después, el proyecto está parado. No por problemas técnicos. Por problemas que la arquitectura inicial no contempló porque nadie en el equipo los preguntó antes de escribir la primera línea de Terraform.

Esto no es una rareza. Es el patrón más común en migraciones cloud de fintechs argentinas, y la causa casi siempre es la misma: se aplicaron supuestos de contexto norteamericano o europeo a una operación que tiene regulaciones, restricciones de datos y condiciones de mercado completamente distintas.

El BCRA no es opcional

Una fintech que opera en Argentina bajo regulación del Banco Central tiene restricciones concretas sobre dónde pueden residir los datos de sus clientes. La Comunicación A 7724 y las normativas de servicios de pago definen marcos que condicionan desde qué regiones de AWS o GCP podés usar hasta cómo tenés que estructurar los accesos y auditorías. No son obstáculos para sortear — son requisitos de cumplimiento que, si no están contemplados en la arquitectura desde el inicio, generan retrabajo costoso o directamente bloquean la operación.

El problema es que la mayoría de los recursos de arquitectura cloud disponibles en internet parten de supuestos americanos o europeos. AWS Well-Architected Framework, los cursos de certificación, los white papers de referencia — todos son útiles, pero ninguno te dice qué hacer cuando tu arquitectura tiene que cumplir con la normativa del BCRA y al mismo tiempo ser suficientemente flexible para adaptarse a las actualizaciones regulatorias que, en Argentina, llegan con una frecuencia que no tiene parangón en otros mercados.

Eso tiene una consecuencia práctica: la consultora que sabe mucho de cloud pero poco de regulación financiera argentina te va a entregar una arquitectura técnicamente correcta que no podés poner en producción.

Lo que cambia cuando el contexto es local

Una migración cloud bien ejecutada en una fintech argentina tiene que resolver simultáneamente tres problemas que en otros mercados suelen ser independientes.

El primero es el técnico: mover la carga de trabajo de forma que el sistema sea más confiable, más fácil de escalar y más barato de operar a mediano plazo. Esto es lo que la mayoría de las consultoras ofrecen. Es necesario pero no suficiente.

El segundo es el regulatorio: asegurarse de que la arquitectura resultante cumple con las normativas vigentes y tiene la flexibilidad para adaptarse a los cambios. Esto requiere conocer la regulación actual, tener una lectura de hacia dónde va, y saber traducir requisitos legales en decisiones de arquitectura. No es el trabajo de un abogado ni de un arquitecto cloud por separado — es el trabajo de alguien que entiende los dos idiomas.

El tercero es el operacional: que el equipo interno pueda operar la nueva infraestructura sin depender indefinidamente de soporte externo. Una migración que deja al cliente sin capacidad de operar lo que se construyó no es una migración exitosa — es una dependencia nueva con nombre distinto.

Los tres problemas tienen que estar resueltos antes de que el proyecto termine. Si alguno queda pendiente, el que lo paga es el equipo de tecnología, generalmente en forma de incidente en el peor momento posible.

‍

‍

Por qué el tamaño no es el determinante

Hay una creencia instalada en el ecosistema fintech argentino que asocia la migración cloud con las empresas grandes. La lógica es que tenés que llegar a cierto volumen de transacciones o cierto tamaño de equipo para que valga la pena la inversión.

Esa lógica es incorrecta, y el error está en cómo se define "vale la pena".

Una fintech con 50.000 clientes activos que opera sobre infraestructura on-prem propia tiene un costo de oportunidad real: el equipo técnico dedica una proporción de su tiempo a mantener esa infraestructura que no se traduce en producto. Ese costo es invisible en el balance pero existe. Cuando se migra bien, ese tiempo se recupera. El equipo de engineering puede dedicarse a construir features en lugar de mantener servidores.

El argumento para migrar no es el volumen actual — es el costo del status quo comparado con el costo de operar sobre infraestructura cloud correctamente diseñada. En la mayoría de los casos que analizamos, el punto de equilibrio aparece antes de lo que el equipo directivo estima.

Lo que hace que una migración funcione

Después de varios proyectos en el sector financiero argentino — fintechs, billeteras, empresas de pagos — hay algunos factores que separan las migraciones que llegan a producción y operan bien de las que se frenan o generan más problemas de los que resuelven.

El primero es que alguien con autoridad técnica real dentro de la empresa esté involucrado desde el inicio. No como sponsor presupuestario sino como interlocutor técnico. Las migraciones donde el CTO o el Lead Architect participa activamente en las decisiones de diseño tienen tasas de éxito significativamente más altas que las que se tercerizan completamente.

El segundo es que la arquitectura se diseña pensando en quién la va a operar, no solo en quién la va a construir. Esto suena obvio pero no lo es: muchas consultoras optimizan para entregar algo que funcione al momento del handoff. Lo que importa es que siga funcionando seis meses después, cuando el equipo externo ya no está.

El tercero es el timing regulatorio. Las fintechs argentinas que migran en momentos de alta actividad normativa — y en Argentina los últimos tres años han sido de alta actividad normativa constante — tienen que construir más flexibilidad de la que construirían en un contexto estable. Eso tiene implicaciones en la elección de servicios, en la estructura de datos y en cómo se documenta la arquitectura para auditorías.

La conversación que vale tener antes

La mayoría de las conversaciones que tenemos con fintechs argentinas llegan cuando el problema ya es visible: la infraestructura está frenando un lanzamiento, el costo operativo creció más que el negocio, o un incidente expuso una fragilidad que el equipo sabía que existía pero no había tenido tiempo de resolver.

Es mejor tenerla antes. No porque seamos consultores y tengamos interés en generar trabajo — sino porque el costo de una arquitectura mal diseñada es siempre mayor que el costo de diseñarla bien desde el inicio. Deshacer decisiones de infraestructura en producción, con clientes reales y reguladores atentos, es el tipo de trabajo que no figura en ningún presupuesto pero que termina apareciendo igual.

Si tu fintech está evaluando cuándo y cómo migrar a cloud, o si ya empezaste una migración que se frenó, hablemos. La primera conversación es una revisión del estado actual — sin compromiso y sin PowerPoint.

‍