Migración de datos: ¿peligrosa o esencial?

El departamento de desarrollo de software de mi empresa enfrenta el problema de que las migraciones de datos se consideran potencialmente peligrosas, especialmente para mis gerentes.

El trasfondo es que nuestros clientes están utilizando una gran cantidad de datos con baja calidad . Las razones para esto solo están parcialmente relacionadas con la calidad de nuestro software , sino más bien con el historial de los datos: la mayoría de ellos se han migrado de sistemas predecesores , algunos errores causaron inconsistencias (principalmente comerciales) en los registros de datos o entradas incorrectas por accidente en el lado del cliente (que nuestro software permitió por error).

Los contraargumentos más importantes de mis gerentes son que los datos defectuosos pueden convertirse en datos aún peores , los problemas de datos pueden despertar a algunos gerentes del cliente y algunos procesos del lado del cliente pueden no funcionar porque sus procesos se adaptaron de alguna manera a nuestro sistema.

Personalmente, considero que las migraciones de datos son una parte integral del desarrollo de software y que la migración de datos se puede ver en los datos, lo que la refactorización es codificar. Creo que la migración de datos es esencial para crear software que evolucione . Sin él, tendríamos que crear un software doloroso que de alguna manera funciona alrededor de una estructura de datos incorrecta.

Te estoy preguntando:

• ¿Qué piensa sobre la migración de datos, especialmente para los casos de la vida real y no solo desde la perspectiva de un desarrollador?
• ¿Tienes algún argumento contra las opiniones de mis gerentes?
• ¿Cómo maneja su empresa las migraciones de datos y las dificultades causadas por ellas?
• ¿Alguna otra idea interesante que pertenezca a estos temas?

Las migraciones de datos son mi pan de cada día y la limpieza de datos es de hecho una cuestión de gran importancia. Una estrategia que utilizamos para migrar el 100% de los datos de nuestros clientes son las herramientas de migración previa de limpieza de datos asintóticas.

1. Esto significa desarrollar decenas de comprobaciones de integridad de datos (principalmente consultas sql).

2. Intercambiando herramientas de limpieza con el cliente (dado que son sus datos, diseñamos las utilidades de parcheo, él las valida y las ejecuta).

3. Refinando la herramienta a través de iteraciones y alcanzando una calidad medible respaldada por KPI lo antes posible.

4. Comprobación de la coherencia de los datos después de que se haya producido la migración. Esto ayuda a tomar una decisión GO / NOGO el día D.

Al final, la migración de datos es un ejercicio inmensamente beneficioso que tiene que suceder después de 3 a 5 años.

1. Permite aumentar la capacidad de la plataforma para apoyar los negocios.

2. Permite racionalizar la base de datos.

3. Prepara la plataforma de TI para las herramientas empresariales de próxima generación (ESB / EAI, Portales, plataformas de autocuidado, informes y minería de datos, lo que sea).

4. Reorganiza los flujos de datos de bricolaje entre plataformas que se han acumulado a lo largo de los años de una manera "temporal" rápida y sucia para cumplir con los "requisitos urgentes".

5. Sobre todo, empodera al equipo de producción de TI que conoce mejor su plataforma y fomenta actitudes de "poder hacer". Este tipo de beneficios son difíciles de medir, pero cuando conoce a muchos clientes, esta consideración se vuelve obvia. Las empresas que evitan las migraciones permanecen en el siguiente nivel, las audaces lideran el grupo.

Es un poco como cuando el sótano de tu casa se llena de madera. Una mañana, tienes que sacar todo y guardar solo las cosas que necesitas y tirar el resto. Después de eso, puedes usar tu sótano nuevamente ;-)

Otra consideración fundamental es que hoy en día, las expectativas de los clientes siempre están en movimiento, como en "los clientes siempre son más exigentes". De modo que siempre habrá una proporción significativa de competidores de una determinada empresa en busca de estas nuevas tendencias con la intención obvia de aumentar su participación en el mercado. La forma en que lo harán es adaptando su oferta para seguir la tendencia o incluso impulsar las tendencias, y eso implica una constante reingeniería de negocios. Si su plataforma de TI es demasiado rígida, será un lastre para su propia capacidad de cónyuge o preceder a las tendencias del mercado por su parte y, en última instancia, para mantener su propia cuota de mercado. En otras palabras, en un mercado en movimiento, la inercia es una receta para la irrelevancia.

Por el contrario, una migración de datos a un sistema más nuevo desplegará una herramienta de productividad más moderna y versátil, haciendo que lo mejor de las tecnologías más nuevas, más atractivas para los empleados y esto, a su vez, contribuirá a apoyar o incluso liderar el proceso de innovación interna de la compañía. , asegurando o aumentando así su cuota de mercado relativa.

Las consideraciones anteriores en realidad responden solo a la mitad de la pregunta formulada en el título "Migración de datos: peligrosa o esencial". Sí, las migraciones de datos son esenciales, pero ¿ también son peligrosas? En esta cuenta, muchas cosas en TI son peligrosas entonces. Por definición, todo lo que está en juego es peligroso; especialmente si no te tomas el asunto en serio. Pero este es en realidad el patrón más común en TI. No tomar en serio los centros de datos o la alta disponibilidad o la tolerancia a desastres es peligroso.
¿Significa eso que las empresas de hoy deberían optar por no participar en estos pilares del panorama actual de la tecnología de la información? Seguramente no !

Para decirlo en broma, podría argumentar que "Volar es peligroso si no utiliza un avión hecho por profesionales". Es lo mismo para las migraciones de datos. Cuando es ejecutado y dirigido por profesionales, no es más peligroso que volar en un avión bien diseñado y bien operado. Y el ROI está en la misma proporción en comparación con los medios de transporte terrestres.
Cuando se confía a profesionales, la mayoría de las migraciones son éxitos bien controlados y la tasa de fracaso + abandono es extremadamente baja.

Debería inducir a sus gerentes a preguntarse: "Si bien la mayoría de las empresas realizan con éxito los proyectos de migración de datos, ¿qué haría a nuestra empresa tan diferente que, en cambio, experimentaría un fracaso? ¿Y podría funcionar bien sin uno?"

Alain dio una gran respuesta en términos de importancia de la limpieza de datos para un proyecto exitoso de migración de datos y la justificación de la migración de datos. Me gustaría apuntar solo a preocupaciones específicas que tenga su gerente.

En mi opinión, no se trata de hacer o no la migración de datos, se trata de cuándo hacerlo. Su gerente tiene un punto absolutamente válido al decir que sus datos ya no son solo suyos y que los clientes finales ya han desarrollado sus procedimientos en torno a ellos. Sin embargo, este estado no cambiará en el futuro . Tarde o temprano, la mala calidad de los datos se convertirá en un factor inevitable para desacelerar su negocio y se verá obligado a realizar la migración. Hacer esto bajo presión y con plazos ajustados podría llevar a decisiones subóptimas. Además, piense en la experiencia que tiene ahora y que tendrá en 2-3 años a partir de ahora. ¿Qué pasa si las personas que entienden sus datos se irán de la compañía? ¿Estás seguro de que la documentación que tienes es adecuada?

Tal vez no sea necesario hacer la migración ahora, pero su gerente al menos necesita tener una visión de cuándo se realizará exactamente la migración.

Estaba trabajando para una compañía de seguros e involucrado en la migración de datos para el sistema central. Bueno, hubo en total 4 veces. Entonces, aquí mis comentarios:

En mi caso, la migración de datos es imprescindible, ya que por regulación debemos conservar los datos durante al menos 10 años, y no podemos permitirnos el soporte del sistema dual a largo plazo. La otra razón es que los usuarios esperan que puedan continuar su trabajo con la nueva aplicación. Si no pueden encontrar el elemento en el que trabajan, su aplicación es incorrecta y es aún peor cuando los datos no son correctos.

Bueno, la migración de datos es una bestia horrible y es real, así que acéptelo. Es arriesgado, pero se puede minimizar al abordarlo antes y con cuidado. Como guía, hay cuatro grandes procesos que deben tenerse en cuenta en la migración de datos:

1. Mapeo de datos. Mapas del maestro (y su combinación) al nuevo sistema
2. Limpieza de datos. Mapas de excepción en los datos, es decir, datos cuya combinación se considera inválida en el nuevo sistema. Si es posible, trate con la empresa para excluir datos que no tienen forma de mapearse y potencialmente romper el nuevo sistema, y ​​prepare una solución alternativa
3. Migración real de datos. Hay muchas estrategias para realizar la migración de datos. Por ejemplo: big bang, incremental
4. Informe de consolidación. Si ambos sistemas se ejecutan en paralelo, cómo producir un informe correcto y consistente

Evento con un plan cuidadoso, ¡pasa una mierda! Un grupo de trabajo especial debería estar preparado para tratar los problemas relacionados con la migración.

1) ¿Qué piensa sobre la migración de datos, especialmente para los casos de la vida real y no solo desde la perspectiva de un desarrollador ?:

La migración es parte esencial del desarrollo de sistemas. Si reemplaza parcial o totalmente los sistemas antiguos, la migración es una realidad si la gerencia lo quiere o no. Si los datos existentes son malos, se reflejarán mal en su nuevo sistema. Por lo tanto, es de gran importancia tener una buena estrategia de migración.

2) ¿Tienes algún argumento en contra de las opiniones de mis gerentes?

Sí, la migración es arriesgada, pero también es un hecho de la vida, así que enfréntalo. Y lidiar con esto lo antes posible.

3) ¿Cómo maneja su empresa las migraciones de datos y las dificultades causadas por ellas?

Mi empresa, con creciente éxito, ha involucrado activamente a los clientes en el proceso de migración. Revisamos los datos existentes lo mejor que podemos en los primeros pasos del proyecto, y alentamos al cliente a mejorar la calidad de los datos antes de comenzar la migración. A veces lo exigimos realmente.

4: Cualquier otro pensamiento interesante que pertenezca a estos temas.

Mi consejo es dividir el proceso de migración en dos pasos: conversión y limpieza de datos. La conversión es bastante sencilla: se trata de asignar los objetos del sistema antiguo al nuevo sistema nuevo. La limpieza de datos, por otro lado, puede ser algo muy complicado (como se mencionó anteriormente). Involucre al cliente lo más posible y comience el proceso lo antes posible. Tenga en cuenta que los datos incorrectos se reflejarán mal en su nuevo sistema, a veces sin razón alguna. Cuando un nuevo sistema no funciona, un cliente rara vez culpará a los datos que parecían funcionar bien en el sistema anterior.

Si los datos que planea migrar actualmente son incorrectos, deben corregirse si realiza una migración o no. Datos incorrectos = datos inútiles.

Las migraciones son arriesgadas, eso es cierto. Pero también lo es cada proyecto importante de TI. Hay formas de mitigar el riesgo y, sin duda, deben planificarse por adelantado en una migración.

Primero, siempre debe tener una forma de volver al sistema como está ahora. Las segundas migraciones deben realizarse en servidores de prueba configurados solo para la migración. Es una tontería hacer una migración sin la capacidad de probarlo primero. Tercero, todo el código para la migración debe estar en control de origen.

Cuarto, necesita requisitos y planes de prueba antes de comenzar la migración. Debe saber que si tenía 1.293.687 registros en el sistema anterior, que tiene los mismos en el nuevo o sabe a dónde fueron (quizás a una tabla de excepción). Si está normalizando un esquema desnormalizado, debe calcular cuántos registros debe terminar antes de comenzar y luego verificarlo. Necesita documentación que especifique cuáles son las asignaciones de un sistema a otro. Esto ayudará a su personal de control de calidad a verificar si los datos se enviaron al lugar correcto.

Debe determinar cómo manejar los datos incorrectos actuales. Lo que se puede limpiar, lo que podría necesitar un valor en un campo obligatorio que diga 'Desconocido', lo que se debe arrojar a una tabla de excepción, lo que necesita la intervención manual de un grupo de usuarios (decidir si estas dos personas son realmente un duplicado o ¿hay dos médicos en esa práctica con el mismo nombre, por ejemplo, y si es un duplicado qué datos elegir cuando difieren los dos registros, etc.).

La clave para una migración exitosa es la planificación. He descubierto que la planificación (que incluye escribir los casos de prueba y las pruebas unitarias) generalmente lleva más tiempo que el desarrollo real.

La siguiente clave para una migración de datos exitosa es el control de calidad. Este no es un proyecto para lanzar al equipo de control de calidad el día antes del lanzamiento. Este no es un proyecto para lanzar cuando QA dice que hay un problema.

Otra clave para una migración exitosa es implementar la mayoría de los datos y probarlos mientras el sistema original todavía se está ejecutando. Si está moviendo muchos registros, esto podría llevar mucho tiempo y se producirán nuevos cambios. Por lo tanto, su proceso también debe poder extraer los cambios de datos después de que comience la migración. SQL Server, por ejemplo, tiene algo llamado Change Data Capture que puede ayudar con esto. Puede realizar una copia de seguridad del sistema original y activar la captura de datos modificados al mismo tiempo. Luego puede restablecer la copia de seguridad en su servidor de migración, probar la migración, cargar la mayoría de los datos y luego solo tiene que cargar los registros que han cambiado. Cuando migre los registros finales, apague el sistema de origen hasta que finalice la migración. Esta es una razón para migrar la mayoría de los registros con anticipación, así que la aplicación está inactiva la menor cantidad de tiempo. Elija bien el tiempo de migración, no cierre el sistema de nómina el día en que deberían procesar la nómina o enviar W2. Y hazlo durante las horas de bajo uso. Si tiene varios clientes, podría considerar migrar uno primero y asegurarse de que todo esté bien antes de hacer los demás. Es mucho más fácil revertir los datos de un cliente que 10000 si hay un problema. Pero planifique esto cuidadosamente si lo hace. s datos de 10000 si hay un problema. Pero planifique esto cuidadosamente si lo hace. s datos de 10000 si hay un problema. Pero planifique esto cuidadosamente si lo hace.

Si la migración involucra una nueva interfaz de usuario, haga que los usuarios reales la usen como parte de las pruebas de migración. Luego, capacite a los otros usuarios antes de que se active (pero menos de una semana antes de que se active o se olvidarán). Haga que los usuarios que participan en las pruebas ayuden a diseñar la capacitación, saben qué preguntas tenían y qué necesitan saber las personas en qué orden. Obtenga su entrada, haciendo un campo obligatorio porque cree que no debería ser útil si los usuarios generalmente no tienen esos datos cuando ingresan los registros. Simplemente pondrán basura en el campo recién requerido porque de lo contrario no pueden obtener los datos.

Mire lo que está mal con los datos actuales, ¿puede agregar claves externas, restricciones, desencadenantes, reglas comerciales en la aplicación, valores predeterminados, etc. para evitar que esto sea malo en el futuro? Cuando limpia datos incorrectos, también necesita crear una forma de evitar que esos datos igualmente malos ingresen en el futuro. Analice por qué se asignaron los datos incorrectos y corrija los agujeros en el diseño.

La migración de datos es una necesidad. Sin la migración de datos, a menudo no puede avanzar. Muchos sistemas con los que he trabajado requieren un historial solo disponible de sistemas anteriores. La migración es el único método práctico para hacer esto. La calidad de los datos es a menudo un problema. En general, esto debería tratarse en el sistema anterior. Esto puede requerir cambios en los datos para recuperar la calidad.

Otros sistemas con los que he trabajado dependían de los datos de otros sistemas. Este es un tema diferente pero significativo. En algunos casos, los datos se pueden reemplazar por completo. Otros casos pueden manejarse mejor combinando los cambios incluidos en los nuevos datos en el conjunto existente. Estos tipos de migraciones deben incluir comprobaciones de validez para el feed entrante.

La capacidad de validar y limpiar datos existentes puede ser una característica importante de un sistema. Esto es independiente de la migración. A menudo hay mecanismos para modificar datos que están fuera del control del sistema. Esto puede hacer que los datos se vuelvan inválidos. Otros problemas de datos resultan de errores en la aplicación. La ejecución periódica de las rutinas de validación puede ayudar a identificar el problema y permitir que los datos se limpien antes de que sea el momento de la migración. Como se ha señalado, la limpieza temprana de los datos puede facilitar la migración.

Algunas validaciones son urgentes y no deben aplicarse a datos que no se hayan modificado. Esto es común con los valores codificados, donde los códigos han sido retirados. Debería ser posible cambiar otros campos en el registro sin activar errores de validación. Esto puede hacer que la validación de la actualización sea más compleja ya que necesita identificar qué campos cambiaron antes de la validación. La validación de campo cruzado también puede ser más compleja. La capacidad de tratar algunos registros como de solo lectura puede ayudar en este caso, ya que se puede evitar la validación.

En un sistema en el que trabajé, el cliente rechazó parcialmente el nuevo sistema. Se negaron a permitir que se utilizaran los nuevos módulos de entrada de datos. Sin embargo, querían el procesamiento por lotes del nuevo sistema. La solución fue migrar los datos todas las noches antes de la ejecución por lotes.

Es un mal necesario. He estado en ambos extremos y estos son algunos de los otros problemas que agravan el problema.

1. Especialmente en la empresa, cuando las empresas van a un nuevo sistema, quieren que haga todo lo que hizo el sistema anterior. No revisan sus procedimientos. Están tan abrumados que solo quieren seguir haciendo todo de la misma manera. Esto es seguro para ellos.
2. No se toman el tiempo para aprender el nuevo sistema o contratar personas con experiencia.
3. Quieren personalizar el nuevo sistema para acomodar # 1 o para manejar algún aspecto nuevo de su negocio. Nuevo sistema X Personalizaciones X Datos convertidos = Complicaciones compuestas
4. No se dedica suficiente tiempo a las pruebas.
5. Los clientes odian correr en paralelo / hacer cosas dos veces. No se puede culpar a los usuarios porque no se les da tiempo para hacerlo, ya que todas sus otras tareas se mantienen a toda máquina.

Si sus gerentes pueden justificar la pérdida de ventas al no convertir los datos, más poder para ellos. Decirles a sus clientes que todas las conversiones de datos fallan no va a funcionar porque alguien más siempre les dirá que lo hará (generalmente su competencia).

¿Qué piensa sobre la migración de datos, especialmente para los casos de la vida real y no solo desde la perspectiva de un desarrollador?

El software tiene que actualizarse regularmente. Para asegurarse de que la migración sea segura, necesita copias de seguridad y pruebas.

¿Tienes algún argumento contra las opiniones de mis gerentes?

tiene razón en que es arriesgado. pero puede adaptar técnicas para que sea menos arriesgado.

¿Cómo maneja su empresa las migraciones de datos y las dificultades causadas por ellas?

tenemos respaldo diario, respaldo incremental, respaldo antes de cada implementación en producción. que al menos te permite retroceder si sucede algo malo.

Tenemos entorno de prueba, pruebas automatizadas y servidor de compilación diario. también un procedimiento de prueba de humo para asegurarse de que las operaciones y funciones principales funcionen correctamente. Involucramos a desarrolladores, control de calidad y usuarios para probar la compilación (que ha migrado los datos).

Estamos utilizando Ruby on Rails, que proporciona versiones de migración de datos, actualización y reversión. lo que nos hace la vida más fácil.

estamos usando capistrano para ejecutar la actualización del código y la migración de datos. Mantener la migración automatizada y simple es una de las cosas clave para garantizar que el sistema de producción funcione.

¿Alguna otra idea interesante que pertenezca a estos temas?

Otra preocupación con respecto a la migración de datos para mí es la consistencia de la actualización del código y la migración de datos. en mi caso, nuevamente, estamos usando formas automatizadas para manejar eso. y siempre listo para retroceder.

ejecutar la migración de datos manualmente puede convertir la base de datos en un estado desconocido. y es difícil comparar la versión de migración de datos entre diferentes entornos de servidor.

Espero eso ayude.

No perdemos el tiempo tratando de migrar datos de sistemas antiguos porque el tiempo, la inversión y el riesgo son demasiado altos. Simplemente avanzamos con sistemas más nuevos y nos integramos cuando es necesario.

Cada negocio tiene algún tipo de sistema heredado que debe soportar, y eso es solo un costo normal de hacer negocios.

La recompensa que sus gerentes esperan obtener debería ser extremadamente alta dado el costo de la migración.