Migrar a Google Cloud: prácticas recomendadas para validar un plan de migración

Last reviewed 2025-05-05 UTC

En este documento se describen las prácticas recomendadas para validar el plan de migración de tus cargas de trabajo a Google Cloud. En este documento no se enumeran todas las prácticas recomendadas posibles para validar un plan de migración, ni se garantiza el éxito. En su lugar, te ayuda a fomentar conversaciones sobre posibles cambios y mejoras en tu plan de migración.

Este documento es útil si tienes previsto migrar desde un entorno local, desde un entorno de alojamiento privado o desde otro proveedor de servicios en la nube a Google Cloud. El documento también es útil si estás evaluando la oportunidad de migrar y quieres saber cómo sería el proceso.

Este documento forma parte de la siguiente serie de artículos sobre la migración aGoogle Cloud:

Evaluación

Realizar una evaluación completa de tus cargas de trabajo y entornos te ayuda a conocerlos en profundidad. Desarrollar este conocimiento te ayudará a minimizar los riesgos de que se produzcan problemas durante y después de la migración a Google Cloud.

Hacer una evaluación completa

Antes de continuar con los pasos posteriores a la fase de evaluación, completa la evaluación de tus cargas de trabajo y entornos. Para hacer una evaluación completa, ten en cuenta los siguientes elementos, que a menudo se pasan por alto:

  • Inventario: asegúrate de que el inventario de las cargas de trabajo que vas a migrar esté actualizado y de que hayas completado la evaluación. Por ejemplo, ten en cuenta la actualidad y la fiabilidad de los datos de origen de tu evaluación, así como las posibles lagunas que puedan existir en los datos.

  • Tiempos de inactividad: identifica las cargas de trabajo que pueden gestionar los tiempos de inactividad. Determina cuándo pueden producirse estos periodos de inactividad y cuánto pueden durar para minimizar las interrupciones, por ejemplo, por la noche o los fines de semana. Migrar cargas de trabajo con un tiempo de inactividad nulo o casi nulo es más difícil que migrar cargas de trabajo que pueden permitirse tiempos de inactividad. Para completar una migración sin tiempo de inactividad, debes diseñar e implementar la redundancia de cada carga de trabajo que quieras migrar. También debes coordinar estas instancias redundantes.

    Cuando evalúes cuánto tiempo de inactividad puede tolerar una carga de trabajo, determina si la ventaja empresarial de una migración sin tiempo de inactividad es mayor que la complejidad adicional de la migración. Si es posible, evita crear un requisito de tiempo de inactividad cero para una carga de trabajo.

  • Clústeres y redundancia: evalúa qué cargas de trabajo admiten clústeres y redundancia. Si una carga de trabajo admite la creación de clústeres y la redundancia, puedes desplegar varias instancias de esa carga de trabajo, incluso en diferentes entornos, como el entorno de origen y el de destino. Las implementaciones en clúster y redundantes pueden simplificar la migración, ya que esas cargas de trabajo se coordinan entre sí con una intervención limitada.

  • Actualizaciones de configuración: evalúa cómo actualizas la configuración de tus cargas de trabajo. Por ejemplo, piensa en cómo vas a enviar las actualizaciones de la configuración de cada carga de trabajo que quieras migrar. Esta consideración es fundamental para que la migración se realice correctamente, ya que es posible que tengas que actualizar la configuración de tus cargas de trabajo mientras las migras al entorno de destino.

  • Generar varios informes de evaluación: durante la fase de evaluación, puede ser útil generar más de un informe de evaluación para tener en cuenta diferentes situaciones. Por ejemplo, puede generar informes para tener en cuenta diferentes perfiles de carga de sus cargas de trabajo, como las horas punta y valle.

Evaluar los modos de fallo que admiten tus cargas de trabajo

Saber cómo se comportan tus cargas de trabajo en circunstancias excepcionales te ayuda a asegurarte de que no las expones a condiciones de las que no puedan recuperarse. Como parte de la evaluación, recopila información sobre los modos de fallo y sus efectos que admiten tus cargas de trabajo y de los que pueden recuperarse automáticamente, así como sobre los modos de fallo que requieren tu intervención. Por ejemplo, puedes empezar planteándote preguntas sobre los posibles modos de fallo, como las siguientes:

  • ¿Qué ocurre si una carga de trabajo pierde la conectividad con la red?
  • ¿Puede una carga de trabajo reanudar su trabajo desde el punto en el que lo dejó después de haberse detenido?
  • ¿Qué ocurre si el rendimiento de una carga de trabajo o de sus dependencias no es adecuado?
  • ¿Qué ocurre si hay dos cargas de trabajo que tienen el mismo identificador en la arquitectura?
  • ¿Qué ocurre si una tarea programada no se ejecuta?
  • ¿Qué ocurre si dos cargas de trabajo procesan el mismo mensaje?

Otra fuente de modos de fallo no admitidos puede ser el propio plan de migración. Determina si tu plan de migración incluye pasos que dependen de que se cumpla una condición concreta y si incluye medidas alternativas en caso de que no se cumpla. Un plan que incluya este tipo de condiciones puede indicar que el plan en sí podría fallar o que los componentes individuales podrían fallar durante la migración.

Después de evaluar esos modos de fallo y sus efectos, valida tus conclusiones en un entorno no crítico simulando fallos e inyectando errores que emulen esos modos de fallo. Por ejemplo, si una carga de trabajo está diseñada para recuperarse automáticamente después de una pérdida de conectividad de red, valida la recuperación automática interrumpiendo la conectividad de forma forzada y, a continuación, restaurándola.

Evalúa tus flujos de procesamiento de datos

La evaluación de la carga de trabajo debe responder a las siguientes preguntas:

  • ¿Los recursos tienen el tamaño adecuado para la migración?
  • ¿Cuánto tiempo se necesita para migrar los datos que necesitan tus cargas de trabajo?
  • ¿Puede el entorno de destino admitir el volumen completo de datos?
  • ¿Cómo se comportan tus cargas de trabajo cuando tienen que adaptarse a picos de demanda o de cantidad de datos que producen en un periodo determinado?
  • Si hay picos de demanda o picos en la cantidad de datos que generan tus cargas de trabajo, ¿se produce algún efecto adverso, como un aumento de la latencia o retrasos en las respuestas?
  • Una vez que se inician las cargas de trabajo, ¿necesitan tiempo para alcanzar los niveles de rendimiento esperados?

Los resultados de esta evaluación suelen ser modelos de la demanda que satisfacen tus cargas de trabajo y los datos que producen en un periodo determinado. Cuando recoja puntos de datos para crear estos modelos, tenga en cuenta que pueden variar significativamente entre los periodos de máxima actividad y los de menor actividad. Para obtener más información sobre cómo y qué monitorizar, consulta Objetivos de nivel de servicio en el libro Site Reliability Engineering.

Asegúrate de que puedes actualizar y desplegar cada carga de trabajo que quieras migrar

Durante la migración, es posible que tengas que actualizar algunas de las cargas de trabajo que estés migrando. Por ejemplo, puede que tengas que implementar una corrección para un problema o revertir un cambio reciente que esté causando un problema. En cada carga de trabajo que migres, asegúrate de que puedes aplicar e implementar los cambios. Por ejemplo, si vas a migrar una carga de trabajo de la que tienes el código fuente, asegúrate de que puedes acceder a ese código fuente y de que puedes compilarlo, empaquetarlo y desplegarlo según sea necesario.

Es posible que tu migración incluya cargas de trabajo a las que no puedas aplicar ni implementar cambios, como software preexistente y listo para usar. En ese caso, refactoriza tu plan de migración para tener en cuenta el esfuerzo adicional que tendrás que hacer para mitigar los problemas que puedan surgir después de migrar esas cargas de trabajo.

Evaluar la infraestructura de red

Una infraestructura de red funcional es fundamental para la migración. Puedes usar la infraestructura de red como parte de tus herramientas de migración. Por ejemplo, puedes usar balanceadores de carga y servidores DNS para dirigir el tráfico según tu plan de migración.

Para evitar problemas durante la migración, es importante que evalúes tu infraestructura de red y determines en qué medida puede admitir la migración. Por ejemplo, puedes empezar planteándote preguntas sobre tu infraestructura de balanceo de carga, como las siguientes:

  • ¿Qué ocurre cuando vuelves a configurar los balanceadores de carga?
  • ¿Cuánto tiempo tarda en aplicarse la configuración actualizada?
  • Al migrar sin tiempo de inactividad, ¿qué ocurre si se produce un pico de tráfico antes de que se aplique la configuración actualizada?

Después de plantearte preguntas sobre tu infraestructura de balanceo de carga, hazte preguntas sobre tu infraestructura de DNS, como las siguientes:

  • ¿Qué registros DNS debes actualizar para que apunten al entorno de destino y cuándo debes actualizarlos?
  • ¿Qué clientes usan esos registros DNS?
  • ¿Cómo se configura el tiempo de vida (TTL) de los registros DNS que quieres actualizar?
  • ¿Puedes definir el TTL del registro DNS en su valor mínimo en segundos antes de realizar la migración?
  • ¿Respetan tus clientes e intermediarios de DNS el TTL de los registros DNS que quieres actualizar? Por ejemplo, ¿sus aplicaciones tienen una caché de DNS del lado del cliente que ignora el TTL que ha configurado para la migración? Recuerda que la resolución de DNS implica varias capas de almacenamiento en caché. Te recomendamos que uses Google Public DNS para evitar problemas con el DNS del proveedor de Internet.
  • ¿Respetan tus clientes DNS el TTL de los registros DNS que se van a actualizar? Por ejemplo, ¿tus aplicaciones tienen una caché de DNS del lado del cliente que ignora el TTL que has configurado para la migración?
  • ¿Detecta tráfico dirigido a su entorno de origen incluso después de haber completado la migración?

Crear una prueba de concepto

Una prueba de concepto es una implementación pequeña y preliminar de un proyecto de migración planificado. Valida la viabilidad, la funcionalidad y las posibles ventajas de ese proyecto antes de comprometerte a llevar a cabo una implementación completa. Una prueba de concepto te ayuda a determinar si las cargas de trabajo de migración funcionan correctamente en el entorno de destino.

Empieza definiendo el alcance y los criterios de éxito específicos de la prueba de concepto. Entre los criterios de éxito se pueden incluir métricas como la compatibilidad con la carga de trabajo de destino completa, el tiempo de inactividad mínimo durante la migración y las demandas de rendimiento específicas.

Una vez que hayas identificado los criterios de éxito, prueba y valida tu prueba de concepto. En la documentación del plan de migración, anota tus conclusiones, los problemas que hayas encontrado y las posibles soluciones a esos problemas.

Crea una prueba de concepto cuando quieras investigar los siguientes aspectos de interés:

  • Valide la viabilidad de la migración: compruebe que sus aplicaciones, cargas de trabajo y datos funcionan correctamente en Google Cloud.
  • Estima el tiempo de inactividad y planifica la restauración: mide el tiempo de inactividad necesario para migrar tus cargas de trabajo y transferir datos. Valida tus escenarios de reversión.
  • Perfecciona el plan de migración: ten en cuenta lo siguiente para perfeccionar tu plan antes de llevar a cabo una migración a gran escala:
    • Identifica el mejor enfoque de migración.
    • Identifica tus necesidades de modernización o refactorización de cargas de trabajo.
    • Identifica los posibles riesgos o problemas de tu migración.
    • Prueba la migración.
  • Valida la seguridad y el cumplimiento: asegúrate de que las políticas de seguridad, los roles de gestión de identidades y accesos (IAM) y los requisitos de cumplimiento de tu migración se ajusten a las necesidades de tu organización.
  • Generar confianza y aceptación por parte de las partes interesadas: ayuda a garantizar la satisfacción de las partes interesadas. Una prueba de concepto satisfactoria genera confianza en el plan de migración entre las partes interesadas, ya que demuestra las ventajas tangibles para los equipos directivo y técnico.
  • Estima los costes y las posibilidades de optimización: calcula los costes asociados a la migración. Explora las posibilidades de optimización, como probar diferentes tamaños de entorno de destino y herramientas de migración.

Iterar en varias pruebas de concepto. Ajusta las cargas de trabajo de destino y el plan de migración hasta que crees una prueba de concepto que cumpla tus criterios de éxito.

Planificación de la migración

Planificar la migración a fondo te ayudará a evitar problemas durante y después de la migración. La planificación también te ayuda a evitar el esfuerzo de hacer tareas imprevistas.

Desarrollar una estrategia de restauración para cada paso del plan de migración

Durante la migración, cualquier paso del plan de migración que ejecutes puede provocar problemas imprevistos. Para asegurarte de que puedes recuperarte de esos problemas, prepara una estrategia de reversión para cada paso del plan de migración. Para evitar perder tiempo durante una interrupción, haz lo siguiente:

  • Para asegurarte de que tus estrategias de restauración funcionan, revisa y prueba periódicamente cada una de ellas.
  • Define un tiempo de ejecución máximo permitido para cada paso de la migración. Cuando finalice este tiempo de ejecución permitido, tus equipos empezarán a deshacer el paso de migración.

Aunque tengas estrategias de reversión preparadas para cada paso del plan de migración, algunos de esos pasos pueden ser potencialmente perjudiciales. Un paso que pueda causar interrupciones puede provocar algún tipo de pérdida, aunque lo deshagas, como una pérdida de datos. Evalúa qué pasos del plan de migración pueden causar interrupciones.

Si has automatizado algún paso del plan de migración, asegúrate de tener un procedimiento predefinido para cada paso automatizado en caso de que se produzca un error en la automatización. Al igual que con las estrategias de restauración, revisa y prueba periódicamente cada procedimiento predefinido.

Si configuras canales de comunicación como parte de la migración, para asegurarte de que no se te bloquee el acceso a tu entorno, proporciona canales de copia de seguridad que puedas usar para recuperarte en caso de fallo. Por ejemplo, si estás configurando Partner Interconnect, durante la migración también puedes configurar un acceso de copia de seguridad a través de Internet público por si tienes algún problema durante el aprovisionamiento y la configuración.

Planificar la modernización y la adaptación de las cargas de trabajo

Cuando planifiques la migración a Google Cloud, ten en cuenta que migrar e integrar tus cargas de trabajo lleva tiempo y puede plantear dificultades. Te recomendamos que crees un documento de resumen que describa la arquitectura general de tus cargas de trabajo, incluida información sobre los siguientes temas:

  • Dependencias de sistemas externos y de middleware de terceros, como almacenamiento, mensajería y alojamiento.
  • Mecanismos para autenticar y autorizar cargas de trabajo.
  • Procesos para integrarse con la gestión de identidades y accesos.
  • Requisitos del entorno de ejecución.
  • Interacciones con opciones de la capa de almacenamiento, como Cloud Storage y Google Cloud bases de datos.
  • Requisitos de volumen de transferencia de datos y ancho de banda.
  • Cambios en el código de la aplicación que puedes hacer durante la migración.
  • Opciones para integrar con Google Cloud Observability.

Puede que tengas que modernizar tus cargas de trabajo, por ejemplo, integrando bibliotecas deGoogle Cloud para la autenticación, la autorización, el almacenamiento y la observabilidad. Modernizar bibliotecas antiguas puede requerir un esfuerzo. Planifica el tiempo suficiente para probar a fondo tus cargas de trabajo.

Planificar lanzamientos y despliegues graduales

Para reducir el alcance de los problemas que puedan surgir durante la migración, evita los cambios a gran escala y diseña tu plan de migración para implementar los cambios de forma gradual. Por ejemplo, planifica implementaciones graduales y cambios de configuración.

Si tienes previsto hacer lanzamientos graduales para reducir el riesgo de que se produzcan problemas imprevistos debido a la aplicación de los cambios, minimiza el número y el tamaño de esos cambios. Una vez que haya identificado y resuelto los problemas en su primera versión, podrá hacer las siguientes versiones de cambios similares a mayor escala.

Alertar a los equipos de desarrollo y operaciones

Para reducir el impacto de los problemas que puedan surgir durante una migración, avisa a los equipos responsables de las cargas de trabajo que se van a migrar. También debes alertar a los equipos responsables de la infraestructura de los entornos de origen y de destino.

Si tus equipos trabajan en zonas horarias diferentes y utilizas el modelo operativo follow-the-sun, asegúrate de que se cumplan los siguientes requisitos:

  • Sus equipos cubren correctamente esas zonas horarias y varios turnos consecutivos, ya que es posible que no puedan resolver los problemas durante un solo turno.
  • Tus equipos están preparados para recoger información detallada sobre los problemas a los que se enfrenten. Esta colección proporciona a los ingenieros del siguiente turno una comprensión completa de lo que hizo el turno anterior y por qué.
  • Personas concretas de tus equipos son responsables de cada turno.

Eliminar los recursos de prueba de concepto del entorno de producción de destino

Como parte de la evaluación, es posible que hayas usado el entorno de destino para alojar experimentos y pruebas de concepto. Antes de la migración, elimina los recursos que hayas creado durante esos experimentos y pruebas de concepto del área de producción del entorno de destino.

Puedes mantener los recursos en un área de no producción del entorno de destino mientras se lleva a cabo la migración, ya que pueden ayudarte a recopilar información sobre cualquier problema que pueda surgir durante la migración. Por ejemplo, para diagnosticar problemas que afecten a tus cargas de trabajo de producción después de la migración, puedes comparar los registros de configuración y de datos de la carga de trabajo de producción con los registros de configuración y de datos de las pruebas de concepto y los experimentos.

Una vez que hayas completado la migración y hayas validado que el entorno de destino funciona correctamente, puedes eliminar los recursos del área de no producción del entorno de destino.

Definir criterios para retirar de forma segura el entorno de origen

Para evitar el coste de ejecutar dos entornos indefinidamente, define las condiciones que deben cumplirse para poder retirar el entorno de origen de forma segura. Por ejemplo:

  • Todas las cargas de trabajo, incluidas sus copias de seguridad y sus mecanismos de alta disponibilidad y recuperación ante desastres, se migran correctamente al entorno de destino.
  • Los datos migrados al entorno de destino son coherentes, accesibles y utilizables.
  • La precisión y la integridad de los datos migrados cumplen el estándar definido.
  • Los recursos que permanecen en el entorno de origen no son dependencias de las cargas de trabajo que están fuera del ámbito de la migración.
  • El rendimiento de tus cargas de trabajo en el entorno de destino cumple los objetivos de tu SLA.
  • Sus sistemas de monitorización indican que no hay tráfico de red hacia el entorno de origen que deba dirigirse al entorno de destino.
  • Una vez que las cargas de trabajo se hayan ejecutado sin problemas en el entorno de destino durante un periodo que definas, podrás estar seguro de que ya no necesitas la opción de volver al entorno de origen.

Planificar la actualización de todos los documentos y paneles

Una vez que hayas completado la migración, actualiza de forma exhaustiva los manuales de operaciones de producción, los documentos de asistencia y los paneles de control de monitorización. Los cambios que debes hacer en tu documentación pueden incluir los siguientes elementos:

  • Diagramas de arquitectura: actualiza los diagramas de arquitectura para que reflejen la arquitectura de Google Cloud , sobre todo si modernizas y refactorizas tus cargas de trabajo.
  • Conexión y autenticación: actualiza la documentación sobre los métodos de autenticación, como la gestión de identidades y accesos, y las configuraciones de red para reflejar la arquitectura de Google Cloud .
  • Seguridad: actualiza la documentación en la que se describen las Google Cloud funciones de seguridad, como el cifrado en reposo y en tránsito, y los controles de acceso basados en gestión de identidades y accesos.
  • Mantenimiento y escalado: actualiza los manuales de operaciones de producción en las ventanas de mantenimiento de los servicios gestionados, los procedimientos de escalado vertical y horizontal, y las prácticas recomendadas para optimizar el rendimiento.
  • Alta disponibilidad y conmutación por error: actualiza la documentación sobre las configuraciones de alta disponibilidad, las consideraciones sobre la sincronización regional y zonal, y los mecanismos de conmutación por error.
  • Copia de seguridad y recuperación: actualiza tus procesos de copia de seguridad y recuperación para que se ajusten a los procesos que admiten Google Cloud y el servicio de copia de seguridad y recuperación tras fallos. Estos procesos incluyen copias de seguridad automáticas, posibilidades de recuperación a un momento dado y procedimientos de exportación e importación.
  • Recuperación tras fallos: actualiza tu plan y tus procedimientos de recuperación tras fallos para que se ajusten a las funciones de recuperación tras fallos de Google Cloud . Después, prueba los procedimientos actualizados.
  • Monitorización y registro: integra Google Cloud Observability en tus paneles de monitorización y sistemas de alertas. Actualice la documentación de Cloud Quotas y especifique cómo interpretar los registros, las métricas y las alertas.

Operaciones

Para gestionar de forma eficiente el entorno de origen y el de destino durante la migración, también debes diseñar tus procesos operativos.

Monitorizar entornos

Para observar el comportamiento de los entornos de origen y de destino, y para ayudarte a diagnosticar los problemas a medida que se produzcan, configura lo siguiente:

  • Un sistema de monitorización para recoger métricas que sean útiles en tu caso.
  • Un sistema de registro para observar el flujo de operaciones que realizan tus cargas de trabajo y otros componentes de tus entornos.
  • Un sistema de alertas que te avisa antes de que se produzca un evento problemático.

Google Cloud Observability admite la monitorización, el registro y las alertas integrados de tuGoogle Cloud entorno.

Como una carga de trabajo y sus dependencias abarcan varios entornos, es posible que tengas que usar varias herramientas de monitorización y alertas para diferentes entornos. Ten en cuenta el momento en el que migras las políticas de monitorización y alertas que admiten las cargas de trabajo. Por ejemplo, si tu entorno de origen está configurado para enviar una alerta cuando un servidor concreto deje de funcionar, la alerta se activará cuando apagues ese servidor intencionadamente. Se espera que se active la alerta, pero no es útil. Como parte de la migración, debes ajustar continuamente las alertas del entorno de origen y volver a configurarlas en el entorno de destino.

Gestionar la migración

Para gestionar la migración, revisa su rendimiento para recopilar información que puedas usar como retrospectiva una vez que se haya completado. Una vez que haya recopilado la información, úsela para analizar el rendimiento de la migración y preparar puntos de datos sobre las posibles mejoras de sus entornos.

Por ejemplo, para empezar a planificar la gestión de la migración, plantéate las siguientes preguntas:

  • ¿Cuánto tiempo ha llevado cada paso del plan de migración?
  • ¿Alguna de las fases del plan de migración ha llevado más tiempo del previsto?
  • ¿Faltaba algún paso o comprobación?
  • ¿Se ha producido algún evento adverso durante la migración?

Siguientes pasos

Colaboradores

Autor: Marco Ferrari | Arquitecto de soluciones en la nube

Otro colaborador: Alex Cârciu | Arquitecto de soluciones