Empresa financiera · Migración legacy · 2026
Zoho Migration: una calculadora financiera en 8 días en lugar de 4-6 meses
Cómo sustituimos el costoso Zoho Creator por una solución propia en Cloudflare Workers + Postgres, con generación nativa de PDF y escalado ilimitado.
// Antes → Después
Antes · Zoho Creator: Una licencia por cada uno de los 25+ usuarios y un servicio externo de PDF (~50 €/mes)
Después · stack propio: ~30 €/mes de infraestructura para todo el equipo, sin licencias por usuario
Antes · Zoho Creator: Un informe PDF: 8-15 segundos
Después · stack propio: Menos de 2 segundos, renderizado nativo en el Worker
Antes · Zoho Creator: Lógica en scripts Deluge que no se pueden migrar
Después · stack propio: Cada fórmula es una función tipada en TypeScript; 240/240 pruebas de regresión
Antes · Zoho Creator: Estimación de la licitación: 4-6 meses y ~25-30K €
Después · stack propio: 8 días laborables y 9000 €: un ingeniero + Claude Code
- Zoho Creator: Fórmulas Deluge, 8 tipos de cálculoreescritoStack nuevo: Funciones TypeScript en Cloudflare Workers (Hono)
- Zoho Creator: Contratos e historial de cálculostrasladadoStack nuevo: Postgres en Supabase + Row-Level Security
- Zoho Creator: Servicio externo de PDFsustituidoStack nuevo: Cloudflare Browser Rendering API
- Zoho Creator: Interfaz de Zoho CreatorreescritoStack nuevo: Astro + React islands
- Zoho Creator: Usuarios y acceso en ZohosustituidoStack nuevo: Clerk + SSO con Microsoft 365
// Contexto
El cliente es una empresa financiera que atiende a clientes corporativos. Un equipo de 25, 30+ clientes corporativos, cálculos multimoneda complejos.
El corazón de la operación es una calculadora financiera: entrada (condiciones, tasas, calendarios de pago); salida, informes PDF estructurados para el cliente. La calculadora se construyó en Zoho Creator hace 4 años: rápido, no-code, funcionaba.
// Qué dolía
- Caro: un modelo per-user: cada usuario en un equipo de 25+ significaba una licencia aparte, más un servicio externo de PDF (~50 €/mes) una vez que se agotaba el límite de 1000 PDF/mes.
- Lento: con 1000+ cálculos al mes la UI «giraba sin fin», y la exportación de PDF tardaba 8-15 segundos.
- Escalar no era trivial: para añadir 5 usuarios nuevos, otra licencia + aprobación. La plataforma siempre se volvía el cuello de botella.
- Vendor lock-in: los scripts Deluge no se podían portar. Podías exportar los datos, pero no la lógica.
// Por qué no un «equipo de desarrollo normal»
El cliente hizo una licitación. Dos equipos estimaron el proyecto en 4-6 meses y ~25 000–30 000 €. Mientras la licitación seguía, propuse un enfoque alternativo: un ingeniero + Claude Code.
La lógica: una migración es una tarea bien documentada (scripts legacy, tipos de datos, comportamiento esperado). Es un caso ideal para la programación con IA, donde gran parte del trabajo es reescribir fórmulas y UI con entradas y salidas conocidas.
El resultado: muchas veces más rápido y tres veces más barato que las estimaciones de la licitación.
// Solution: qué hicimos
1. Reverse engineering del legacy
Exportamos cada script de Zoho Deluge (su lenguaje de scripting propietario). Entrevistas con el director financiero: una hora por cada uno de los 8 tipos de cálculo. Construimos pruebas de regresión: 240 escenarios con salidas esperadas.
2. Backend en Cloudflare Workers
Framework Hono.js, TypeScript. Cada fórmula es una función separada con un contrato tipado. Postgres en Supabase para almacenar contratos e historial de cálculos. Row-Level Security proporciona multi-tenancy.
3. Generación nativa de PDF
Cloudflare Browser Rendering API: renderiza el PDF desde HTML/CSS dentro del Worker. Gratis hasta 100 000 llamadas/mes. Velocidad: <2 segundos por PDF en lugar de 8-15 en Zoho.
4. Frontend en Astro
Páginas con SSR estático (rápido, SEO-friendly), formularios reactivos vía React islands. El diseño contempla a los usuarios frecuentes: atajos de teclado, autoguardado, historial.
5. Auth & SSO
Clerk para la gestión de usuarios, integración SSO con el Microsoft 365 corporativo. El usuario inicia sesión a través de su cuenta corporativa, sin contraseñas extra.
6. Stack
| Layer | Herramientas |
|---|---|
| Backend | Cloudflare Workers + Hono + TypeScript |
| Database | Supabase (Postgres) + Row-Level Security |
| Frontend | Astro 6 + React islands + Tailwind v4 |
| PDF generation | Cloudflare Browser Rendering API (nativo) |
| Auth | Clerk + Microsoft 365 SSO |
| AI assist | Claude Code (Sonnet 4.6) para todo el código |
// Timeline
Exportación de los scripts de Zoho Deluge, entrevista con el director financiero, mapeo de fórmulas, un conjunto de pruebas de regresión (240 escenarios)
Cloudflare Worker con las APIs principales, esquema Postgres, conexión Supabase, primeras 50 pruebas pasando
Generación nativa de PDF, implementación de todas las fórmulas de la calculadora financiera, 240/240 pruebas en verde
Frontend Astro con formularios reactivos, Clerk auth, SSO con Microsoft 365, deploy a producción en Cloudflare
// Result: las cifras
| Métrica | Zoho (antes) | Cloudflare (después) |
|---|---|---|
| Coste mensual | licencias per-user + servicio de PDF | ~30 € de infraestructura |
| Generación de PDF | 8-15 seg | <2 seg |
| Escalado | Per-user pricing | Ilimitado |
| Tiempo de migración | 4-6 meses (estimación) | 8 días hábiles |
| Pruebas de regresión | 0 | 240/240 ✓ |
// Qué salió mal: lecciones aprendidas
Legacy edge cases. 18 de 240 pruebas «se pusieron rojas» al principio: las fórmulas de Zoho tenían comportamiento no documentado en valores extremos (tasas cero, penalizaciones negativas). El reverse engineering llevó 1 día más de lo que planeé.
Configuración de SSO con Microsoft 365. Clerk en sí es simple, pero el AD corporativo tiene sus mañas. Pasamos medio día en una conditional access policy.
Postgres connection pooling. Cloudflare Workers se ejecuta en el edge, mientras que Supabase está en us-east. Las primeras pruebas mostraron +200 ms de latencia. Cambiamos a Hyperdrive (servicio de Cloudflare para cachear conexiones) y la latencia cayó a 30 ms.
// FAQ
¿Por qué el cliente quería dejar Zoho Creator?+
Tres razones. Primera, el per-user pricing: cada nuevo usuario en un equipo de 25+ personas significaba otra licencia, y el modelo se volvía cada vez menos conveniente. Segunda, los límites de generación de PDF: la cuota gratis de 1000 PDF/mes se agotaba, y más allá un servicio externo costaba otros ~50 €/mes. Tercera, una UI lenta: una «carga infinita» al trabajar con tablas de cálculo grandes.
¿Por qué Claude Code en lugar de un equipo de desarrollo normal?+
Un equipo (3 desarrolladores + lead) estimó la migración en 4-6 meses y ~25 000–30 000 € a tarifa fija. Con Claude Code, un ingeniero hizo la migración en 8 días hábiles, porque la IA generaba código, pruebas y documentación en paralelo. El cliente pagó 9000 € en vez de 25 000 € por la misma funcionalidad.
¿Cómo conservasteis la lógica de las fórmulas legacy?+
Reverse engineering. Exportamos cada script de Zoho Deluge y documentamos cada fórmula en una entrevista con el director financiero (quien recordaba los edge cases). Generamos un conjunto de pruebas de regresión: 240 escenarios con salidas esperadas. La nueva implementación tenía que pasar las 240 antes de que la funcionalidad fuera aceptada.
¿Qué hacer si la lógica legacy no está documentada?+
Si no hay pruebas ni documentación, el riesgo es máximo. Mi consejo es no migrar «de frente», sino primero envolver el legacy en pruebas de regresión (vía automatización de UI o la API), y solo después reescribir. Aquí valió la pena por completo: los días invertidos en auditar las fórmulas ahorraron semanas de depuración.
¿Cuánto cuesta mantener la nueva solución?+
Cloudflare Workers: ~5 €/mes para un workload básico. Postgres en Supabase: 25 €/mes. Coste total de infra: ~30 €/mes para los 25 usuarios, sin licencias per-user y sin servicio externo de PDF. La infraestructura ahora cuesta menos de lo que antes costaba una sola licencia.
Autor del caso
Andrew Maryasov
Consultor de IA, fundador de Auspex (automatización de CRM) y Grow2.ai (agentes de IA + comunidad). 25+ años en automatización de negocios: contabilidad → CRM → IA. Construyo estrategia de IA y automatización para dueños y equipos; la entrega va a través de mis propias marcas.
// Otros casos
// Conclusión
La decisión clave aquí fue estratégica, no técnica: ver que una migración es una tarea bien documentada (scripts legacy + entradas/salidas conocidas), y por eso justamente es un caso ideal para la programación con IA. La velocidad y el ahorro vinieron de plantear la tarea correctamente, no de la herramienta en sí.
Implantado a través de Auspex: automatización de CRM y migración de procesos de negocio. La estrategia la construyo personalmente; la entrega en sí la lleva el equipo de Auspex.
¿Tienes tu propio legacy del que ya deberías irte?
Empecemos con una conversación: si conviene migrar siquiera, dónde están los riesgos y dónde la ventaja. La estrategia la construimos juntos; la entrega, a través de Auspex.
Asesoría personal →