El ahorro que se puede obtener al rediseñar un sitio web conservando el backend existente depende de cuántas capacidades del sistema antiguo puedan reutilizarse directamente. Si las funciones de gestión de productos, publicación de contenidos, seguimiento de consultas y permisos satisfacen las necesidades del sitio rediseñado, conservar el backend puede reducir los costes de reconstruir estos módulos y parte de los gastos de migración de datos. Si las nuevas páginas requieren muchas modificaciones de las interfaces y el sistema antiguo acumula tareas de mantenimiento pendientes, el margen de ahorro se reducirá.
Por eso, al aprobar el presupuesto del rediseño web (costo de rediseño web), no conviene aplicar directamente un porcentaje de «cuánto se ahorra al conservar el backend». Una forma más fundamentada es pedir a los proveedores presupuestos para ambos escenarios con el mismo alcance de entrega y, después, calcular el coste adicional de compatibilidad, correcciones y mantenimiento continuo que implica conservar el sistema.
En los sitios web de empresas de comercio exterior o fábricas manufactureras, el backend puede gestionar ya las categorías de productos, los parámetros técnicos, las descargas de documentos, los contenidos multilingües y las consultas de ventas. Conservar estas funciones puede reducir el trabajo de desarrollo, importación de datos históricos, configuración de permisos de cuentas y capacitación del personal.
Sin embargo, el diseño de páginas, la adaptación a dispositivos móviles, el desarrollo del frontend, la compatibilidad con navegadores y las pruebas previas a la publicación siguen teniendo que realizarse conforme a los nuevos requisitos. Aunque la base de datos permanezca intacta, si cambia la forma en que las nuevas páginas utilizan las imágenes de productos, los filtros y los campos de los formularios, es posible que haya que modificar las interfaces y las plantillas.
«Conservar el backend» puede referirse a distintos alcances. Conservar solo los datos, conservar la interfaz de administración existente o conservar también las interfaces y el entorno de despliegue implican cargas de trabajo diferentes. Si el presupuesto solo indica «mantener el sistema existente», al departamento financiero le resultará difícil determinar qué costes se han eliminado realmente.
Se puede pedir al proveedor que desglose los costes en tres partes: el diseño y el trabajo de frontend necesarios en ambos escenarios; el trabajo de reconstrucción del backend y migración que se evita con la opción de conservarlo; y las tareas adicionales de adaptación y corrección que esta opción requiere. La diferencia entre las dos últimas partidas se aproxima al ahorro real de este rediseño.
Ahorro neto inicial = coste total de la reconstrucción con el mismo alcance − coste total de la opción que conserva el backend. Ambos presupuestos deben incluir la misma cantidad de páginas, versiones lingüísticas, funciones, pruebas, asistencia para la puesta en marcha e impuestos; de lo contrario, la diferencia podría deberse a una reducción del alcance de la entrega.
Un ejemplo hipotético, utilizado únicamente para ilustrar el método de cálculo: si la reconstrucción completa cuesta 100.000 yuanes y el rediseño básico conservando el backend cuesta 70.000, parece que se ahorran 30.000 yuanes. Pero si la adaptación de interfaces, las correcciones del sistema antiguo y las pruebas adicionales cuestan 10.000 más, el coste inicial total de la opción de conservación será de 80.000 yuanes y el ahorro real, de 20.000 yuanes, es decir, el 20 % del presupuesto de reconstrucción. Estas cifras solo muestran la lógica del cálculo y no representan precios de mercado ni promedios del sector.
A continuación, también hay que tener en cuenta los gastos posteriores. Supongamos que, durante el mismo periodo de comparación, los costes de licencias, mantenimiento y actualizaciones necesarias de la opción de conservación superan en 10.000 yuanes los de la reconstrucción. El ahorro acumulado se reduciría entonces a 10.000 yuanes. Al solicitar la aprobación, se debe elegir un periodo de comparación que se ajuste al plan de uso de la empresa y diferenciar los costes confirmados de los que se activan según determinadas condiciones.

Entre los gastos que se omiten con más facilidad en este tipo de presupuestos están las renovaciones de plugins antiguos, los costes de uso de interfaces, el traspaso entre proveedores, la exportación de datos y el mantenimiento del entorno antiguo. Para los trabajos de adaptación aún no evaluados, el contrato debe especificar el alcance de la evaluación, el método de cálculo de precios y las condiciones de aprobación de cambios, a fin de evitar que se añadan costes continuamente después de firmar un contrato de bajo precio.
Conservar el backend está más justificado cuando el rediseño busca principalmente actualizar una apariencia anticuada, mejorar la experiencia en dispositivos móviles y presentar mejor los contenidos, mientras los procesos empresariales del backend apenas cambian. Para ello, la empresa debe poder obtener los permisos de administración y la documentación de las interfaces necesarios, así como disponer de código o asistencia técnica de acuerdo con el método de mantenimiento. Además, el equipo que asuma el sistema debe poder desplegarlo y resolver incidencias.
Si el rediseño incluye rehacer la estructura multilingüe, mejorar los filtros de productos, incorporar transacciones de comercio electrónico o integrar un sistema de gestión de clientes, primero hay que comprobar la capacidad del sistema antiguo para admitir estos cambios. Por ejemplo, si el backend original solo dispone de un campo de descripción del producto y el nuevo sitio requiere gestionar por separado, en cada idioma, los parámetros, los archivos descargables y la información de búsqueda, mantener el backend también puede exigir modificaciones importantes.
Antes de solicitar la aprobación, se puede pedir al responsable técnico que responda claramente a las siguientes preguntas:
Si estas preguntas no tienen respuestas claras, no habrá fundamento suficiente para el bajo presupuesto de conservar el backend. En los sistemas que solo puede modificar el proveedor original, también se deben comparar los plazos de respuesta, las tarifas unitarias de los cambios y las condiciones de salida, para evitar que el ahorro de un único rediseño se convierta en gastos de mantenimiento a largo plazo que generen dependencia.
Conservar el backend no equivale a conservar el tráfico de búsqueda ni el rendimiento de los anuncios. El rediseño puede cambiar las direcciones de las páginas, la estructura de los contenidos, la forma de enviar los formularios y el seguimiento de conversiones. La redirección de las direcciones antiguas, la llegada de las consultas al proceso de ventas correcto y el registro preciso de las conversiones publicitarias deben incluirse en el alcance de la entrega y la aceptación.
Si la empresa también contrata herramientas publicitarias como sistema de marketing publicitario inteligente AI+SEM, se deben detallar por separado los costes de integración y aceptación correspondientes, y comprobar que el sitio web proporciona todos los datos necesarios para supervisar los indicadores clave y realizar análisis de datos. La herramienta ofrece funciones de seguimiento, pero el sitio web también debe configurarse correctamente para que sea posible comparar los resultados antes y después del rediseño.
En los sitios web con campañas publicitarias continuas, el plan de lanzamiento también debe incluir pruebas de formularios, comprobaciones de las páginas de destino clave y preparativos para revertir los cambios. Es difícil calcular de antemano con precisión la posible pérdida de consultas, por lo que el riesgo puede reducirse mediante criterios de aceptación. No conviene exagerar las ventajas de una opción con previsiones de ingresos sin fundamento.
El presupuesto presentado para su aprobación debe indicar claramente cuánto trabajo de reconstrucción se ha evitado, cuánto gasto adicional implica conservar el sistema antiguo y qué otros costes confirmados habrá durante el periodo de comparación. Si la diferencia está respaldada por un desglose, las funciones han superado la validación y las responsabilidades de mantenimiento están claras, conservar el backend supone un ahorro cuantificable. Si la ventaja depende principalmente de partidas omitidas y costes adicionales posteriores, el menor precio que figura en el presupuesto no puede servir de fundamento para tomar una decisión.
Artículos relacionados
Productos relacionados


