n8n 3.0: qué revisar antes de migrar tus automatizaciones
El anuncio de la beta introduce incompatibilidades que afectan a ejecución, archivos y despliegue. Preparar la migración no significa instalarla ya en producción.
La migración a n8n 3 debe tratarse como un cambio de plataforma, no como un reinicio rutinario. El anuncio del 27 de octubre presentó una beta con cambios incompatibles. La recomendación es inventariar, probar y preparar la recuperación antes de decidir cuándo trasladar los flujos de negocio.
Qué sabemos y qué hay que volver a comprobar
La presentación oficial, consultada el 5 de noviembre, situaba la versión estable a comienzos de diciembre. Es una previsión del anuncio, no una garantía ni una afirmación sobre el estado de cualquier versión futura.
Entre los cambios descritos están ejecuciones manuales en workers cuando se usa cola, retirada del almacenamiento binario en memoria, sustitución de nodos de programación antiguos y cambios en instalación autogestionada. El informe de migración ayuda a localizar incompatibilidades. Antes de actuar, contrasta la documentación de la versión exacta elegida.
Inventariar flujos por consecuencia de fallo
Clasifica workflows según lo que hacen: leer información, enviar avisos, modificar un CRM o crear pedidos no tienen el mismo riesgo. Anota disparador, credenciales, propietario, archivos utilizados y sistema que recibe el resultado.
Prioriza los recorridos donde una repetición pueda duplicar una operación. Un workflow desactivado también puede ser necesario para recuperación o cierres mensuales. No limites el inventario a los que se ejecutaron esta semana.
Revisar ejecución y archivos por separado
Una prueba manual satisfactoria no sustituye una ejecución programada o mediante webhook. En un entorno con workers, confirma que todos reciben configuración compatible y acceso al almacenamiento necesario.
Si un flujo mueve adjuntos, prepara una prueba con archivos representativos y otra con fallo de descarga. Verifica dónde queda el dato, quién puede leerlo y cómo se elimina. El cambio de versión no decide automáticamente la retención adecuada para tu negocio.
Preparar un ensayo sin efectos externos reales
Usa un entorno aislado y destinos de prueba. No clones credenciales de producción sin revisar qué operaciones habilitan: una copia puede seguir enviando mensajes o creando registros aunque la pantalla parezca un laboratorio.
Compara entrada y resultado esperado para cada recorrido. Incluye respuesta lenta del proveedor, credencial rechazada y reintento. Registra si la ejecución termina, si deja un error entendible y si permite recuperar el trabajo sin repetir efectos confirmados.
Distinguir copia de seguridad de recuperación
Guarda base de datos, configuración, material necesario para descifrar credenciales y archivos persistentes según tu despliegue. Comprueba que la copia pueda restaurarse en el entorno anterior antes de tocar producción.
No presupongas que cambiar la etiqueta del contenedor constituye un rollback. Las migraciones de datos pueden impedir una vuelta directa. La recuperación necesita una copia coherente y un plan para las operaciones nuevas ejecutadas después del cambio.
Decidir con un registro de aceptación
El criterio de salida debe listar flujos validados, excepciones y responsable de seguimiento. Si falta una dependencia crítica, posponer una migración mayor puede ser razonable sin abandonar el mantenimiento de seguridad de la rama actual.
Para revisar plataforma y workflows ofrecemos automatización con n8n y Make. Si todavía estás eligiendo herramienta, consulta la comparación entre n8n, Make y Python: es una decisión diferente de migrar una instalación existente.