Migrar de PHP/MySQL a Next.js + Supabase: por que, cuando y como (con caso real)

La conversacion que tenemos todas las semanas

"Mi sistema en PHP anda, pero cada cambio cuesta una fortuna. El dev que lo hizo ya no esta. Cuando crece la base de datos se pone lento. No funciona bien en celulares."

Escuchamos alguna variante de esto al menos una vez por semana. Y la respuesta no siempre es "migra ya". A veces conviene; a veces no.

En NexPO hacemos migraciones de sistemas legacy como uno de nuestros servicios principales. Este articulo explica cuando tiene sentido migrar, como lo hacemos y que resultados podes esperar.

Cuando SI conviene migrar

• El mantenimiento cuesta mas que reconstruir: Si cada fix te sale USD 500-1.000 y tenes 2-3 por mes, en 6 meses llevas USD 3.000-6.000 de mantenimiento. Ese dinero alcanza para migrar la mitad del sistema.
• No encontras devs PHP seniors: El pool de desarrolladores PHP esta achicandose. Los que quedan cobran caro. Encontrar un dev Next.js/React es mucho mas facil en 2026.
• El sistema no es responsive: Si tu equipo necesita usar el sistema desde el celular y no se adapta, necesitas reconstruir el frontend de todas formas.
• Seguridad: Versiones de PHP < 8.1 ya no reciben parches de seguridad. Si tu sistema corre en PHP 7.x, estas expuesto.
• Performance degradada: Queries que tardan segundos, pages que tardan en cargar, servidor que se cae con carga.

Cuando NO conviene migrar

• El sistema funciona bien y el equipo lo mantiene: Si tenes un dev PHP competente que lo mantiene y los usuarios estan contentos, no migres por moda.
• El negocio va a cambiar radicalmente: Si en 6 meses vas a pivotar o cambiar tu modelo, no inviertas en migrar algo que va a cambiar.
• No tenes presupuesto para hacerlo bien: Una migracion a medias es peor que quedarse con el sistema viejo. Si el presupuesto solo alcanza para migrar 1 de 5 modulos sin un plan claro, mejor esperar.

Comparativa tecnica honesta

El proceso de migracion paso a paso

Fase 1: Auditoria del sistema actual (1-2 semanas)

No se puede migrar lo que no se entiende. Hacemos:

• Relevamiento de todas las tablas, relaciones y queries
• Documentacion de reglas de negocio (muchas estan "en el codigo" y nadie las tiene escritas)
• Mapeo de integraciones externas (APIs, pagos, facturacion)
• Listado de usuarios, roles y permisos
• Identificacion de "deuda tecnica" vs. features reales

El entregable es un documento que dice "esto es lo que el sistema hace" vs. "esto es lo que deberia hacer".

Fase 2: Plan de migracion por modulos (1 semana)

No migramos todo junto. Priorizamos:

• Modulo mas doloroso: El que mas problemas da hoy
• Modulo mas independiente: El que tiene menos dependencias con el resto
• Quick wins: Modulos simples que dan resultados rapidos y generan confianza

Cada modulo tiene su timeline y presupuesto independiente.

Fase 3: Migracion de base de datos

La migracion de MySQL a PostgreSQL (Supabase) es el paso mas critico. Asi lo hacemos:

``sql -- Ejemplo: tabla de usuarios en MySQL CREATE TABLE usuarios ( id INT AUTO_INCREMENT PRIMARY KEY, nombre VARCHAR(100), email VARCHAR(150) UNIQUE, password VARCHAR(255), rol ENUM('admin', 'operador', 'viewer'), activo TINYINT(1) DEFAULT 1, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP );

-- Equivalente en PostgreSQL (Supabase) CREATE TABLE usuarios ( id UUID DEFAULT gen_random_uuid() PRIMARY KEY, nombre TEXT NOT NULL, email TEXT UNIQUE NOT NULL, rol TEXT CHECK (rol IN ('admin', 'operador', 'viewer')) DEFAULT 'viewer', activo BOOLEAN DEFAULT true, created_at TIMESTAMPTZ DEFAULT now() );

-- Row Level Security para multi-tenancy ALTER TABLE usuarios ENABLE ROW LEVEL SECURITY; CREATE POLICY "usuarios_own_org" ON usuarios USING (org_id = auth.jwt() ->> 'org_id'); `

Diferencias clave:

• ENUM de MySQL pasa a CHECK constraint en PostgreSQL (mas flexible)
• INT AUTO_INCREMENT pasa a UUID (mejor para sistemas distribuidos)
• TINYINT(1) pasa a BOOLEAN` nativo
• Se agrega Row Level Security desde el principio

Fase 4: Reconstruccion del frontend

El frontend se reconstruye en Next.js con Tailwind CSS. La regla es: respetar los flujos que el usuario ya conoce, mejorar la UX.

No le cambiamos la ubicacion de botones ni el orden de los formularios por capricho. Si el usuario hace Click A, Click B, Click C para completar un pedido hace 5 anos, el nuevo sistema tiene que seguir siendo Click A, Click B, Click C (pero mas rapido y en el celular tambien).

Fase 5: Periodo de convivencia

Durante 2-4 semanas, ambos sistemas corren en paralelo. Los modulos migrados se usan en el nuevo sistema; los no migrados siguen en el viejo. Datos criticos se sincronizan bidireccionalmente.

Este periodo es clave para detectar bugs que no aparecieron en testing y para que el equipo se adapte gradualmente.

Caso real: ChivAPP (AppSheet a Next.js)

ChivAPP es un sistema de gestion avicola que migramos de AppSheet a Next.js + Supabase.

Situacion original:

• AppSheet con Google Sheets como "base de datos"
• Miles de registros de produccion, mortalidad y alimentacion
• Performance degradada: 8+ segundos para cargar reportes
• Costos de licencia AppSheet crecientes
• Personalizacion limitada

Lo que hicimos:

• Auditamos todas las vistas y flujos de AppSheet
• Migramos datos de Google Sheets a PostgreSQL (con limpieza y normalizacion)
• Reconstruimos cada vista en Next.js, respetando la logica original
• Agregamos features que AppSheet no podia: graficos de rendimiento, alertas automaticas, exportacion avanzada

Resultado:

• Carga de reportes: de 8+ segundos a menos de 1 segundo
• Costo mensual de licencias: de USD [DATO A CONFIRMAR] a USD 0 (tier gratuito Supabase)
• Personalizacion completa: cualquier feature nueva se puede agregar sin limitaciones de plataforma

La leccion mas importante

La migracion tecnica es la parte facil. La parte dificil es la gestion del cambio humano. Tu equipo lleva anos usando el sistema viejo: conocen cada boton, cada atajo, cada truco. El nuevo sistema tiene que ser lo suficientemente familiar para que no sientan que perdieron expertise, y lo suficientemente mejor para que quieran usarlo.

Si estas pensando en migrar tu sistema PHP/MySQL o tu AppSheet, agenda un diagnostico gratuito. En 30-45 minutos te decimos si tiene sentido migrar, que modulos priorizar y cuanto costaria.