Mejores practicas para migración de datos a Salesforce

La migración de datos es una tarea común que los administradores, desarrolladores y arquitectos de Salesforce deben completar. Comprender las mejores prácticas sobre la mejor manera de abordar la migración de datos garantizará que se eviten errores costosos y que la migración de datos sea completa y precisa.

Evaluación de datos

En cualquier negocio, los datos son clave y crecen rápidamente, lo que resulta en el uso de varias bases de datos y almacenes de datos que se utilizan para almacenar esos datos de forma segura. A veces, los datos están en diferentes formatos y es necesario trabajar en ellos para que tengan el mismo formato para evitar confusiones. Pero antes de entrar en una discusión profunda sobre los datos, primero comprendamos las diferencias entre la migración, conversión e integración de datos:

• Migración de datos: la migración de datos es el proceso de mover datos de un sistema o aplicación a otro. Este suele ser el resultado de retirar un sistema para actualizarlo a un nuevo sistema que proporciona una funcionalidad empresarial mejorada. A medida que más empresas pasan de los sistemas locales a la infraestructura en la nube, se dan cuenta de que los datos deben moverse junto con la aplicación para continuar con las operaciones comerciales.
• Conversión de datos: la conversión es el proceso de transformar datos de un formato a otro. Cada aplicación tiene su propio conjunto de estándares que sigue en términos de formato de datos, tipos de datos o la longitud de los campos. Por ejemplo, en un sistema heredado, es posible que el campo Etapa en un objeto Oportunidad sea un campo numérico. Durante el proceso de conversión, debemos asignar estos valores de etapa basados ​​en números a los valores de etapa basados ​​en texto en Salesforce. Por lo general, esto implica realizar un trabajo de transformación en un área de preparación antes de que los datos se carguen en el destino. Para evitar confusión en la conversión y migración de datos, es importante entender que la primera implica la transformación de datos, mientras que la segunda está más orientada hacia los procesos y las herramientas que se utilizan para mover los datos de un sistema a otro.
• Integración de datos: implica combinar datos de diferentes fuentes para proporcionar una vista unificada al usuario. Por ejemplo, una empresa utiliza Salesforce como herramienta de gestión de relaciones con el cliente (CRM), pero Sistemas, aplicaciones y productos (SAP) como herramienta de cumplimiento de pedidos. En ausencia de herramientas de autoservicio donde el cliente pueda verificar el estado por sí mismo, los representantes de ventas necesitarían conocer el estado del pedido para poder mantener al cliente actualizado. En este escenario, a medida que el pedido pasa por las diferentes etapas en SAP y el estado cambia, el estado puede reflejarse en Salesforce.

Componentes de una evaluación de migración de datos

La migración de datos no debe ser simplemente un elemento de una sola línea en el plan del proyecto porque tiene matices y requiere una planificación y ejecución cuidadosas. Tenerlo como un elemento de línea menor en el plan del proyecto es una forma segura de encontrar problemas al ejecutar la migración al entorno de producción. Más bien, debe tratarse como un componente principal de cualquier proyecto con su propio cronograma detallado, tareas y dependencias.

Con una evaluación adecuada, puede medir el panorama y proporcionar estimaciones presupuestarias y de tiempo realistas que pueden garantizar una migración de datos de calidad. Analicemos algunos de los componentes integrales de una evaluación sólida de la migración de datos:

• Volumen de datos: esto suele ser lo primero en lo que piensan la mayoría de los equipos de proyecto durante las discusiones sobre migración de datos. Es una consideración importante ya que la migración de 50,000 registros requerirá un enfoque diferente al de la migración de 100 millones de registros. Por ejemplo, la elección de API, ya sea para usar Bulk o REST API, tendrá más sentido para el último caso de uso (migrar 100 millones de registros) que para el primero.
• Tipo de datos: otra consideración es el tipo y formato de datos que planea migrar. Por ejemplo, migrar clientes potenciales desde el sistema heredado será mucho menos laborioso que migrar cuentas, contactos, oportunidades y productos de oportunidad. Esto se debe a las posibles relaciones entre estos objetos en el sistema heredado y los diferentes tipos de datos y formatos de los campos. Se requerirá más esfuerzo si los valores de Stage, por ejemplo, son diferentes en el sistema heredado que en Salesforce.
• Número de sistemas: ¿Cuál es el número de sistemas involucrados en la migración? ¿Estamos migrando datos de un sistema de origen o de varios sistemas de origen a Salesforce? Por ejemplo, en una migración de datos de tipo consolidación, podría tener Oracle NetSuite y / o Microsoft Dynamics como sistemas de origen, cada uno con sus propios tipos de datos y estándares. Migrar esto a Salesforce será mucho más complicado que, digamos, simplemente migrar datos desde Oracle NetSuite. Esto también puede requerir que se introduzca una base de datos provisional en el panorama donde se pueda realizar la deduplicación y la transformación antes de cargar los datos en Salesforce.
• Privacidad: con la introducción de nuevas regulaciones de privacidad en todo el mundo y la revisión de las existentes, cuáles son las consideraciones para la migración de datos durante la fase de preparación. ¿Pueden los equipos offshore tener acceso a él? ¿Dónde debe ubicarse la infraestructura utilizada durante la migración de datos? ¿Puede ser en un país que puede no tener leyes de privacidad muy sólidas o que no las hace cumplir de manera efectiva? Todas estas son consideraciones que podrían tener un impacto en la duración y en el costo del proyecto de migración de datos. Comprender esto y cualquier restricción para acceder a los datos, ya sea que se base en los requisitos del cliente o por razones de cumplimiento, lo ayudará a planificar y abordar estos requisitos de manera adecuada.

• Retención de datos: es posible que no todos los datos del sistema heredado deban transferirse a Salesforce, pero la empresa puede tener requisitos relacionados con la retención de datos para fines de cumplimiento. Al trabajar con arquitectos y otras partes interesadas, el equipo del proyecto debería proporcionar soluciones para identificar las formas óptimas de cumplir con el cumplimiento y proporcionar acceso continuo a los datos del negocio.
• Disponibilidad de recursos: la migración de datos nunca es un ejercicio aislado en el que el equipo de migración de datos se va, trabaja en el proyecto y regresa con un producto terminado que, cuando se ejecuta en producción, migrará los datos sin problemas. Debe involucrar recursos comerciales que estén íntimamente familiarizados con los datos y puedan guiar al equipo y validar la migración de datos, así como la ejecución de producción. Comprender de antemano cuáles son las limitaciones de recursos comerciales puede ayudar a identificar los riesgos potenciales y brindar la oportunidad de implementar una estrategia de mitigación efectiva.
• Panorama actual: esto implica evaluar si todos los sistemas en consideración están en la nube o en las instalaciones. ¿Existe alguna consideración especial con respecto al acceso a estos sistemas y dónde están los horarios regulares de interrupción planificados? Los sistemas locales generalmente requieren más configuración debido a la necesidad de acceder a la red interna. Esto también incluiría la coordinación con los recursos de cualquier proveedor externo cuya asistencia pueda ser necesaria durante la migración.
• Comunicación: Un buen proyecto de migración siempre tendrá un plan de comunicación sólido que considere las necesidades de los diferentes stakeholders y cómo les gusta que se les comunique. Dependiendo del alcance, la complejidad y la cantidad de partes interesadas en el proyecto de migración de datos, el plan de comunicación puede ser muy extenso. Eso no debería disuadirlo de crear un plan de comunicación bien pensado, ya que proporciona una hoja de ruta de cómo se mantendrá al día a otras partes interesadas y qué se espera de ellas durante el proyecto.
• Documentar las transformaciones de datos: una vez que haya identificado sus datos de origen y los haya asignado campo por campo a los campos de destino, asegúrese de que esté suficientemente documentado. Asegúrese de haber mapeado tanto las tablas desde la fuente a los objetos en Salesforce como los campos desde la tabla fuente a los campos en Salesforce. Este documento se convierte en un documento fundamental para cualquier problema en el futuro que pueda deberse a asignaciones de campo incorrectas. También forma la base para cualquier transformación que sea necesaria y el equipo de pruebas puede utilizarla para validar las cargas de prueba.
• Ejercicio recurrente: debe quedar claro desde el principio que la migración de datos es un ejercicio recurrente. Significa que durante la fase de ejecución, será necesario realizar múltiples iteraciones para llegar a una etapa en la que el equipo se sienta cómodo apretando el trigger en el entorno de producción.
• Calidad de los datos: los problemas de calidad de los datos son un problema común en los sistemas actuales y casi ningún sistema es inmune a ellos. Al migrar datos a Salesforce, tenga en cuenta el problema de la calidad de los datos de los sistemas de origen. Esto lo ayudará a comprender cuánto esfuerzo se requerirá para limpiar los datos antes de que puedan cargarse en Salesforce. Dado que los datos se utilizan para la toma de decisiones y, entre otras cosas, para automatizar los procesos comerciales, la calidad de los datos de los sistemas de origen es de suma importancia durante esta fase de evaluación.

Fase de preparación

En esta fase, está preparando todo lo necesario para la siguiente fase, que es la fase de ejecución. Armado con el tesoro de información que se recopiló en la fase anterior, está listo para actuar y prepararse para una migración de datos exitosa.

Analicemos las mejores prácticas que se aplican a esta fase:

• Análisis: Analice cuidadosamente el resultado del ejercicio desde la fase de evaluación. Los detalles aparentemente menores que se omiten durante el análisis pueden causar muchas modificaciones en el futuro. Por ejemplo, suponiendo que un sistema heredado tiene una buena calidad de datos; Sin examinar esta suposición con los usuarios o sin muestrear los datos para validarlos, puede hacer que el ejercicio de limpieza de datos sea un esfuerzo prolongado y costoso.
• Configurar entornos y herramientas de migración de datos: en función de los requisitos recopilados hasta el momento y del análisis realizado, configure el entorno y las herramientas que se utilizarán para migrar los datos. Esto incluirá cualquier base de datos provisional, herramientas de limpieza de datos, herramientas de deduplicación, sandboxes, etc.
• Plan de prueba: este es un aspecto crítico de la fase de preparación porque desea tener una idea clara de lo que se va a probar (el alcance de la prueba y los casos de uso a probar), cómo se probará y dónde ( herramientas para las pruebas y entornos sandbox aplicables), quién realizará las pruebas y cuáles son las dependencias para las pruebas.
• Identificaciones externas: estos son sus mejores amigos, así que utilícelos para facilitar las migraciones de datos. Los ID externos proporcionan no solo un método para realizar un seguimiento de los registros del sistema de origen, sino también la capacidad de aprovechar la funcionalidad Upsert en Salesforce.
• Respete la secuencia de carga de los objetos: esto se refiere a garantizar que su objeto principal se cargue primero antes de que se pueda cargar el objeto secundario. Esto significa que si está utilizando hojas de cálculo para transformar datos como un área de preparación, debe cargar las cuentas antes de que se puedan cargar los registros de contactos o oportunidades.
• ID de codificación rígida: los ID de registro en Salesforce cambian según el entorno y, por lo tanto, debe evitar el uso de valores codificados en sus cargas. Por ejemplo, un ID de tipo de registro para una oportunidad en un entorno limitado será diferente del ID en la instancia de producción. Si debe almacenar ID, tenga un archivo de tipo de configuración al que se haga referencia durante las ejecuciones. Esto le brinda la posibilidad de actualizar la ID una vez en un lugar centralizado que luego es referenciable para todas las ejecuciones. De lo contrario, necesitaría actualizar los ID de registro para filas individuales a medida que se desplaza por cada entorno.
• Propiedad del registro: cada registro en Salesforce tiene un propietario y esto debe tenerse en cuenta al preparar la carga de datos. El sistema no migrará datos si el propietario del registro falta o no es válido. Su sistema heredado puede tener registros cuyos propietarios son ex empleados y están inactivos en el sistema fuente. Deberá asegurarse de que, si esos registros están en el ámbito de la migración, se proporcionen los nombres apropiados de los propietarios de los registros para evitar errores en los registros.
• Configuración de Salesforce: dado que la siguiente fase implicará ejecutar la migración, asegúrese de que se haya completado la configuración adecuada en Salesforce. Esto incluirá cosas como jerarquía de roles, perfiles, conjuntos de permisos, diseños de página y la definición de valores de lista de selección. Este es un paso importante. De lo contrario, cuando ejecute sus cargas de prueba, se atascará con errores causados ​​no por el proceso de migración de datos, sino por una configuración incompleta en la organización de destino.
• Actualizaciones de los sandboxes: a medida que trabaja en su proyecto, las operaciones comerciales diarias continúan, lo que significa que se deben realizar cambios continuos en forma de correcciones de fallas y mejoras, y otros proyectos se seguirán aplicando al entorno de producción. Asegúrese de tener esto en cuenta y trabaje con su equipo de Salesforce para coordinar que los cambios que se apliquen al entorno de producción también se apliquen a los entornos sandbox del proyecto. Esto evitará sorpresas más adelante debido a diferentes configuraciones y bases de código cuando esté ejecutando ejecuciones en seco en un entorno compartido, como un sandbox de UAT.
• Capacidad para deshabilitar la lógica empresarial: tiene la opción de permitir que su lógica empresarial se aplique a los datos a medida que se cargan en el destino, pero esto no se recomienda. La mejor práctica es transformar sus datos y aplicar las reglas comerciales fuera de Salesforce y cargar el conjunto de datos finalizado en Salesforce. Esto ayuda con el rendimiento y reduce las posibilidades de tener problemas relacionados con los datos. Sin embargo, con este enfoque, querrá asegurarse de que su lógica de automatización declarativa, así como la basada en código, tenga indicadores de deshabilitación incorporados que se pueden deshabilitar fácilmente en el momento de la carga. Estos indicadores deben construirse como parte del diseño cuando se introduzcan estas características, pero si no están allí, evalúe si tendría sentido incluirlos antes de ejecutar la producción.
• Vaya directamente a la fuente: siempre que sea posible, lea los datos directamente de la fuente. Esto se debe a que cada sistema intermediario tiene su propia forma de formatear y almacenar datos, y esto podría provocar la pérdida de datos mientras pasan por esta capa intermedia. Por ejemplo, cuando se exportan datos a Microsoft Excel desde el sistema de origen, los campos de texto con números pueden convertirse en campos numéricos con decimales o, a veces, los ceros a la izquierda en una columna pueden eliminarse. Esto puede provocar errores cuando los datos se cargan en Salesforce.
• Manejo de errores: cuando se extraen datos directamente de una base de datos de origen, volver a ejecutar el proceso de migración es mucho más fácil si, por ejemplo, los ID de los nuevos registros en Salesforce se vuelven a escribir en la tabla de origen. De esa manera, en la próxima ejecución, simplemente puede filtrar los registros que no tienen la columna ID de Salesforce completa y volver a ejecutarlos. En términos generales, independientemente de cuál sea la fuente de los datos, asegúrese de tener un plan para manejar los errores y la capacidad de reintentar las ejecuciones porque es inevitable que se necesiten reintentos.
• Haga una copia de seguridad de los datos: en esta fase, también querrá asegurarse de que las copias de seguridad de los datos estén en su lugar y de que los procedimientos probados ya estén en su lugar en caso de que se requiera una restauración de datos. No subestime este paso, ya que no hay nada peor que perder los datos del cliente, incluso si no es culpa suya. Asegúrese de que el cliente sea consciente y tenga los procesos de copia de seguridad adecuados, y que también haya probado esas copias de seguridad en escenarios de restauración.

Fase de ejecución

Esta es la fase se prueba todo el trabajo realizado en la fase anterior. En esta fase, habrá logrado una buena comprensión del alcance, el tipo de datos, las suposiciones y las limitaciones con las que se enfrenta. Analicemos las mejores prácticas que se pueden aplicar en esta fase.

• Comience con algo pequeño: comience con cargas pequeñas y solucione cualquier problema antes de probar cargas grandes. Esto hace que el esfuerzo requerido para volver a validar el lote sea razonable a medida que avanza y refina su código o modifica la configuración en la herramienta de migración para solucionar cualquier problema.
• Siga los pasos: A estas alturas, debería tener un documento de implementación que enumere los pasos necesarios para ejecutar las pruebas junto con notas sobre los pasos adicionales necesarios para la ejecución de producción. A medida que pruebe y modifique aún más su código y la migración también, asegúrese de que el documento esté actualizado. Siga los pasos de este documento cada vez que realice un ensayo. Esto asegurará que el documento esté actualizado y desarrolle el documento mientras se prepara para la carga completa final para UAT.
• Reglas duplicadas: desactive las reglas de administración duplicadas que haya configurado en Salesforce. Estas podrían ser funciones de Salesforce listas para usar que está utilizando o, si está utilizando una solución de terceros, reglas que han sido configuradas por esa herramienta. No desea que sus cargas generen errores debido a reglas duplicadas y cualquier inquietud de este tipo debe manejarse fuera de Salesforce antes de que los datos se carguen en él.
• Deshabilitar automatizaciones: asegúrese de haber deshabilitado todas las automatizaciones relevantes, como activadores, Process Builder y flujos de trabajo antes de ejecutar sus cargas. Nuevamente, cualquier tipo de transformación de los datos ya debería haberse realizado fuera de Salesforce antes de cargarse en el sistema.

Ejecución en producción: Ha realizado varios pruebas y las pruebas comerciales validan sus resultados en un ciclo completo de UAT. Es hora de presionar el inicio y ejecutar la migración de datos en el entorno de producción. Algunas de las mejores prácticas para esta fase incluyen las siguientes:

• Freeze de producción: asegúrese de haber comunicado a otras partes interesadas que debería haber un freeze de cambios para los metadatos en el entorno de producción. Esto es para evitar problemas debido a mejoras que no se aplicaron a los entornos de espacio aislado. No se pueden evitar las reparaciones, pero si hay alguna que no sea de alta prioridad, se recomienda posponerlas hasta que haya migrado por completo sus datos. Un freeze de cambios generalmente debe comenzar cuando se pasa al entorno de copia completa y está realizando pruebas UAT allí. Para evitar retrasar otros proyectos o equipos, intente minimizar el tiempo entre el freeze del cambio y la ejecución de producción de su migración. Debo mencionar que para migraciones más simples, es posible que no se necesiten medidas tan extensas, pero no obstante, es una buena práctica a seguir para evitar problemas inesperados.
• Copia de seguridad de los datos: haga una copia de seguridad de los datos antes de ejecutar la última producción. Idealmente, habrá horneado en un proceso de reversión si la ejecución de producción falla, pero en los casos en que eso no sea posible, debido a la herramienta o por otras razones, tiene sentido hacer una copia de seguridad de sus datos antes de cambiar cualquier dato en masa en la producción. Para ser claros, incluso si tiene un mecanismo de reversión integrado en su código, sigue siendo una buena práctica realizar una copia de seguridad de los datos de producción.
• Momento de la ejecución: Otro factor a considerar es el momento de la ejecución. Habrá calculado el tiempo total que tomará el proceso de migración cuando lo ejecutó en la zona de pruebas de copia completa. Teniendo eso en cuenta, querrá minimizar cualquier interrupción para los usuarios comerciales y reducir la cantidad de tiempo que necesitarían para no usar Salesforce. Esto no es un problema en una organización totalmente nueva, pero es una consideración crítica para las organizaciones globales que tienen usuarios distribuidos en múltiples zonas horarias. En esas situaciones, no hay un tiempo de interrupción ideal. Querrá elegir un momento en el que la interrupción sea mínima para los usuarios en las diferentes zonas horarias.
• Validación: una vez que el proceso de migración se haya completado con éxito en el entorno de producción, asegúrese de tener usuarios comerciales que puedan validar los datos cargados. Esto puede ser tan variado como probar una muestra de algunos registros para preseleccionar registros más estratégicos (es decir, las últimas cuentas) junto con otros métodos para validar esos datos. Asegúrese de que el equipo comercial esté disponible y tenga una comprensión clara de qué hacer cuando se le llame para validar la carga.