Low-code o desarrollo a medida: cuándo empezar en low-code y migrar

Publicado: 2026-07-13 · Actualizado: 2026-10-28

Por Goiko, Founder & AI Solutions CTO de GUGŌ Creative

Low-code o desarrollo a medida: límites, escalabilidad, propiedad del código y coste; cuándo empezar en low-code y cómo migrar sin parar la operación.

Empieza en low-code cuando el proceso todavía se está definiendo, el volumen es bajo, las integraciones son estándar y un fallo no para la empresa: tendrás algo funcionando en días y aprenderás qué necesitas de verdad. Pasa a desarrollo a medida cuando el proceso se vuelve crítico, el coste por uso crece más que el negocio, necesitas lógica o integraciones que la plataforma no admite, o tienes que poder probarlo, auditarlo y llevártelo a otra parte.

La pregunta útil no es cuál de los dos es mejor, sino cuándo cambiar y cómo hacerlo sin romper la operación. Esa decisión se prepara desde el primer día: datos en un sitio del que puedas sacarlos, flujos documentados y cuentas de servicio en lugar de credenciales personales. La comparación general entre ambos enfoques está en software a medida vs no-code/low-code; aquí nos centramos en los límites que obligan a migrar, en los riesgos y en cómo hacer la migración.

Qué cabe bajo la etiqueta low-code y por qué importa para salir

Bajo la misma etiqueta caben herramientas muy distintas, y la facilidad de salida cambia con cada una:

Automatización entre aplicaciones, como Zapier, Make, n8n o Power Automate: flujos que conectan servicios. La lógica vive en la plataforma y los datos, normalmente, en los sistemas que conecta.
Bases de datos con interfaz, como Airtable: tablas, vistas y formularios. Los datos y parte de la lógica viven en la plataforma.
Constructores de aplicaciones, como Bubble, Power Apps, FlutterFlow o Retool: interfaz, lógica y a veces base de datos. Es donde la propiedad del código marca más diferencia.

La salida no es igual en todas. Bubble explica que sus aplicaciones no se pueden exportar como código y solo se ejecutan en su plataforma; si te vas, ofrece un volcado en JSON de la lógica y del diseño, y los datos se exportan en CSV. FlutterFlow, en cambio, permite exportar el proyecto como código Flutter con su herramienta de línea de comandos. Y n8n se puede autoalojar, pero bajo una licencia de uso sostenible que limita el uso a fines internos de la empresa o no comerciales y que la propia n8n describe como fair-code, no como código abierto.

Límites del low-code que suelen obligar a migrar

Volumen y coste por uso

Las plataformas cobran por usuario, por ejecución o por operación. En Zapier, por ejemplo, cada acción que se ejecuta con éxito cuenta como una tarea, y al agotar el límite del plan, según cómo esté configurada la facturación, se cobran tareas adicionales o se retienen las ejecuciones nuevas hasta el siguiente ciclo. Un flujo de cinco acciones que se ejecuta mil veces al día consume cinco mil tareas diarias. Con poco volumen es irrelevante; cuando el proceso crece, la factura crece con él, y un límite alcanzado puede retener un flujo crítico.

Lógica que no cabe en el editor visual

Reglas con muchas excepciones, cálculos que cruzan varias tablas, operaciones que deben completarse enteras o deshacerse y reintentos que no dupliquen nada. Se pueden resolver con bloques de código dentro de la plataforma, pero entonces tienes código sin control de versiones, sin pruebas y repartido por decenas de pasos.

Pruebas, versiones y auditoría

Cuando el proceso es crítico necesitas saber qué cambió y quién lo cambió, poder volver atrás, probar un cambio antes de publicarlo y registrar quién hizo qué. Comprueba qué ofrece la plataforma, y en qué plan, antes de que el proceso dependa de ello.

Integraciones fuera del catálogo

Mientras existen conectores, todo es rápido. Cuando hay que hablar con un ERP antiguo, una máquina, un sistema sin API pública o un proveedor con un formato propio, acabas construyendo un servicio aparte. Eso ya es desarrollo a medida, pero sin la arquitectura que lo sostenga.

Riesgos de seguir en low-code cuando el proceso ya es crítico

OWASP mantiene un Top 10 de riesgos del desarrollo ciudadano (citizen development), el que hacen perfiles de negocio con plataformas low-code, asistentes de programación con IA o agentes. Dos de sus riesgos pesan especialmente cuando un flujo pasa a ser crítico:

Suplantación de cuentas (CD-SEC-02): la aplicación usa las credenciales personales de quien la creó, una cuenta compartida o una conexión a la base de datos con más permisos de los necesarios, y todo lo que hace parece hecho por esa persona.
Fallos en la gestión de activos (CD-SEC-09): como crear soluciones es tan fácil, se multiplican y acaban sin responsable, sin actualizar y abandonadas.

A eso se suman los riesgos de negocio:

Dependencia del proveedor: cambios de precio, de plan o de producto que no controlas.
Conocimiento en una sola persona: el flujo lo entiende quien lo montó, y nadie más.
Datos repartidos: la misma información en la plataforma, en el ERP y en hojas de cálculo, sin un sistema que mande.
Una salida más cara cuanto más se espera: cada flujo nuevo es uno más que migrar.

El Reglamento de Datos de la UE ayuda, pero no lo resuelve todo. Obliga a los proveedores de servicios de tratamiento de datos, incluido el software como servicio, a facilitar el cambio de proveedor y a exportar a petición del cliente sus datos en un formato estructurado, de uso habitual y legible por máquina. Pero los datos exportables excluyen lo protegido por la propiedad intelectual del proveedor, y la obligación de facilitar una equivalencia funcional en el destino solo alcanza a los servicios de infraestructura. Dicho de otro modo: te llevas los datos, no una aplicación que funcione en otro sitio. Esto es orientación técnica, no asesoramiento jurídico.

Tabla: qué hay que migrar de una plataforma low-code y cómo

Pieza	Dónde suele estar	Riesgo al migrar	Cómo abordarlo
Datos	Tablas de la plataforma o sistemas conectados	Formatos propios, relaciones exportadas como identificadores e históricos incompletos	Exportar pronto y a menudo, modelar en una base de datos propia y validar recuentos antes del cambio
Lógica de negocio	Pasos, fórmulas y bloques de código repartidos	Reglas implícitas que nadie documentó	Inventariar cada flujo con entradas, salidas y excepciones, y escribir pruebas con casos reales
Integraciones	Conectores del catálogo y webhooks	Credenciales personales y límites de llamadas	Cuentas de servicio, una capa de integración propia y reintentos que no dupliquen
Usuarios y permisos	Roles de la plataforma	Permisos más amplios de lo necesario	Rediseñar los roles sobre el inicio de sesión corporativo
Interfaz	Pantallas y formularios del constructor	Hábitos de uso que el equipo no quiere perder	Reproducir primero las tareas diarias y cambiar lo demás después
Tareas programadas	Disparadores por horario o por evento	Ejecuciones dobles o perdidas durante la transición	Un único sistema autorizado para cada escritura en cada momento

Cómo migrar de low-code a desarrollo a medida sin parar la operación

La migración que funciona es gradual. El patrón de higuera estranguladora (strangler fig) que documenta Microsoft consiste en sustituir funcionalidades una a una mientras el sistema antiguo sigue atendiendo el resto, hasta poder retirarlo. Microsoft advierte de que el patrón no encaja si no se pueden interceptar las peticiones al sistema antiguo; en low-code, el punto de corte natural suele ser el disparador de cada flujo —el webhook, el formulario o la tabla que lo pone en marcha—, pero compruébalo antes de planificar. El mismo patrón aplicado a sistemas heredados está en cómo modernizar software legacy sin parar el negocio.

Inventario. Lista cada flujo, aplicación y tabla: qué hace, quién lo usa, con qué sistemas habla, cuántas veces se ejecuta y qué pasa si falla.
Prioridad. Empieza por lo que más duele o más riesgo tiene: el flujo con más volumen, el que mueve dinero o el que solo entiende una persona.
Datos primero. Crea el modelo de datos propio y sincronízalo desde la plataforma, para que el sistema nuevo arranque con datos reales y puedas comparar resultados.
Flujo a flujo. Reescribe un flujo, ejecútalo en paralelo con el original comparando salidas y, cuando coincidan, redirige el disparador al sistema nuevo.
Retirada. Desactiva el flujo antiguo, conserva una exportación de datos y lógica, y revisa las licencias para dejar de pagar lo que ya no usas.

Cómo empezar en low-code preparando la salida

Antes de elegir plataforma, comprueba qué puedes exportar —datos, lógica o código— y en qué formato.
Guarda los datos maestros donde puedas exportarlos completos, mejor fuera de la herramienta de automatización.
Usa cuentas de servicio, nunca credenciales personales.
Documenta cada flujo en una frase: disparador, qué hace, qué sistemas toca y quién responde si falla.
Evita bloques largos de código dentro de la plataforma: si los necesitas, esa parte ya pide desarrollo.
Revisa cada trimestre volumen, coste y errores: son los tres indicadores que avisan de que se acerca el cambio.

Cuánto cuesta: low-code frente a desarrollo a medida

No publicamos rangos para licencias low-code: dependen de la plataforma, del plan, de los usuarios y del volumen, y cambian a menudo. Lo que sí conviene comparar es la tendencia. El low-code empieza barato y su coste crece con cada usuario y cada ejecución; el desarrollo a medida pide más inversión inicial y después un coste recurrente más estable.

Para el desarrollo, los rangos de nuestro informe de precios 2026 son estos:

MVP operativo con un módulo principal, usuarios, panel y despliegue: 15.000-35.000 €, en 8-12 semanas.
Plataforma interna con varios roles, flujos, permisos e integraciones: 35.000-70.000 €, en 12-20 semanas.
Automatización acotada con IA, si el flujo clasifica documentos, correos o datos del CRM con revisión humana: 10.000-20.000 €, en 4-6 semanas.
Costes recurrentes: mantenimiento del 15-25 % del coste de desarrollo al año e infraestructura cloud de 50-500 € al mes.

La migración de datos y el tiempo en que conviven los dos sistemas no tienen rango publicado: dependen de cuántos flujos haya, de la calidad de los datos y del tiempo que deban funcionar en paralelo, y se presupuestan después del inventario. Hay más detalle en cuánto cuesta desarrollar software a medida.

Ejemplos de decisión

Los escenarios siguientes son hipotéticos e ilustrativos, no casos de clientes.

Un flujo de pedidos que creció más que la plataforma

Una empresa B2B conecta su formulario de pedidos con el ERP y el correo mediante un flujo automatizado. Con el volumen inicial funciona; al multiplicarse los pedidos, el coste por ejecución sube y algunos reintentos duplican pedidos en el ERP. Se migra solo ese flujo a un servicio propio con identificadores únicos y reintentos seguros, y las notificaciones internas se quedan en la plataforma.

Una aplicación interna que se convirtió en producto

Una empresa de servicios monta en un constructor visual un portal para que sus clientes sigan sus expedientes. Funciona, y los clientes empiezan a pedir más. Como la plataforma no exporta código, hay que reescribirlo: se aprovechan los datos exportados y lo aprendido sobre qué usan de verdad los clientes, que es lo más valioso del primer año.

Cuando no compensa migrar

Un equipo de marketing mueve contactos entre formularios, CRM y correo con automatizaciones. El volumen es bajo, no hay datos sensibles y, si algo falla, se corrige al día siguiente. Migrar no aportaría nada: basta con documentar los flujos y pasarlos a una cuenta de servicio.

Errores frecuentes al migrar

Migrar todo de golpe: se pierde lo aprendido con el sistema actual y se multiplica el riesgo.
Reproducir la plataforma en código: migrar es la ocasión de rediseñar el proceso, no de copiar cada pantalla.
No ejecutar en paralelo: sin comparar salidas no sabes si el sistema nuevo hace lo mismo que el antiguo.
Olvidar las automatizaciones invisibles: la que se dispara una vez al mes para cerrar la facturación es la que nadie recuerda.
Volver a quedarte sin propiedad: si desarrolla un proveedor, el contrato debe cederte los derechos y entregarte el código, como explicamos en cuándo desarrollar software a medida.

Preguntas frecuentes

¿Cuándo es suficiente una plataforma low-code?

Cuando el flujo es sencillo, el volumen es bajo, las integraciones son estándar y un fallo no para la empresa. Para validar un proceso o automatizar tareas internas poco críticas, suele ser la opción más rápida.

¿Cuándo conviene pasar de low-code a desarrollo a medida?

Cuando el proceso se vuelve crítico, el coste por uso crece más que el negocio, necesitas lógica o integraciones que la plataforma no admite o debes poder probarlo, auditarlo y llevártelo a otra parte. La señal práctica es que el equipo dedica más tiempo a sortear la plataforma que a mejorar el proceso.

¿Se puede exportar el código de una aplicación low-code?

Depende de la plataforma. FlutterFlow permite exportar el proyecto como código Flutter; Bubble no permite exportar la aplicación como código y ofrece un volcado en JSON de la lógica y el diseño. Compruébalo antes de que el proceso dependa de la herramienta.

¿Cómo se migra de low-code a software a medida sin parar la operación?

Por fases: inventario, datos primero y cada flujo reescrito y ejecutado en paralelo con el original hasta que coincidan las salidas; después se redirige su disparador al sistema nuevo. Lo que funciona y no es crítico puede quedarse en low-code.

¿Cuánto cuesta el desarrollo a medida frente al low-code?

El low-code tiene un coste inicial bajo y una cuota que crece con usuarios y volumen; no publicamos rangos de licencias. Según nuestro informe de precios 2026, un MVP operativo cuesta 15.000-35.000 € y una plataforma interna, 35.000-70.000 €, más un mantenimiento del 15-25 % anual.