Infraestructura · Modernización
La deuda tecnológica heredada no se soluciona solo con parches
Durante años, muchas empresas —nosotros incluidos— hemos mantenido sistemas legacy que siguen cumpliendo su función, pero que hoy representan un desafío en seguridad, mantenimiento y escalabilidad.
Muchas veces heredamos sistemas desarrollados hace 10 o 15 años que siguen funcionando perfectamente para el usuario final. Sin embargo, detrás pueden existir versiones sin soporte, dependencias obsoletas y vulnerabilidades que ya no podemos ignorar.
Esa deuda, tarde o temprano, se tiene que enfrentar. En PortalPBX la estamos enfrentando con una estrategia clara.
01 / ACTUALIZARLo que todavía tiene soporte, se parchea
No todo necesita reescribirse desde cero. Si un componente aún recibe actualizaciones de seguridad, lo correcto es mantenerlo al día, aplicar los parches y seguir operando con normalidad.
02 / AISLARLo más antiguo y vulnerable sale de la exposición pública
Los componentes que no pueden actualizarse de forma segura se retiran de internet y, cuando corresponde, se trasladan a entornos internos controlados mientras se planifica su reemplazo. Si no puedo arreglarlo hoy, al menos me aseguro de que no quede expuesto.
03 / MODERNIZARLo que está expuesto a internet se migra
Estamos evaluando y migrando endpoints, APIs y servicios heredados en PHP hacia arquitecturas más modernas, utilizando Go y otras tecnologías según las necesidades de cada proyecto. La superficie pública es donde más importa reducir vulnerabilidades.
04 / CÓMO DECIDIMOSMigrar sin afectar producción
Hablamos de software antiguo, obsoleto y, en muchos casos, sin soporte. Por eso no empezamos reescribiendo: empezamos reduciendo el riesgo y después avanzamos pieza por pieza.
- Primero, todo a local. Lo heredado deja de estar expuesto a internet y pasa a un entorno interno y controlado.
- Proxies al frente. Ponemos un reverse proxy o gateway delante, de modo que PHP nunca quede expuesto directamente a internet. Solo pasa lo que tiene que pasar.
- Migración gradual, pieza por pieza. Cada componente se lleva a un lenguaje o runtime con soporte. Puede ser la misma tecnología en una versión soportada o una más adecuada, como Go, cuando de verdad mejora las cosas.
- Pruebas y operación en paralelo. Antes de mover el tráfico, la versión nueva corre junto a la anterior y comparamos resultados.
- Siempre con vuelta atrás. Si algo no se comporta como esperamos, el tráfico regresa al componente anterior sin que el cliente lo note.
Para decidir qué camino toma cada componente miramos cinco cosas:
- Qué hace: no es lo mismo una API de facturación que un reporte interno.
- Riesgo y exposición: lo que atiende peticiones desde internet va primero.
- Si existe una ruta de actualización soportada: si la hay, muchas veces actualizar es suficiente.
- Las habilidades del equipo: una tecnología que nadie puede mantener es otra deuda en camino.
- Las necesidades de rendimiento: ahí es donde Go suele marcar la diferencia.
05 / CLIENTESLo mismo que hacemos en casa, lo hacemos con ustedes
Esto no es solo un tema interno. Muchos de nuestros clientes también operan plataformas antiguas y sin soporte: aplicaciones en PHP, centrales telefónicas y sistemas de telefonía de otra época, CRMs que nadie se anima a tocar. Siguen funcionando, y justamente por eso nadie quiere moverlos.
Hoy los estamos acompañando con el mismo criterio:
- Revisión inicial: un diagnóstico de qué está expuesto a internet y qué ya no tiene soporte.
- Parches urgentes: donde todavía se puede, se actualiza primero.
- Aislar y poner un proxy al frente: lo que no se puede parchear deja de estar expuesto directamente.
- Plan de migración por etapas: pieza por pieza, sin detener su operación.
- Acompañamiento durante la transición: no entregamos un informe y nos vamos; estamos mientras se hace el cambio.
06 / CONTINUIDADMigrar no es apagar todo y empezar de nuevo
La continuidad del negocio es fundamental. Migrar significa avanzar por etapas, realizar pruebas y reducir riesgos sin interrumpir los servicios que nuestros clientes usan todos los días.
07 / REFLEXIÓNNi todo lo que funciona es seguro, ni todo lo viejo se tira
Que un sistema funcione no significa que sea seguro. Y que sea antiguo no significa que debamos reemplazarlo todo.
El verdadero reto está en identificar qué conservar, qué actualizar, qué aislar y qué migrar.
En PortalPBX apostamos por una modernización progresiva, priorizando la seguridad, la estabilidad y la continuidad operativa.
Porque modernizar no es simplemente cambiar PHP por Go. Es construir una arquitectura preparada para los próximos años.
Si quieres saber por qué esto se volvió urgente, hace poco escribí sobre PHP2Shell y por qué conviene actualizar PHP ya. Y si tienes un sistema legacy y no sabes por dónde empezar, escríbeme por el contacto de joseareche.com.
