En la vida hay momentos en los que te ves hablando con cierto recelo. Cuando eso ocurre, algunos piensan “parezco mi madre”. Yo ni confirmo ni desmiento que me haya pasado alguna vez. Otra situación que acabo de vivir es escucharme a mí misma decir que me encantan las estrategias de migración. 

Has leído bien. Me interesa genuinamente la manera en que una empresa migra un proceso empresarial de su infraestructura a Snowflake Data Cloud. ¿Por qué? Porque se trata de un reto complejo. Para Snowflake, esto implica trasladar una base de datos heredada, flujos de datos y una capa de consumo con herramientas de elaboración de informes y analíticas, así como los propios informes y paneles de control. Todo ello requiere tener muchos aspectos en cuenta, no solo la tecnología, sino también personas y procesos. Otro motivo que despertó mi interés por este tema fue la historia de uno de mis clientes favoritos (en el hipotético caso de que tuviera clientes favoritos).

Para cada perspectiva, un camino 

Durante años he creído que el traslado a una nueva arquitectura no debía ser como un “big bang”. Hace unos años, el Chief Data Officer (CDO) de una empresa de ropa para actividades al aire libre me contó que habían diseñado una nueva arquitectura de datos, pero que no la pondrían en marcha hasta terminar de alimentar el data lake. Pretendían hacer las cosas bien y no querían que la plataforma se usara hasta que estuviera lista. Ya hace varios años de eso. 

Otro CDO me explicó que habían adoptado un enfoque más básico y dividido en fases. En lugar de decir que la empresa estaba creando un marco común (y tener a todo el mundo a la espera), el equipo trabajó estrechamente con todas las unidades de negocio para ofrecer la información que se necesitaba, pero de forma que se ajustara a unas herramientas de visualización y una infraestructura de back‑end comunes. Con el tiempo, el equipo creó un nuevo “almacén de información empresarial” con capacidades de paneles de control comunes que compartían todas las marcas. Cuando se lanzó, fue una gran sorpresa para las partes interesadas de la empresa, pero no un “big bang” desde el punto de vista de la migración. No hubo que esperar durante años para obtener la información. Se generó valor durante todo el proceso mediante un enfoque incremental. Yo estaba totalmente convencida de que la incrementalidad era lo mejor… hasta hace poco.  

El mes pasado participé en el Snowflake Data Cloud World Tour que se celebró en Toronto. Fue un evento fantástico con presentaciones muy atractivas y conversaciones aún más estimulantes. Durante una pausa me acabé juntando con los responsables de datos de un minorista canadiense y una aseguradora, y la conversación derivó en las estrategias de migración. En efecto. 

Más tarde, hablé de la conversación que había tenido recientemente con otro cliente al que le estaba costando mucho migrar a la arquitectura de destino que quería y planificar su “big bang”. Me recordó a la empresa de ropa. Mis interlocutores asintieron. Sin embargo, cuando expuse la alternativa, el enfoque incremental, una mostró su desacuerdo. Según su experiencia, lo mejor era el enfoque “big bang”: la cuestión era hacerlo y rápido. En su caso, se aplicó la estrategia de migración lift-and-shift a nivel de mayorista. Sin rediseñar la arquitectura: simplemente se hizo el cambio a la nueva infraestructura. Así, su organización dejó atrás una plataforma heredada on-premise que no satisfacía plenamente sus necesidades en el momento y cuyo mantenimiento era caro. Puesto que la estrategia lift and shift fue de tipo “big bang”, no tuvieron que ejecutar dos sistemas de forma simultánea. Además, lo prioritario era deshacerse del antiguo sistema de una vez por todas. 

Con todo, la historia no acaba aquí. Aunque los informes y paneles de control existentes se habían traspasado a la nueva plataforma, no todos generaban valor. Ese es el reto que plantea el método lift and shift: acabas mudándote con cosas que no necesitas. 

¿Y cuál es la solución? Para mi interlocutora, había que desactivarlo todo. Así es. Se desactivaron los 80 000 informes y paneles de control que se habían migrado. Como imaginarás, se produjo cierto revuelo, pero no tanto como el que cabría esperar. No todos los informes tenían adeptos, pues solo 3000 de ellos se reactivaron. Bien está lo que bien acaba. Por fortuna, esta responsable de datos canadiense tiene nervios de acero.

Elegir la estrategia adecuada de migración a la nube

La conclusión es que las migraciones son un reto y que se deben valorar distintos enfoques. Hay que decidir sobre dos cuestiones: la estrategia de migración en sí y el enfoque de la transición. 

Este enfoque puede ser de tipo “big bang” o por fases.

  • “Big bang”: migración de la plataforma heredada a la nueva en una sola operación, en un momento determinado y con unos beneficios que se obtienen en el momento.
  • Por fases: migración de plataforma dividida en etapas gestionables y ejecutada a lo largo de un periodo, cuyos beneficios se acumulan a medida que se completa cada fase.

A continuación, las estrategias de migración reflejan lo que quieres mover y a qué destino. Si no quieres hacer cambios de inmediato, reúnes los datos existentes (lift) y los traspasas a la nueva plataforma (shift). Si prefieres aplicar cambios desde el principio, “arreglas” o rediseñas lo que sea necesario antes de moverlos. Puedes aplicar el enfoque de transición que más te convenga. Todos tienen sus pros y sus contras.

Esta imagen ilustra tres estrategias de migración habituales: 

En última instancia, no hay nada que sirva para todo. El enfoque adecuado depende de la organización, la plataforma existente y el deseo de cambio que tenga la empresa. El enfoque lift and shift de tipo “big bang” podría no parecer óptimo. Se migra todo de una vez, incluido lo que no sirve. No obstante, aquella conversación que tuve en Canadá me hizo ver que ese camino puede ser lo que necesitas. La clave es obtener valor lo más rápido posible, ya sea el incremental que ofrece una nueva plataforma mediante un enfoque por fases, o bien el que se obtiene al acabar de un plumazo con una carísima plataforma heredada. 

Iniciar la migración

Según el equipo de Snowflake Professional Services, independientemente de la estrategia que elijas, lo ideal es seguir unos pasos básicos:

  • Prueba: identifica un primer caso de uso de migración que proporcione valor empresarial y sirva para probar el traslado de la plataforma actual a Snowflake.
  • Definición del alcance: en función de las conclusiones extraídas de la prueba de concepto o de la migración piloto, identifica qué se incluirá y qué se excluirá del traslado de la plataforma actual a Snowflake.
  • Planificación: elabora un plan de migración que incluya los costes, los plazos, las tareas y los recursos necesarios para pasar de la plataforma actual a Snowflake.

Además, asegúrate de tener toda la información que necesites para tomar decisiones de migración. Responder al cuestionario de abajo, que se utiliza en la evaluación de la preparación para la migración de Snowflake, es un buen punto de partida.

Preguntas sobre la migración
¿Qué motiva la migración (por ejemplo, los costes de la plataforma heredada)?
¿Es necesario cumplir plazos específicos?
¿Qué sistema o sistemas heredados se migrarán a Snowflake?
¿Qué enfoque de migración se prefiere (lift and shift; lift, fix and shift; o rediseño total)?
¿Qué estrategia se ha planteado para la transición (de tipo “big bang” o por fases)?
¿Quién se encargará de las labores de migración (personal interno, un partner, Snowflake o enfoque combinado)?
¿Tienes alguna preferencia en cuanto al integrador de sistemas con el que trabajar?
¿Qué fuentes de datos se usan para alimentar el sistema heredado?
¿Qué herramientas se usan actualmente en la ingesta de datos?
¿Qué herramientas se usan actualmente en la elaboración de informes y analíticas?
¿Cuántos usuarios o unidades de negocio diferentes acceden al sistema heredado?

Si quieres obtener más información sobre la manera en que Snowflake puede ayudar con las migraciones y mucho más, consulta Snowflake Professional Services y de educación y formación de Snowflake