Infraestructura cloud

1. 1

   Diagnóstico de coste e infraestructura actual

   3-5 días

   Acceso de solo lectura a la cuenta cloud (AWS, Azure o GCP) para mapear cada recurso, su coste real y su nivel de utilización. Se identifican instancias sobredimensionadas, recursos huérfanos, almacenamiento que puede bajarse de tier y descuentos por compromiso no aprovechados.

2. 2

   Diseño de la arquitectura objetivo

   1-2 semanas

   Diagrama de la arquitectura nueva: dimensionamiento correcto según uso real, zonas de disponibilidad, red, permisos, backups y recuperación. Se compara con el estado actual y se calcula el coste proyectado mes a mes.

3. 3

   Plan de migración por fases

   1 semana

   Cronograma detallado con hitos, dependencias entre sistemas, ventanas de mantenimiento y plan de rollback en cada fase. Los sistemas se migran de menos a más crítico para ir validando antes de tocar producción.

4. 4

   Preparación de entorno de pruebas

   1-2 semanas

   Réplica del entorno actual en una arquitectura nueva aislada. Permite probar la migración con datos reales (anonimizados si es necesario) sin tocar producción hasta que todo funciona.

5. 5

   Migración controlada

   1-4 fines de semana

   Ventanas de mantenimiento planificadas. Cada fase se valida antes de pasar a la siguiente. El rollback está siempre disponible si algo no funciona.

6. 6

   Optimización post-migración

   2-3 semanas

   Una vez todo en cloud nuevo, se activan descuentos por compromiso (savings plans, reserved instances), se ajusta dimensionamiento final en caliente y se montan alertas de coste para evitar desvíos futuros.

7. 7

   Documentación y traspaso

   1 semana

   Runbook de operación, diagrama actualizado, procedimientos de incidencia y guía de mantenimiento. El equipo o el proveedor habitual recibe formación para operar la infraestructura nueva.

Preferimos decirlo antes: si reconoces alguna de estas situaciones, probablemente no es el momento o no es el servicio adecuado. Queda mejor ahorrar el tiempo de ambos.

• Tu infraestructura son 1-2 servidores virtuales y nunca has tenido problemas de rendimiento ni de coste. Migrar aporta poco y complica la operación.
• Ya migraste a cloud en los últimos 6 meses con un proveedor serio. Conviene esperar al menos un año antes de revisar.
• Tienes un contrato on-premise con un vendor (Oracle, SAP, otros) con penalización por salida alta. La migración puede no compensar hasta que venza.
• Necesitas certificaciones o requisitos regulatorios muy específicos (sector sanitario, financiero, defensa) que limitan el proveedor cloud. Ahí el proyecto es otro.
• Buscas un "cambio de hosting" sin replantear arquitectura. Eso lo hace mejor tu hosting actual; lo nuestro es diseñar bien, no mover cajas.
• Tu equipo técnico interno ya está trabajando en la migración y quieres subcontratar manos que ejecuten. No ejecutamos; diseñamos y supervisamos. Si necesitas ejecución, te conectamos con un partner.

¿Qué pasa si algo sale mal durante la migración?

El plan contempla rollback en cada fase: si algún sistema no funciona correctamente en la arquitectura nueva tras la migración, se vuelve al estado anterior con una ventana máxima de 30-60 minutos. Por eso se hacen por fases y con pruebas previas en un entorno aislado, nunca todo de golpe.

¿Recomendáis siempre AWS o hacéis multi-cloud?

Ni lo uno ni lo otro por defecto. Elegimos el proveedor según el caso concreto: ecosistema actual, perfil del equipo, certificaciones requeridas y coste proyectado. Multi-cloud añade complejidad y solo tiene sentido cuando hay justificación técnica real (no solo "por si acaso").

¿Y si después de migrar quiero cambiar de proveedor?

Diseñamos la arquitectura con la menor dependencia del proveedor posible: bases de datos estándar, servicios replicables y documentación completa. Cambiar de proveedor nunca es trivial, pero con un diseño razonable es viable en 2-3 meses si algún día hace falta.

¿Quién mantiene la infraestructura después de la migración?

Depende de lo que encaje con tu empresa. Puede quedar en manos de tu equipo técnico interno con la documentación que entregamos, puede hacerlo un partner especializado al que te conectamos, o puedes contratar nuestra asesoría técnica mensual si prefieres continuidad con quien lo diseñó.

¿El ahorro del 20-40 % se mantiene a largo plazo?

Sí, si hay mantenimiento. Sin revisión periódica, los entornos cloud tienden a descontrolarse otra vez: nuevos proyectos que dejan recursos huérfanos, backups que crecen, equipos que desactivan mal lo que ya no usan. Una revisión semestral de 1-2 días mantiene el ahorro estable.

¿Qué certificaciones cubre la arquitectura que diseñáis?

Por defecto, configuración compatible con RGPD e ISO 27001 en aspectos técnicos (cifrado, accesos, logs, backups). Certificaciones específicas de sector (PCI DSS, HIPAA, ENS) requieren alcance adicional y se cotizan aparte porque implican auditoría formal, no solo diseño.

• Cómo reducir la factura de cloud de tu empresa entre un 20% y un 40%

  Las 5 causas más comunes de sobrecoste en cloud y cómo eliminarlas. Guía práctica para PYMEs que pagan de más por su infraestructura.

  Infraestructura·6 min

• Cuánto cuesta migrar a la nube: guía de precios para PYMEs

  Precios reales de migración cloud para PYMEs: qué factores determinan el coste, cuánto se puede ahorrar y qué incluye un proyecto de migración bien hecho.

  Infraestructura·6 min

• Los 7 errores tecnológicos más comunes en PYMEs (y cómo evitarlos)

  Comprar software sin necesitarlo, no tener backups, depender de una sola persona... Los 7 errores tecnológicos que vemos repetirse en PYMEs y cómo corregirlos.

  Auditoría·7 min