El costo de postergar el mantenimiento de sitios web

Una integración dejó de actualizarse, el formulario usa un complemento antiguo y nadie recuerda por qué cierta página carga dos veces. El problema aparece cuando esas decisiones que alguna vez fueron razonables empiezan a encarecer cada cambio nuevo: una modificación simple requiere más horas, más pruebas y más precauciones que antes.

No todo lo antiguo necesita reemplazarse. Un componente estable puede seguir funcionando durante años sin generar problemas. La señal de alerta aparece cuando esa antigüedad empieza a afectar seguridad, rendimiento, integraciones o facilidad de actualización, y obliga a invertir cada vez más tiempo y dinero para mantener el sitio funcionando o adaptarlo a nuevas necesidades.

Postergarla parece ahorrar presupuesto porque el costo no aparece en una factura única. Se reparte entre horas de diagnóstico, incidentes, campañas demoradas y tareas manuales. Esa fragmentación dificulta justificar una intervención hasta que ocurre una falla visible.

El problema es que ese costo casi nunca llega de golpe. Se acumula en pequeñas demoras que parecen normales: una campaña que espera porque nadie se anima a tocar una integración, un formulario que falla justo cuando empieza una acción comercial o un cambio que debería llevar una hora y termina ocupando varios días. Como ninguna de esas situaciones parece justificar por sí sola un proyecto de mantenimiento, se siguen postergando. Hasta que dejan de ser pequeñas.

La conversación mejora cuando Técnica y Dirección comparten un lenguaje de consecuencias. En lugar de discutir si algo es antiguo, pueden comparar riesgo, horas perdidas, dependencia y efecto sobre recorridos críticos.

El cambio que debía llevar una hora terminó frenando una campaña

Imaginá la siguiente situación. Una empresa prepara durante semanas el lanzamiento de un nuevo servicio. Comercial ya invitó a clientes, Marketing contrató una campaña y Dirección aprobó la fecha. Dos días antes de salir necesitan hacer algo aparentemente sencillo: agregar un nuevo campo al formulario de consultas para identificar de qué sector proviene cada oportunidad.

El desarrollador descubre que ese formulario depende de un complemento que no se actualiza desde hace años. Actualizarlo rompe una integración con el CRM; dejarlo como está impide hacer el cambio con seguridad. Aparecen además dos versiones distintas de una plantilla y nadie recuerda por qué una de ellas fue modificada manualmente. La campaña no se cancela, pero se posterga una semana mientras varias personas intentan reconstruir decisiones técnicas tomadas años atrás.

El costo del mantenimiento postergado no fue solamente el tiempo del programador. Fue presupuesto publicitario reprogramado, horas de Marketing y Comercial, una fecha de lanzamiento perdida y una Dirección preguntando por qué un campo nuevo terminó afectando a media empresa. La deuda técnica suele hacerse visible exactamente así: cuando el negocio necesita avanzar y descubre que la web ya no puede acompañarlo con la misma velocidad.

El mantenimiento no sólo evita fallas. También protege resultados. Porque está comprobado que las empresas que no esperan a que el sitio falle, sino que revisan de forma periódica su velocidad, estabilidad, formularios y navegación, consiguen detectar y corregir antes los problemas que pueden afectar la experiencia del usuario.

Esto se demuestra en un análisis de Contentsquare en 2025…

Por eso es bueno que sepas que postergar mantenimiento reduce poco a poco la capacidad de la empresa para cambiar, vender y operar con tranquilidad.

Qué incluye un servicio de mantenimiento web bien priorizado

Una web puede funcionar perfectamente y, sin embargo, haberse vuelto difícil de cambiar. Ésa es una de las formas más engañosas de riesgo técnico: desde afuera no hay ninguna alarma, pero puertas adentro cada modificación exige más tiempo, más pruebas y más personas que antes.

También aparece cuando nadie se anima a tocar determinadas partes del sitio porque “siempre funcionaron así”. Una integración cuyo funcionamiento conoce una sola persona, un complemento que hace años no se actualiza o una plantilla modificada tantas veces que nadie sabe cuál es la versión correcta pueden permanecer invisibles durante meses. El problema aparece cuando el negocio necesita usarlos para algo nuevo.

“

A veces parece que hay más soluciones que problemas. Al examinarlo más de cerca, resulta que muchos de los problemas actuales son resultado de soluciones de ayer.

Un mantenimiento bien priorizado empieza por aquello que puede afectar el funcionamiento del negocio. Primero conviene mirar seguridad, versiones sin soporte, formularios, procesos de contacto e integraciones con otras herramientas. Después entran cuestiones como velocidad, estabilidad, facilidad para actualizar contenidos y compatibilidad con nuevas necesidades. La lógica es simple: atender antes lo que puede frenar una consulta, comprometer información o volver más costoso un cambio futuro.

También importa distinguir lo urgente de lo importante. No todo lo pendiente merece resolverse al mismo tiempo, ni todo lo visible es necesariamente prioritario. Una mejora estética puede esperar si el sitio sigue funcionando bien. En cambio, un formulario que falla de manera intermitente, una integración que depende de un único proveedor o una actualización que nadie se anima a realizar porque podría romper otra parte del sistema merecen más atención. Priorizar mantenimiento significa, en definitiva, proteger primero aquello que sostiene la operación, la confianza y la capacidad de seguir cambiando sin sobresaltos.

Equifax: la actualización que parecía poder esperar

Seguramente conocerás el sistema de información crediticia y financiera conocido como Veraz, ¿verdad? Bueno, Equifax opera en Argentina comercializando y administrando Veraz. Te cuento una historia inquietante…

En marzo de 2017 se informó a Equifax de una vulnerabilidad crítica en Apache Struts, software utilizado por una aplicación web de la compañía. Internamente se había ordenado instalar la corrección, pero el proceso falló: la lista de destinatarios estaba desactualizada y el sistema vulnerable no fue identificado correctamente. Meses después, hackers, aprovechando la demora de resolución en Equifax, accedieron a información personal de aproximadamente 147 millones de personas.

Si bien el parche existía, el problema fue que una tarea de mantenimiento conocida no llegó correctamente al sistema que la necesitaba. La FTC (organismo federal de Estados Unidos) sostuvo después que Equifax no verificó que la orden de parchear se hubiera cumplido y el caso terminó en un acuerdo de hasta USD 700 millones.

Increíble, ¿no? Claro que la mayoría de las empresas B2B argentinas nunca enfrentarán algo de esa magnitud, pero el mecanismo es reconocible. Una actualización se posterga porque “todo sigue funcionando”; el riesgo permanece invisible; y sólo se descubre cuánto costaba no hacerla cuando aparece el incidente.

Los costos que suelen quedar fuera del presupuesto

Cada modificación puede requerir más tiempo del esperado cuando el sitio acumula años de cambios sin una revisión ordenada, o si está poco documentado, muy parcheado o depende de componentes antiguos.

En ese caso el proveedor no sabe con certeza cuánto tiempo llevará hacer un cambio sin generar otro problema. Porque el equipo investiga cómo funciona algo, prepara respaldos, prueba efectos laterales y corrige regresiones. El costo no es sólo programar: es recuperar confianza en un sistema poco conocido.

También puede encarecer el trabajo de proveedores externos. Cuando el sitio está ordenado y bien documentado, es más fácil estimar tiempos y costos. Cuando nadie sabe con precisión qué puede romperse al hacer un cambio, el presupuesto suele incluir más horas de revisión, pruebas y contingencia.

El deterioro tampoco se limita al área técnica. Una página que carga cada vez más lento puede reducir el rendimiento de una campaña; un formulario inestable puede hacer desaparecer una consulta sin que nadie lo advierta; una pieza de software sin soporte puede convertir un cambio postergado en un riesgo de seguridad.

Para Dirección son problemas diferentes. Para el visitante sólo existe una experiencia: funciona o no funciona, transmite confianza o genera dudas.

Cómo priorizar sin convertir todo en urgente

No todo lo pendiente merece la misma urgencia. Una animación imperfecta puede esperar; un formulario que pierde consultas o una dependencia sin soporte, probablemente no. La prioridad debería surgir de combinar qué puede fallar, cuánto afectaría al negocio, qué esfuerzo requiere corregirlo y qué otras mejoras dependen de esa decisión. Ese es justamente el trabajo que propone la matriz descargable al final del artículo.

Dirección no necesita saber qué biblioteca JavaScript quedó antigua ni memorizar versiones de cada complemento. Necesita poder responder preguntas más simples: ¿qué puede interrumpir ventas?, ¿qué nos impide hacer cambios rápidamente?, ¿qué estamos sosteniendo manualmente porque nunca resolvimos el problema de fondo?

Cuando Técnica puede responder esas preguntas en términos de tiempo, riesgo e impacto comercial, el mantenimiento deja de parecer un gasto indefinido. Se convierte en una decisión sobre cuánto margen quiere conservar la empresa para seguir cambiando sin poner en riesgo lo que ya funciona.

Lo barato sale caro cuando el ahorro consiste en aplazar mantenimiento sin entender consecuencias. Reducir deuda técnica por falta de actualizaciones web no es perseguir perfección: es recuperar capacidad de cambiar sin que cada avance ponga en riesgo lo que ya funciona.

Descubrí qué conviene arreglar primero

La matriz, que abajo podés descargar, empieza ayudándote a saber si realmente conocés el atraso técnico de tu sitio. Revisa seis cuestiones: si existe un inventario de problemas, si cada uno tiene evidencia, si se distingue riesgo de impacto comercial, si se tienen en cuenta las dependencias, si cada tarea tiene un responsable y si las prioridades cuentan con una fecha. La idea es dejar de decidir mantenimiento según cuál fue el último problema que hizo más ruido.

Después, la matriz separa los hallazgos por áreas concretas —seguridad y versiones, rendimiento, formularios, SEO, integraciones y contenido/CMS— y permite comparar riesgo, impacto, esfuerzo y dependencias. Esto ayuda a distinguir, por ejemplo, una corrección pequeña pero importante de otra muy visible que en realidad puede esperar.

Por último, la herramienta obliga a tomar decisiones: identificar el problema con mayor riesgo e impacto, encontrar una mejora rápida de alto valor, reconocer qué dependencia está bloqueando varias correcciones y decidir qué debería entrar en el próximo trimestre. Después elegís hasta tres prioridades, asignando una primera acción, responsable y fecha.

Descargá la matriz de deuda técnica y priorizá cada hallazgo por riesgo, impacto comercial, esfuerzo y dependencia.