Migración a la nube en ayuntamientos: cómo contratar un proyecto cloud con seguridad y control

La migración a la nube en ayuntamientos puede mejorar escalabilidad, continuidad y capacidad de evolución tecnológica, pero no debería plantearse como un simple traslado de servidores. Una Administración necesita decidir qué cargas tiene sentido mover, qué modelo cloud necesita, cómo protegerá la información y qué ocurrirá si en el futuro cambia de proveedor.

El objetivo no es “estar en la nube”, sino construir una arquitectura que facilite operar servicios públicos con mayor control y menor dependencia de infraestructuras obsoletas. En algunos casos será adecuado un servicio SaaS; en otros, una plataforma PaaS, infraestructura IaaS o un modelo híbrido con sistemas que permanezcan en entornos municipales.

Antes de contratar conviene relacionar el proyecto con la estrategia de digitalización de la Administración Pública, el Esquema Nacional de Seguridad y las necesidades reales de cada servicio.

Cuándo tiene sentido migrar a cloud

La nube puede ser útil cuando la infraestructura actual está próxima al final de su vida útil, cuando existen problemas de capacidad, cuando se necesita alta disponibilidad o cuando nuevas aplicaciones requieren desplegarse con mayor flexibilidad.

También puede facilitar proyectos de integración, análisis de datos, automatización o inteligencia artificial que necesitan servicios gestionados.

Una auditoría tecnológica municipal permite identificar qué cargas son buenas candidatas y cuáles deberían mantenerse o modernizarse primero.

No todo debe migrarse

Trasladar una aplicación antigua sin revisar arquitectura puede mover los mismos problemas a una factura cloud. Antes de migrar conviene analizar dependencia de sistemas operativos, bases de datos, licencias, latencia, integraciones y soporte.

Algunas cargas pueden modernizarse; otras pueden sustituirse por un servicio SaaS; y otras pueden seguir siendo más adecuadas en infraestructura local o compartida.

La decisión debe tomarse por servicio y no mediante una regla única.

Inventario de cargas y dependencias

El proyecto debería comenzar con un inventario de servidores, aplicaciones, bases de datos, almacenamiento, integraciones, usuarios y niveles de criticidad.

Cada carga debe relacionarse con sus dependencias. Una aplicación aparentemente sencilla puede necesitar una base de datos, un directorio, certificados, carpetas compartidas y conexiones con varios sistemas.

La guía sobre integración de sistemas municipales ayuda a identificar estas relaciones.

Clasificar por criticidad

No todos los servicios tienen el mismo impacto. Una web informativa puede tolerar una ventana de mantenimiento distinta de un gestor de expedientes o una plataforma de atención ciudadana.

Conviene clasificar cargas por disponibilidad, pérdida máxima de datos aceptable, tiempo de recuperación y horarios críticos.

Esta clasificación orientará arquitectura, copias, redundancia y presupuesto.

SaaS, PaaS e IaaS

En SaaS, el proveedor entrega la aplicación completa. En PaaS, ofrece servicios gestionados para ejecutar aplicaciones. En IaaS, la entidad o adjudicatario administra máquinas, redes y almacenamiento sobre infraestructura cloud.

No existe un modelo mejor para todos los casos. SaaS reduce operación pero puede limitar personalización; IaaS ofrece más control pero exige más mantenimiento.

El pliego debe definir el resultado y responsabilidades más que imponer un modelo sin justificar.

Cloud pública, privada e híbrida

Un ayuntamiento puede combinar servicios de nube pública con infraestructura propia o servicios de otras Administraciones. La arquitectura híbrida puede ser adecuada cuando ciertas aplicaciones no pueden migrarse de inmediato.

El reto está en gestionar conectividad, identidad, seguridad y monitorización de forma coherente.

Una arquitectura fragmentada sin gobierno puede ser más compleja que el entorno original.

ENS y selección del proveedor

El servicio cloud debe analizarse dentro del marco del Esquema Nacional de Seguridad y de la categorización de los sistemas afectados.

El pliego debería solicitar evidencias y condiciones acordes al servicio, evitando limitarse a logotipos o declaraciones comerciales.

La guía sobre ENS para ayuntamientos ayuda a estructurar control de accesos, continuidad y gestión de terceros.

Ubicación y tratamiento de datos

La entidad debe conocer dónde se almacenan y procesan sus datos, qué proveedores intervienen y qué mecanismos existen para moverlos o eliminarlos.

El contrato debe evitar ambigüedades sobre regiones, subencargados y copias.

También conviene documentar qué información puede salir de la infraestructura principal durante soporte, backup o análisis.

Identidad y acceso

La migración es una oportunidad para centralizar autenticación y revisar permisos. Las cuentas privilegiadas deben estar especialmente protegidas.

Conviene aplicar mínimo privilegio, autenticación reforzada y trazabilidad de operaciones administrativas.

No deberían mantenerse cuentas genéricas o credenciales compartidas por comodidad.

Red y conectividad

Las aplicaciones cloud dependen de la conectividad. El proyecto debe analizar ancho de banda, redundancia, latencia y acceso desde sedes municipales.

Una aplicación puede funcionar técnicamente y ofrecer una mala experiencia si la conexión no está dimensionada.

También debe definirse qué servicios pueden seguir operando durante una incidencia de conectividad.

VPN, enlaces privados y exposición pública

No todos los componentes deben estar accesibles desde Internet. Bases de datos y servicios internos pueden utilizar redes privadas o mecanismos específicos de conexión.

El pliego debe separar interfaces públicas, APIs y componentes internos.

Las reglas de firewall y acceso deben quedar documentadas y revisarse periódicamente.

Base de datos

La migración de una base de datos requiere analizar versión, tamaño, compatibilidad, rendimiento, copias y ventanas de corte.

Puede mantenerse en máquina virtual o utilizar un servicio gestionado, según requisitos.

Las pruebas deben realizarse con volúmenes representativos y consultas reales.

Almacenamiento documental

Expedientes, documentos e imágenes pueden representar gran parte del volumen. La estrategia debe definir niveles de almacenamiento, copias y conservación.

La guía sobre archivo electrónico único ayuda a diferenciar disponibilidad operativa y preservación.

No debe confundirse un repositorio cloud con una política de archivo.

Gestor de expedientes

Si el proyecto afecta al gestor, deben mantenerse metadatos, firmas, índices e integraciones.

La migración de un gestor de expedientes necesita un plan específico de reconciliación y continuidad.

Trasladar únicamente la infraestructura no resuelve por sí mismo problemas de arquitectura o datos.

Aplicaciones a medida

Las aplicaciones desarrolladas específicamente pueden beneficiarse de contenedores, servicios gestionados, almacenamiento escalable y despliegues automatizados.

La guía sobre software a medida para Administraciones Públicas explica cómo combinar arquitectura, código, repositorios y mantenimiento.

Antes de migrar conviene comprobar si es necesario actualizar versiones o dependencias.

Automatizaciones e integraciones

Los flujos que conectan sistemas deben actualizar endpoints, credenciales y reglas de red cuando cambia la infraestructura.

La migración debe probar procesos completos y no únicamente servidores aislados.

La automatización municipal necesita monitorización especialmente cuidada durante el cambio.

Plan de migración por oleadas

Una estrategia habitual es dividir cargas por grupos. Puede comenzarse por servicios de menor riesgo, aprender de la primera fase y después abordar sistemas críticos.

Cada oleada debe tener inventario, dependencias, pruebas, fecha de corte y reversión.

Este enfoque reduce el impacto de errores y permite ajustar arquitectura antes de mover todo.

Prueba piloto

El piloto debería validar conectividad, rendimiento, seguridad, backups y operación. No debe limitarse a encender una máquina en cloud.

Conviene utilizar una carga representativa y medirla antes y después.

Los resultados deben quedar documentados para decidir el paso a producción.

Fecha de corte y coexistencia

Durante una migración puede ser necesario mantener origen y destino temporalmente. Debe definirse cuál es el sistema maestro y cómo se sincronizan cambios.

La ventana de corte debe coordinarse con usuarios y servicios afectados.

También se necesita un plan para volver al entorno anterior si aparecen incidencias graves.

Copias de seguridad

La nube no elimina la necesidad de diseñar backups. El contrato debe establecer frecuencia, retención, ubicación y pruebas de restauración.

Puede ser conveniente separar copias del entorno principal para reducir riesgos.

Las restauraciones deben probarse, no únicamente comprobar que existe una tarea programada.

Continuidad y recuperación

Los servicios críticos necesitan objetivos de recuperación claros. La arquitectura puede utilizar redundancia, regiones, réplicas o procedimientos manuales según impacto y presupuesto.

El nivel de resiliencia debe corresponderse con la criticidad real.

No tiene sentido pagar una arquitectura extrema para un servicio que tolera horas de indisponibilidad, ni infradimensionar un servicio crítico.

Monitorización

El ayuntamiento debe poder conocer disponibilidad, consumo, errores y rendimiento. La monitorización puede centralizar infraestructura y aplicaciones.

Las alertas deben tener responsables y umbrales definidos.

La guía sobre mantenimiento de software municipal ayuda a convertir esas métricas en SLA y procedimientos de soporte.

Costes cloud

El coste no se limita a máquinas virtuales. Incluye almacenamiento, tráfico, backups, bases de datos, observabilidad, licencias y soporte.

El pliego debe solicitar un modelo económico transparente y escenarios de crecimiento.

Una arquitectura sobredimensionada puede generar un coste recurrente muy superior al previsto.

FinOps y control presupuestario

Es recomendable etiquetar recursos por servicio o proyecto y establecer presupuestos, alertas y revisiones periódicas.

El ayuntamiento debería poder identificar qué aplicación genera cada coste.

Esta disciplina facilita optimizar recursos sin perder visibilidad del servicio.

Escalabilidad automática

La capacidad de escalar puede ser útil en servicios con picos, pero debe configurarse con límites para evitar costes inesperados.

No todas las aplicaciones están preparadas para escalar horizontalmente.

El proyecto debe probar comportamiento bajo carga y mecanismos de reducción de capacidad.

Vendor lock-in

Utilizar servicios gestionados puede aportar mucho valor, pero también aumentar dependencia. El pliego debe evaluar qué componentes son portables y qué esfuerzo requeriría cambiarlos.

No es necesario evitar cualquier servicio propietario; lo importante es conocer la dependencia y disponer de una estrategia de salida.

La documentación de datos, APIs y despliegues es fundamental.

Reversibilidad

La Administración debe saber cómo exportar datos, configuraciones y aplicaciones al finalizar el contrato.

El adjudicatario debería entregar procedimientos, formatos y documentación suficientes para una transición.

La reversibilidad también debe incluir cuentas, dominios, certificados y repositorios relacionados.

Gobierno cloud y oficina técnica

Cuando la migración afecta a varias aplicaciones conviene definir responsables, políticas comunes y un calendario de revisión. Una asistencia técnica de transformación digital puede coordinar proveedores, costes y riesgos, mientras que la categoría de arquitectura digital permite relacionar el proyecto con decisiones de infraestructura, integración y evolución a largo plazo.

Este gobierno evita que cada departamento contrate recursos cloud de forma aislada y facilita mantener una arquitectura coherente, documentada y económicamente controlada.

Infraestructura como código

Cuando la arquitectura lo permita, definir infraestructura mediante código facilita reproducir entornos, revisar cambios y transferir conocimiento.

Los repositorios deben quedar documentados y con acceso institucional según contrato.

Esto puede reducir configuraciones manuales difíciles de reconstruir.

DevOps y despliegues

Una aplicación cloud puede beneficiarse de pipelines de pruebas y despliegue, pero necesitan control y separación de entornos.

Cada release debería ser trazable y disponer de mecanismos de rollback.

Las credenciales de despliegue deben protegerse adecuadamente.

Seguridad de la cadena de suministro

Frameworks, imágenes de contenedor y librerías externas deben mantenerse actualizados.

El mantenimiento debe contemplar vulnerabilidades y componentes sin soporte.

El proveedor debe documentar dependencias principales y procedimiento de actualización.

Cómo preparar el pliego cloud

El pliego debería definir inventario, cargas, criticidad, modelo de servicio, seguridad, migración, pruebas, costes, monitorización, soporte y reversibilidad.

La guía de pliego técnico para digitalización municipal ofrece una estructura general.

También debe quedar clara la responsabilidad entre proveedor cloud, adjudicatario y Ayuntamiento.

Criterios de aceptación

La aceptación puede comprobar rendimiento, disponibilidad, restauración, seguridad, integraciones y costes previstos.

Los casos deben utilizar cargas reales o representativas.

La migración no debería considerarse terminada hasta superar una fase de estabilización.

Criterios técnicos de adjudicación

Puede valorarse arquitectura, estrategia de migración, seguridad, continuidad, optimización de costes, documentación y reversibilidad cuando estén relacionados con el objeto.

También conviene valorar cómo el proveedor gestionará cambios y soporte.

La propuesta debe mostrar capacidad real de operación, no únicamente certificaciones comerciales.

Qué puede aportar BlackHold Consulting

BlackHold Consulting trabaja en proyectos de digitalización e integración de procesos, automatización de procesos, automatización administrativa e integración documental.

También dispone de capacidades aplicables a procesos complejos, consultoría tecnológica, agentes e integraciones y servicios de automatización. Estas capacidades pueden aplicarse a modernización, integración y migración cloud cuando la contratación pública correspondiente así lo determine.

Checklist antes de contratar una migración cloud

Inventario

¿Se conocen cargas, datos y dependencias?

Criticidad

¿Cada servicio tiene objetivos de disponibilidad y recuperación?

Seguridad

¿Se han analizado ENS, accesos y tratamiento de datos?

Conectividad

¿La red soportará las aplicaciones migradas?

Costes

¿Existe un modelo económico completo y medible?

Pruebas

¿Hay piloto, rendimiento y restauración?

Mantenimiento

¿Está definida la operación después de migrar?

Reversibilidad

¿La entidad puede mover datos y cargas a otro entorno?

Preguntas frecuentes

Conclusión

Una migración cloud municipal debe ser un proyecto de arquitectura y continuidad, no una simple mudanza de servidores. El ayuntamiento necesita conocer sus cargas, dependencias, riesgos y costes antes de elegir el destino.

La seguridad, la monitorización, el control presupuestario y la reversibilidad deben formar parte del contrato desde el principio. Una arquitectura bien diseñada puede facilitar nuevas integraciones y servicios sin perder el control institucional.

Cuando la entidad necesita modernizar aplicaciones, automatizar despliegues o integrar sistemas en una nueva infraestructura, contar con un equipo capaz de combinar arquitectura, desarrollo e integración puede reducir el riesgo de la transición y acelerar la puesta en producción.

Fotografía: panumas nikhomkhai / Pexels.