El problema: PHP legacy es una interrupción en cámara lenta
Una aplicación PHP legacy normalmente carga con tres riesgos a la vez: corre en una versión de PHP que ya no recibe parches de seguridad, habla con la base de datos a través de extensiones que PHP moderno ha eliminado, y vive en un solo servidor envejecido que nadie se atreve a reiniciar. Cada mes que pasa la hace más expuesta y más difícil de mover, porque la memoria institucional de cómo funciona se desvanece mientras la superficie de ataque crece. El instinto de dejarla en paz es comprensible y exactamente lo que la hace peligrosa — cuanto más tiempo se queda, más grande se vuelve la eventual migración forzada. Este escenario existe para hacer el movimiento deliberado y reversible en lugar de una emergencia.
Cómo lo resuelve cdn.com.tr: runtime moderno, datos administrados, escudo edge
La PHP Platform le da a la app un runtime PHP 8 soportado con un file manager apropiado y selección de versión, así que ya no estás anclado a lo que sea que estaba instalado en la caja vieja. La base de datos administrada saca los datos de ese servidor frágil y los pone en un servicio MySQL mantenido cuyas credenciales se muestran en el panel — tú las pones en la configuración de la app, y puedes resetear la contraseña desde el panel en cualquier momento. Delante de ambos, la capa edge termina el TLS con Auto SSL y filtra tráfico con el WAF, así que incluso el código que precede las prácticas de seguridad modernas no queda directamente expuesto a internet. Modernizas el runtime y la capa de datos mientras envuelves todo en protección que la app original nunca tuvo.
Compatibilidad con PHP 8: el trabajo que realmente condiciona el movimiento
La migración se sostiene o se cae según la compatibilidad del código, así que ahí es donde va el esfuerzo real. Las apps legacy comúnmente usan las funciones mysql_* eliminadas, dependen de funciones borradas o cambiadas en PHP 7 y 8, asumen un tipado laxo que PHP 8 endureció, o dependen de extensiones que ya no vienen incluidas. Correr la app en una copia de staging del runtime nuevo saca a la luz estos problemas como errores concretos en lugar de sorpresas en producción. Los corriges metódicamente — cambias mysql_* por mysqli o PDO, reemplazas funciones eliminadas, atiendes los warnings — y vuelves a probar hasta que las rutas críticas quedan limpias. Solo entonces salir a producción se convierte en un paso rutinario en lugar de un salto de fe.
Migración de base de datos sin corromper tus datos
Mover los datos es donde ocurre el daño silencioso si te apuras. La trampa más común es el encoding de caracteres: muchas bases de datos legacy son latin1 o una mezcla, e importarlas a un destino utf8mb4 sin cuidado convierte los caracteres turcos y otro texto no-ASCII en mojibake que es doloroso de revertir después. El camino seguro es importar a MySQL administrado, hacer coincidir explícitamente el character set y la collation de origen, y verificar una muestra de registros reales — especialmente cualquier cosa con texto acentuado o no latino — antes de confiar en el resultado. Validas el ciclo completo de lectura/escritura en staging para que al momento del cambio la base de datos sea una copia conocida como buena, no una esperanzadora.
Staging y rollback: nunca apostar con tráfico en vivo
La disciplina que hace segura una migración legacy es que producción sigue corriendo intacta hasta que el nuevo entorno se ha probado a sí mismo. Construyes y pruebas todo en staging, y mantienes el host viejo vivo y sirviendo hasta después del cambio. Bajar el TTL del DNS con antelación significa que el cambio al edge — y la vuelta atrás, si es necesaria — toma minutos en lugar de horas. Si algo se rompe bajo tráfico real que el staging no reveló, reviertes el DNS al host viejo, corriges el problema en staging, y lo intentas de nuevo. Como nada del entorno viejo se destruyo durante el movimiento, el rollback es una opción real y no un bluff.
Opcional: estandariza los deploys futuros contenerizando la app
Una vez que la app está estable en la plataforma y quieres push-to-deploy con pasos de build y logs de despliegue, el camino es contenerizarla y ejecutarla como una Container App conectada a través de GitHub Deploy — instalación de Composer, build, y pasos de migración definidos una vez y ejecutados de la misma forma cada vez. La propia plataforma PHP mantiene el despliegue deliberadamente simple: subes por el file manager, sin pipeline que mantener.
Cómo configurarlo, paso a paso
Inventaria la app y elige un runtime destino
Cataloga la versión de PHP, extensiones, cron jobs, y rutas de archivo de las que depende la app, luego crea una app PHP Platform apuntando a un runtime PHP 8 soportado. Anota cualquier cosa que use funciones eliminadas o extensiones antiguas de MySQL para que sepas que cambios de código vienen antes de tocar producción.
Levanta una copia de staging
Despliega el código en la plataforma como un entorno de staging e importa una copia de la base de datos, para que puedas ejercitar la app en el runtime nuevo sin ningún tráfico en vivo. Sube el código por el file manager integrado, y mantén este entorno hasta que la migración esté probada.
Migra la base de datos a MySQL administrado
Crea una base de datos administrada, importa tu dump, y confirma que el character set y la collation coinciden con el original (las apps legacy suelen ser latin1 o un encoding mixto). Apunta la app a la BD administrada usando las credenciales provistas por la plataforma en lugar de hardcodearlas, y verifica lecturas y escrituras en staging.
Corrige compatibilidad y vuelve a probar en staging
Trabaja en los problemas de PHP 8 que aparecen en staging — funciones deprecadas, mysql_* a mysqli/PDO, manejo de tipos más estricto — hasta que la app corra limpio. Prueba las rutas críticas (login, formularios, admin, pagos) de extremo a extremo en la URL de staging antes de que alguien hable de salir a producción.
Conecta el dominio, Auto SSL, y WAF
Trae el dominio a la cuenta del CDN, deja que Auto SSL prepare el certificado, y activa el WAF para que el código antiguo quede protegido en el momento en que enfrenta el internet público. Mantén el origin accesible solo a través del edge para que el servidor de la app nunca quede expuesto directamente.
Cambia el DNS con un rollback listo
Cambia el DNS al edge durante una ventana tranquila con un TTL bajo configurado de antemano, para que si aparece un problema puedas revertir rápido. Mantén el host viejo corriendo e intacto hasta que el nuevo entorno se haya probado a sí mismo bajo tráfico real, y luego desmantelalo.
Escenarios de ejemplo
Un foro de larga trayectoria en PHP end-of-life se mueve a PHP 8 y MySQL administrado, con secciones de archivo de solo lectura cacheadas en el edge y el WAF conteniendo el abuso de bots.
Un CMS PHP a medida se traslada al runtime moderno tal cual, después de correcciones de compatibilidad, ganando años de operación segura sin una reescritura completa.
Una herramienta PHP de línea de negocio corriendo en una sola caja envejecida se migra a runtime y base de datos administrados, eliminando el punto único de falla que tenía a todos nerviosos.
Preguntas frecuentes
Mi app usa las viejas funciones mysql_*. Correrá en PHP 8?
No tal cual — esas funciones se eliminaron hace años. La migración incluye reemplazarlas con mysqli o PDO, que es exactamente el tipo de problema que el staging revela como errores claros para que puedas corregirlo antes de salir a producción en lugar de descubrirlo en producción.
Cómo evito distorsionar los caracteres turcos durante el movimiento de la BD?
Haz coincidir explícitamente el character set y la collation de origen al importar a MySQL administrado, y verifica registros de muestra que contengan texto acentuado o no latino en staging. Los desajustes de encoding son el fallo silencioso más común en migraciones legacy, así que lo validas antes del cambio, no después.
Puedo probar todo antes de tocar el sitio en vivo?
Sí, ese es el núcleo del enfoque. Corres una copia completa de staging en el runtime nuevo con una copia de la base de datos, pruebas las rutas críticas, y solo entonces mueves el DNS. Producción sigue corriendo en el host viejo todo el tiempo.
Qué pasa si algo se rompe justo después del cambio?
Reviertes el DNS al host viejo, que sigue corriendo e intacto, luego corriges el problema en staging y reintentas. Configurar un TTL de DNS bajo antes del cambio mantiene ese rollback en cuestión de minutos.
Tengo que actualizar todo mi código de una vez?
Necesitas suficiente trabajo de compatibilidad para que la app corra limpio en el runtime PHP 8 objetivo, pero no tienes que reescribir la aplicación. Muchas apps legacy se mueven con un conjunto enfocado de correcciones; un refactor más grande puede pasar después una vez que la app está segura en la plataforma.
Mi código viejo está seguro una vez que vuelve a exponerse a internet?
El WAF edge y Auto SSL se ubican delante de la app, filtrando tráfico de ataque común y forzando HTTPS antes de que las solicitudes lleguen al origin. Combinado con mantener el servidor de la app accesible solo a través del edge, esto le da al código legacy una protección que nunca tuvo en su host viejo.