Migre datos heredados sin estropearlos

La migración de datos heredados es difícil.

Muchas organizaciones tienen sistemas de CRM empresariales locales antiguos y complejos. Hoy en día, hay muchas alternativas de SaaS en la nube, que vienen con muchos beneficios; pague sobre la marcha y pague solo por lo que use. Por lo tanto, deciden pasar a los nuevos sistemas.

Nadie quiere dejar datos valiosos sobre los clientes en el sistema anterior y comenzar con el nuevo sistema vacío, por lo que debemos migrar estos datos. Desafortunadamente, la migración de datos no es una tarea fácil, ya que alrededor del 50 por ciento del esfuerzo de implementación lo consumen las actividades de migración de datos. Según Gartner, Salesforce es el líder en soluciones de CRM en la nube. Por lo tanto, la migración de datos es un tema importante para la implementación de Salesforce.

Entonces, ¿cómo podemos garantizar una transición exitosa de los datos heredados a un sistema nuevo y brillante y garantizar que preservaremos todo su historial? En este artículo, brindo 10 consejos para una migración de datos exitosa. Los primeros cinco consejos se aplican a cualquier migración de datos, independientemente de la tecnología utilizada.

Migración de datos en general

1. Hacer de la migración un proyecto separado

En la lista de verificación de implementación de software, la migración de datos no es un elemento de "exportación e importación" manejado por una herramienta inteligente de migración de datos de "presionar un botón" que tiene un mapeo predefinido para los sistemas de destino.

La migración de datos es una actividad compleja que merece un proyecto, un plan, un enfoque, un presupuesto y un equipo por separado. Se debe crear un alcance y un plan a nivel de entidad al comienzo del proyecto, asegurando que no haya sorpresas, como "Oh, olvidamos cargar los informes de visita de esos clientes, ¿quién lo hará?" dos semanas antes de la fecha límite.

El enfoque de migración de datos define si cargaremos los datos de una sola vez (también conocido como big bang ) o si cargaremos lotes pequeños cada semana.

Sin embargo, esta no es una decisión fácil. El enfoque debe acordarse y comunicarse a todas las partes interesadas comerciales y técnicas para que todos sepan cuándo y qué datos aparecerán en el nuevo sistema. Esto también se aplica a las interrupciones del sistema.

2. Estime de manera realista

No subestime la complejidad de la migración de datos. Muchas tareas que requieren mucho tiempo acompañan este proceso, que pueden ser invisibles al comienzo del proyecto.

Por ejemplo, cargar conjuntos de datos específicos con fines de capacitación con una gran cantidad de datos realistas, pero con elementos confidenciales ofuscados, de modo que las actividades de capacitación no generen notificaciones por correo electrónico a los clientes.

El factor básico para la estimación es el número de campos que se transferirán desde un sistema de origen a un sistema de destino.

Se necesita cierta cantidad de tiempo en las diferentes etapas del proyecto para cada campo, incluida la comprensión del campo, la asignación del campo de origen al campo de destino, la configuración o creación de transformaciones, la realización de pruebas, la medición de la calidad de los datos para el campo, etc.

El uso de herramientas inteligentes, como Jitterbit, Informatica Cloud Data Wizard, Starfish ETL, Midas y similares, puede reducir este tiempo, especialmente en la fase de construcción.

En particular, la comprensión de los datos de origen, la tarea más crucial en cualquier proyecto de migración, no se puede automatizar con herramientas, pero requiere que los analistas se tomen el tiempo de revisar la lista de campos uno por uno.

La estimación más simple del esfuerzo general es un día-hombre por cada campo transferido desde el sistema heredado.

Una excepción es la replicación de datos entre los mismos esquemas de origen y de destino sin más transformación, a veces conocida como migración 1:1, donde podemos basar la estimación en la cantidad de tablas para copiar.

Un presupuesto detallado es un arte en sí mismo.

3. Comprobar la calidad de los datos

No sobreestime la calidad de los datos de origen, incluso si no se informan problemas de calidad de los datos de los sistemas heredados.

Los nuevos sistemas tienen nuevas reglas, que pueden violarse con datos heredados. Aquí hay un ejemplo simple. El correo electrónico de contacto puede ser obligatorio en el nuevo sistema, pero un sistema heredado de 20 años puede tener un punto de vista diferente.

Puede haber minas ocultas en datos históricos que no se han tocado durante mucho tiempo pero que podrían activarse al transferirse al nuevo sistema. Por ejemplo, los datos antiguos que utilizan monedas europeas que ya no existen deben convertirse a euros; de lo contrario, las monedas deben agregarse al nuevo sistema.

La calidad de los datos influye significativamente en el esfuerzo, y la regla simple es: cuanto más avancemos en la historia, mayor será el desorden que descubriremos. Por lo tanto, es vital decidir desde el principio cuánta historia queremos transferir al nuevo sistema.

4. Involucrar a la gente de negocios

Los empresarios son los únicos que realmente entienden los datos y, por lo tanto, pueden decidir qué datos se pueden desechar y qué datos conservar.

Es importante que alguien del equipo de negocios participe durante el ejercicio de mapeo y, para futuras revisiones, es útil registrar las decisiones de mapeo y los motivos de las mismas.

Dado que una imagen vale más que mil palabras, cargue un lote de prueba en el nuevo sistema y deje que el equipo comercial juegue con él.

Incluso si el equipo comercial revisa y aprueba el mapeo de migración de datos, pueden aparecer sorpresas una vez que los datos aparecen en la interfaz de usuario del nuevo sistema.

“Oh, ya veo, tenemos que cambiarlo un poco”, se convierte en una frase común.

No involucrar a los expertos en la materia, que suelen ser personas muy ocupadas, es la causa más común de problemas después de que se pone en marcha un nuevo sistema.

5. Apunte a una solución de migración automatizada

La migración de datos a menudo se ve como una actividad de una sola vez, y los desarrolladores tienden a terminar con soluciones llenas de acciones manuales con la esperanza de ejecutarlas solo una vez. Pero hay muchas razones para evitar este enfoque.

• Si la migración se divide en varias oleadas, tenemos que repetir las mismas acciones varias veces.
• Por lo general, hay al menos tres ejecuciones de migración para cada ola: una ejecución de prueba para probar el rendimiento y la funcionalidad de la migración de datos, una carga completa de validación de datos para probar todo el conjunto de datos y realizar pruebas comerciales y, por supuesto, la carga de producción. El número de ejecuciones aumenta con la mala calidad de los datos. Mejorar la calidad de los datos es un proceso iterativo, por lo que necesitamos varias iteraciones para alcanzar la tasa de éxito deseada.

Por lo tanto, incluso si la migración es una actividad única por naturaleza, tener acciones manuales puede ralentizar significativamente sus operaciones.

Migración de datos de Salesforce

A continuación, cubriremos cinco consejos para una migración exitosa de Salesforce. Tenga en cuenta que es probable que estos consejos también se apliquen a otras soluciones en la nube.

6. Prepárate para Cargas Largas

El rendimiento es una de las ventajas y desventajas, si no la más importante, al pasar de una solución local a una en la nube, sin excluir Salesforce.

Los sistemas locales generalmente permiten la carga directa de datos en una base de datos subyacente y, con un buen hardware, podemos alcanzar fácilmente millones de registros por hora.

Pero, no en la nube. En la nube, estamos muy limitados por varios factores.

• Latencia de red: los datos se transfieren a través de Internet.
• Capa de aplicación de Salesforce: los datos se mueven a través de una gruesa capa de tenencia múltiple de API hasta que aterrizan en sus bases de datos de Oracle.
• Código personalizado en Salesforce: validaciones personalizadas, activadores, flujos de trabajo, reglas de detección de duplicados, etc., muchos de los cuales desactivan las cargas paralelas o masivas.

Como resultado, el rendimiento de la carga puede ser de miles de cuentas por hora.

Puede ser menos, o puede ser más, dependiendo de cosas, como la cantidad de campos, validaciones y disparadores. Pero es varios grados más lento que una carga de base de datos directa.

También se debe considerar la degradación del rendimiento, que depende del volumen de datos en Salesforce.

Es causado por índices en el RDBMS subyacente (Oracle) que se usa para verificar claves externas, campos únicos y evaluación de reglas de duplicación. La fórmula básica es una desaceleración de aproximadamente el 50 por ciento por cada grado de 10, causada por O (logN), la porción de complejidad de tiempo en las operaciones de clasificación y árbol B.

Además, Salesforce tiene muchos límites de uso de recursos.

Uno de ellos es el límite de API masiva establecido en 5000 lotes en ventanas móviles de 24 horas, con un máximo de 10 000 registros en cada lote.

Entonces, el máximo teórico es de 50 millones de registros cargados en 24 horas.

En un proyecto real, el máximo es mucho más bajo debido al tamaño de lote limitado cuando se usan, por ejemplo, disparadores personalizados.

Esto tiene un fuerte impacto en el enfoque de migración de datos.

Incluso para conjuntos de datos de tamaño mediano (de 100 000 a 1 millón de cuentas), el enfoque big bang está fuera de discusión, por lo que debemos dividir los datos en olas de migración más pequeñas.

Esto, por supuesto, afecta todo el proceso de implementación y aumenta la complejidad de la migración porque agregaremos incrementos de datos en un sistema que ya está poblado por migraciones anteriores y datos ingresados ​​por los usuarios.

También debemos considerar estos datos existentes en las transformaciones y validaciones de migración.

Además, las cargas prolongadas pueden significar que no podemos realizar migraciones durante una interrupción del sistema.

Si todos los usuarios están ubicados en un país, podemos aprovechar una interrupción de ocho horas durante la noche.

Pero para una empresa como Coca-Cola, con operaciones en todo el mundo, eso no es posible. Una vez que tenemos EE. UU., Japón y Europa en el sistema, abarcamos todas las zonas horarias, por lo que el sábado es la única opción de interrupción que no afecta a los usuarios.

Y eso puede no ser suficiente, por lo que debemos cargar mientras estamos en línea , cuando los usuarios están trabajando con el sistema.

7. Respete las necesidades de migración en el desarrollo de aplicaciones

Los componentes de la aplicación, como las validaciones y los disparadores, deben poder manejar las actividades de migración de datos. La deshabilitación dura de las validaciones en el momento de la carga de la migración no es una opción si el sistema debe estar en línea. En cambio, tenemos que implementar una lógica diferente en las validaciones de los cambios realizados por un usuario de migración de datos.

• Los campos de fecha no deben compararse con la fecha real del sistema porque eso deshabilitaría la carga de datos históricos. Por ejemplo, la validación debe permitir ingresar una fecha de inicio de cuenta anterior para los datos migrados.
• Los campos obligatorios, que no pueden completarse con datos históricos, deben implementarse como no obligatorios, pero con validación sensible para el usuario, lo que permite valores vacíos para los datos provenientes de la migración, pero rechaza los valores vacíos provenientes de usuarios normales a través de la GUI. .
• Los disparadores, especialmente aquellos que envían nuevos registros a la integración, deben poder activarse o desactivarse para el usuario de migración de datos a fin de evitar que la integración se inunde con datos migrados.

Otro truco es usar el campo ID heredado o ID de migración en cada objeto migrado. Hay dos razones para esto. El primero es obvio: mantener la identificación del sistema anterior para retroceder; una vez que los datos están en el nuevo sistema, es posible que las personas aún deseen buscar en sus cuentas utilizando las ID antiguas, que se encuentran en lugares como correos electrónicos, documentos y sistemas de seguimiento de errores. ¿Mal hábito? Quizás. Pero los usuarios te lo agradecerán si conservas sus identificaciones anteriores. La segunda razón es técnica y proviene del hecho de que Salesforce no acepta ID proporcionados explícitamente para nuevos registros (a diferencia de Microsoft Dynamics), sino que los genera durante la carga. El problema surge cuando queremos cargar objetos secundarios porque tenemos que asignarles ID de los objetos principales. Dado que conoceremos esos ID solo después de la carga, este es un ejercicio inútil.

Usemos Cuentas y sus Contactos, por ejemplo:

1. Generar datos para Cuentas.
2. Cargue cuentas en Salesforce y reciba los ID generados.
3. Incorporar nuevos ID de cuenta en los datos de contacto.
4. Generar datos para Contactos.
5. Cargar contactos en Salesforce.

Podemos hacer esto más simplemente cargando Cuentas con sus ID heredadas almacenadas en un campo externo especial. Este campo se puede usar como una referencia principal, por lo que al cargar Contactos, simplemente usamos el ID heredado de la cuenta como un puntero a la cuenta principal:

1. Genere datos para Cuentas, incluida la ID heredada.
2. Genere datos para los contactos, incluido el ID heredado de la cuenta.
3. Cargue cuentas en Salesforce.
4. Cargue contactos en Salesforce, utilizando el ID heredado de la cuenta como referencia principal.

Lo bueno aquí es que hemos separado una generación y una fase de carga, lo que permite un mejor paralelismo, reduce el tiempo de interrupción, etc.

8. Tenga en cuenta las funciones específicas de Salesforce

Como cualquier sistema, Salesforce tiene muchas partes complicadas que debemos conocer para evitar sorpresas desagradables durante la migración de datos. Aquí hay un puñado de ejemplos:

• Algunos cambios en los usuarios activos generan automáticamente notificaciones por correo electrónico a los correos electrónicos de los usuarios. Por lo tanto, si queremos jugar con los datos de los usuarios, primero debemos desactivar los usuarios y activarlos después de que se completen los cambios. En entornos de prueba, codificamos los correos electrónicos de los usuarios para que las notificaciones no se activen en absoluto. Dado que los usuarios activos consumen licencias costosas, no podemos tener a todos los usuarios activos en todos los entornos de prueba. Tenemos que administrar subconjuntos de usuarios activos, por ejemplo, para activar solo aquellos en un entorno de capacitación.
• Los usuarios inactivos, para algunos objetos estándar como Cuenta o Caso, se pueden asignar solo después de otorgar al sistema el permiso "Actualizar registros con propietarios inactivos", pero se pueden asignar, por ejemplo, a Contactos y todos los objetos personalizados.
• Cuando el contacto está desactivado, todos los campos de exclusión voluntaria se activan silenciosamente.
• Al cargar un miembro del equipo de cuenta duplicado o un objeto compartido de cuenta, el registro existente se sobrescribe silenciosamente. Sin embargo, cuando se carga un socio de oportunidad duplicado, el registro simplemente se agrega, lo que da como resultado un duplicado.
• Los campos del sistema, como Created Date de creación, Created By ID , Last Modified Date , Last Modified By ID , se pueden escribir explícitamente solo después de otorgar un nuevo permiso del sistema "Establecer campos de auditoría al crear registros".
• Los cambios de valores del historial de campos no se pueden migrar en absoluto.
• Los propietarios de los artículos de conocimientos no se pueden especificar durante la carga, pero se pueden actualizar más adelante.
• La parte complicada es el almacenamiento de contenido (documentos, archivos adjuntos) en Salesforce. Hay varias formas de hacerlo (usando Adjuntos, Archivos, Adjuntos de fuentes, Documentos), y cada forma tiene sus pros y sus contras, incluidos diferentes límites de tamaño de archivo.
• Los campos de lista de selección obligan a los usuarios a seleccionar uno de los valores permitidos, por ejemplo, un tipo de cuenta. Pero al cargar datos mediante la API de Salesforce (o cualquier herramienta creada a partir de ella, como el cargador de datos de Apex o el conector de Informatica Salesforce), se pasará cualquier valor.

La lista continúa, pero la conclusión es: familiarícese con el sistema y aprenda lo que puede hacer y lo que no puede hacer antes de hacer suposiciones. No asuma un comportamiento estándar, especialmente para los objetos principales. Siempre investiga y prueba.

9. No utilice Salesforce como plataforma de migración de datos

Es muy tentador utilizar Salesforce como plataforma para crear una solución de migración de datos, especialmente para los desarrolladores de Salesforce. Es la misma tecnología para la solución de migración de datos que para la personalización de la aplicación Salesforce, la misma GUI, el mismo lenguaje de programación Apex, la misma infraestructura. Salesforce tiene objetos que pueden actuar como tablas y una especie de lenguaje SQL, el lenguaje de consulta de objetos de Salesforce (SOQL). Sin embargo, no lo use; sería un defecto arquitectónico fundamental.

Salesforce es una excelente aplicación SaaS con muchas características interesantes, como colaboración avanzada y personalización enriquecida, pero el procesamiento masivo de datos no es una de ellas. Las tres razones más importantes son:

• Rendimiento : el procesamiento de datos en Salesforce es varios grados más lento que en RDBMS.
• Falta de funciones analíticas : Salesforce SOQL no admite consultas complejas ni funciones analíticas que deben ser compatibles con el lenguaje de Apex y degradarían aún más el rendimiento.
• Arquitectura * – Poner una plataforma de migración de datos dentro de un entorno específico de Salesforce no es muy conveniente. Por lo general, tenemos múltiples entornos para propósitos específicos, a menudo creados ad hoc para que podamos dedicar mucho tiempo a la sincronización del código. Además, también confiaría en la conectividad y la disponibilidad de ese entorno específico de Salesforce.

En su lugar, cree una solución de migración de datos en una instancia separada (podría ser una nube o local) utilizando una plataforma RDBMS o ETL. Conéctelo con los sistemas de origen y apunte a los entornos de Salesforce que desee, mueva los datos que necesita a su área de preparación y procéselos allí. Esto le permitirá:

• Aproveche toda la potencia y las capacidades del lenguaje SQL o las funciones ETL.
• Tenga todo el código y los datos en un solo lugar para que pueda ejecutar análisis en todos los sistemas.
  • Por ejemplo, puede combinar la configuración más reciente del entorno de prueba de Salesforce más actualizado con datos reales del entorno de producción de Salesforce.
• No depende tanto de la tecnología de los sistemas de origen y de destino y puede reutilizar su solución para el próximo proyecto.

10. Supervisión de metadatos de Salesforce

Al comienzo del proyecto, generalmente tomamos una lista de campos de Salesforce y comenzamos el ejercicio de mapeo. Durante el proyecto, a menudo sucede que el equipo de desarrollo de la aplicación agrega nuevos campos a Salesforce, o que se modifican algunas propiedades de los campos. Podemos pedirle al equipo de aplicaciones que notifique al equipo de migración de datos sobre cada cambio en el modelo de datos, pero no siempre funciona. Para estar seguros, necesitamos tener todos los cambios del modelo de datos bajo supervisión.

Una forma común de hacer esto es descargar, de manera regular, metadatos relevantes para la migración de Salesforce a algún repositorio de metadatos. Una vez que tenemos esto, no solo podemos detectar cambios en el modelo de datos, sino que también podemos comparar modelos de datos de dos entornos de Salesforce.

Qué metadatos descargar:

• Una lista de objetos con sus etiquetas y nombres técnicos y atributos como creatable o updatable .
• Una lista de campos con sus atributos (mejor obtenerlos todos).
• Una lista de valores de lista de selección para campos de lista de selección. Los necesitaremos para mapear o validar los datos de entrada para valores correctos.
• Una lista de validaciones, para asegurarse de que las nuevas validaciones no generen problemas para los datos migrados.

¿Cómo descargar metadatos de Salesforce? Bueno, no hay un método de metadatos estándar, pero hay varias opciones:

• Generar Enterprise WSDL: en la aplicación web de Salesforce, vaya al menú Setup / API y descargue Enterprise WSDL fuertemente tipado, que describe todos los objetos y campos en Salesforce (pero no los valores de lista de selección ni las validaciones).
• Llame al servicio web describeSObjects de Salesforce, directamente o mediante el contenedor Java o C# (consulte la API de Salesforce). De esta manera, obtendrá lo que necesita y esta es la forma recomendada de exportar los metadatos.
• Utilice cualquiera de las numerosas herramientas alternativas disponibles en Internet.

Prepárese para la próxima migración de datos

Las soluciones en la nube, como Salesforce, están listas al instante. Si está satisfecho con las funcionalidades integradas, simplemente inicie sesión y utilícelo. Sin embargo, Salesforce, como cualquier otra solución de CRM en la nube, trae problemas específicos a los temas de migración de datos a tener en cuenta, en particular, con respecto a los límites de rendimiento y recursos.

Mover datos heredados al nuevo sistema siempre es un viaje, a veces un viaje al historial oculto en los datos de años anteriores. En este artículo, basado en una docena de proyectos de migración, he presentado diez consejos sobre cómo migrar datos heredados y evitar con éxito la mayoría de las trampas.

La clave es entender lo que revelan los datos. Por lo tanto, antes de comenzar la migración de datos, asegúrese de que su equipo de desarrollo de Salesforce esté bien preparado para los posibles problemas que puedan tener sus datos.