Migrar a la nube compensa a una empresa de Madrid cuando cada aplicación tiene decidida su estrategia y su región en la UE antes de mover un solo servidor. AWS (eu-south-2, Aragón), Microsoft Azure (Spain Central, Madrid) y Google Cloud (europe-southwest1, Madrid) tienen región en España, así que el método pesa más que el proveedor. Lo aplica nuestro equipo de desarrollo a medida en Madrid.
Una migración mal planificada se paga dos veces. Mientras el sistema antiguo y el nuevo conviven, facturas los dos, y si la aplicación sube sin cambios arrastra el dimensionado que tenía en el servidor físico, ahora cobrado por horas. Si además nadie ensayó la vuelta atrás, una parada en plena campaña se convierte en pedidos perdidos.
Al terminar sabrás qué estrategia dar a cada aplicación y qué exigir al proveedor, partiendo del tipo de hosting y arquitectura que tienes hoy.
Qué Es Migrar a la Nube y Qué Cambia para tu Empresa
Migrar a la nube es trasladar aplicaciones y datos desde servidores propios o un hosting tradicional a la infraestructura de un proveedor cloud, que se gestiona por API y se factura por uso. Cambia quién mantiene el hardware y cómo pagas, pero la responsabilidad sobre los datos y los accesos sigue siendo de tu empresa.
Los proveedores llaman a ese reparto modelo de responsabilidad compartida: ellos protegen la infraestructura física y tú configuras los permisos y las copias de seguridad con su plan de recuperación ante desastres.
AWS, Azure o Google Cloud para Empresas de Madrid
Los tres grandes proveedores tienen en España una región con tres zonas de disponibilidad, y la elección suele depender de lo que tu empresa ya usa:
- AWS: Región: Europa (España), eu-south-2, en Aragón. Encaja si: tu equipo ya trabaja con AWS o tu software de terceros lo exige.
- Microsoft Azure: Región: Spain Central, en Madrid. Encaja si: tu empresa trabaja con Microsoft 365 y Microsoft Entra ID y quieres reutilizar identidades.
- Google Cloud: Región: europe-southwest1, en Madrid. Encaja si: tu analítica vive en BigQuery o despliegas contenedores en Cloud Run.
Si tu duda está entre infraestructura completa y una red perimetral delante de tu web, revisa la comparativa de Google Cloud frente a Cloudflare.
Qué Estrategia de Migración Cloud Dar a Cada Aplicación
La guía de AWS reúne siete estrategias de migración cloud, conocidas como las 7 R de las estrategias de migración. Estas son las que más se comparan al revisar el inventario de una empresa mediana:
- Rehost (lift and shift): mueves la aplicación sin cambiar código. Úsalo cuando: manda el plazo, como el fin de contrato del centro de datos. Evítalo cuando: la aplicación ya va justa de recursos.
- Replatform: cambias piezas sin tocar la arquitectura, como pasar la base de datos a un servicio gestionado o desplegar en una plataforma PaaS gestionada. Úsalo cuando: quieres eliminar parches y copias manuales sin reescribir.
- Refactor: rediseñas la aplicación con servicios nativos. Úsalo cuando: el negocio necesita escalar por picos y el código lo permite. AWS desaconseja refactorizar en migraciones grandes y recomienda modernizar después de mover.
- Retire o retain: retiras lo que nadie usa y retienes lo que aún no conviene mover, con un plan para modernizar la aplicación legacy sin parar el negocio.
Si la aplicación se rehace en la nube, la elección entre funciones serverless o contenedores fija buena parte de la factura, y conviene tener desde el primer mes la factura cloud bajo control con FinOps.
Región en la UE, RGPD y Salida del Proveedor
Elegir una región en la UE mantiene los datos dentro del Espacio Económico Europeo, pero no sustituye el contrato de encargo del tratamiento que exige el artículo 28 del Reglamento (UE) 2016/679.
Desde el 12 de septiembre de 2025 se aplica además el Reglamento (UE) 2023/2854 de Datos, que obliga a los proveedores cloud a facilitar el cambio:
- Preaviso máximo: dos meses para iniciar el cambio de proveedor (artículo 25).
- Periodo transitorio: hasta treinta días naturales para trasladar datos y activos con el servicio en marcha (artículo 25).
- Costes por cambio: hasta el 12 de enero de 2027 solo pueden cobrar los costes directos del cambio y desde esa fecha ninguno (artículo 29).
CodeZone Pro Tip: tras la migración, comprueba cada noche que ningún recurso de AWS se ha creado fuera de las regiones de la UE pactadas.
import boto3
# Regiones autorizadas en el plan de migración: España y, como respaldo, Irlanda
PERMITIDAS = {"eu-south-2", "eu-west-1"}
def regiones_activas() -> list[str]:
# describe_regions devuelve solo las regiones habilitadas en la cuenta
ec2 = boto3.client("ec2", region_name="eu-south-2")
return [r["RegionName"] for r in ec2.describe_regions()["Regions"]]
def fuera_de_la_ue() -> list[str]:
hallazgos = []
for region in regiones_activas():
if region in PERMITIDAS:
continue
# Instancias y bases de datos de pruebas son lo que más se olvida encendido
ec2 = boto3.client("ec2", region_name=region)
for pagina in ec2.get_paginator("describe_instances").paginate():
for reserva in pagina["Reservations"]:
hallazgos += [f"EC2 {i['InstanceId']} en {region}" for i in reserva["Instances"]]
rds = boto3.client("rds", region_name=region)
for pagina in rds.get_paginator("describe_db_instances").paginate():
hallazgos += [f"RDS {db['DBInstanceIdentifier']} en {region}" for db in pagina["DBInstances"]]
# S3 lista los buckets de forma global; la región de cada uno se consulta aparte
s3 = boto3.client("s3")
for bucket in s3.list_buckets()["Buckets"]:
loc = s3.get_bucket_location(Bucket=bucket["Name"]).get("LocationConstraint") or "us-east-1"
loc = "eu-west-1" if loc == "EU" else loc # valor heredado de buckets antiguos
if loc not in PERMITIDAS:
hallazgos.append(f"S3 {bucket['Name']} en {loc}")
return hallazgos
if __name__ == "__main__":
for linea in fuera_de_la_ue():
print(linea)Programado tras el corte, el script avisa de cualquier recurso que alguien cree fuera de las regiones pactadas. Cada hallazgo es algo que tendrías que justificar ante tu delegado de protección de datos y, además, un recurso que se sigue facturando aunque nadie lo use.
Lo Que Cuesta Migrar a la Nube Sin Plan de Salida
El coste de una migración tiene dos partes: el proyecto, que depende de cuántas aplicaciones se refactorizan, y la factura mensual por uso, que depende de cómo quedan dimensionadas. Sin plan de salida pactado, cualquier cambio futuro de proveedor se negocia desde la dependencia.
En Codezone empezamos por el inventario de aplicaciones y ensayamos la vuelta atrás antes del corte. Cuéntanos qué servidores tienes hoy y te proponemos el orden de migración.
