Migración de datos a Salesforce: La guía completa para Planificación, Limpieza y Cutover

La respuesta breve

La migración de datos a Salesforce suele fallar no por la herramienta, sino por un flujo de trabajo deficiente: comenzar la carga antes de entender la calidad de los datos de origen, mapear campos en un Excel sin verificar valores anómalos, y realizar la carga sin respetar las dependencias entre objetos. Un proceso adecuado se construye como un ciclo iterativo: perfilado, mapeo, limpieza, carga controlada, prueba y conciliación (Reconciliation), y solo entonces el “Cutover”.

El objetivo de este artículo es desglosar este ciclo de vida en etapas claras, con una tabla de orden de carga y una lista de verificación de conciliación que pueden utilizarse en la práctica. En la mayoría de los proyectos, la diferencia entre una migración fluida y una que implica retrabajo se define en la primera semana, en la etapa de perfilado del origen.

El trabajo de limpieza previo ahorra problemas posteriores; le recomendamos leer más al respecto en Limpieza de duplicados en Salesforce.

Perfilado del origen: Conocer los datos antes de tocarlos

Antes de escribir un solo mapeo de campo, es fundamental realizar un perfilado de los datos de origen: ¿cuántos registros hay en cada tabla?, ¿qué campos están realmente vacíos (no solo en el Schema, sino en los propios datos)?, ¿cuál es el rango de valores en campos numéricos y de fecha?, y ¿dónde hay valores de texto libre que deberían ser una lista cerrada? En un proyecto que asesoramos, el campo "Estado del cliente" contenía 47 expresiones diferentes en el origen – "Activo", "Active", "Activo " con un espacio, "A" – todas las cuales debían mapearse a un único valor en Salesforce.

Herramientas como OpenRefine, consultas SQL sencillas o incluso una tabla dinámica en Excel sobre una muestra de los datos suelen ser suficientes para la mayoría de los proyectos. El objetivo es generar un documento de perfilado que muestre: el número total de registros, el porcentaje de campos obligatorios vacíos, el número de valores únicos para cada campo categórico, y una identificación preliminar de posibles duplicados por nombre, teléfono o correo electrónico.

En esta etapa también se identifica si hay varias fuentes para información superpuesta –por ejemplo, el mismo cliente existe tanto en un CRM antiguo como en un sistema de contabilidad– y se decide qué fuente es la "Fuente de Verdad" (Source of Truth) para cada campo. Una decisión como esta debe estar documentada, no asumida, ya que afecta a todas las etapas siguientes.

Mapeo de campos: Más allá de una hoja de Excel

Un buen mapeo de campos no es solo "columna A en el origen = campo B en el destino". También incluye la dirección de la transformación: formato de fecha, conversión de unidades, división de un campo de dirección en calle/ciudad/código postal, y una solución para valores que no existen en la lista cerrada del destino. El mejor documento de mapeo que hemos visto incluía cinco columnas: campo de origen, campo de destino, tipo de transformación, regla para manejar valores nulos, y un ejemplo de entrada/salida.

Es necesario abordar por separado los campos de tipo Lookup (búsqueda) y Master-Detail (maestro-detalle): estos no contienen un valor directo, sino una referencia a otro registro, por lo que su mapeo depende de que el registro vinculado ya haya sido cargado y posea un identificador al que se pueda apuntar. Esta es la razón por la que el orden de carga (ver más adelante) y el mapeo de campos son dos caras de la misma decisión.

Puede encontrar información ampliada sobre la gestión de la calidad de los campos a lo largo del tiempo, no solo en una etapa puntual, en Calidad de datos en Salesforce.

Limpieza y duplicidades: Antes de la carga, no después

La limpieza que se realiza después de que la información ya está en un entorno de producción es exponencialmente más costosa: implica la actualización de registros en vivo, el riesgo de romper automatizaciones y procesos de aprobación, y a veces حتى (incluso) afectar informes que ya han sido distribuidos a la dirección. Por lo tanto, la fase de limpieza debe ocurrir en la capa intermedia (Staging), antes de que los datos ingresen a Salesforce.

Reglas de limpieza clave que deben definirse de antemano:

• Normalización de teléfono y correo electrónico (eliminación de espacios, uniformidad del formato internacional).
• Identificación de duplicados por combinación de campos (nombre + teléfono, o solo número de identificación fiscal para empresas).
• Reglas para la selección del registro "Master" al fusionar duplicados – por ejemplo, el registro más actualizado o el más completo.
• Manejo de valores nulos versus cadenas vacías, para evitar la creación de "duplicados simulados".

En un proyecto típico con aproximadamente 80,000 registros de clientes, una limpieza razonable identificará entre el 3% y el 8% de duplicados reales. Un número significativamente mayor sugiere que el origen mismo no fue mantenido, y justifica una conversación con los dueños del proceso de negocio antes de continuar.

IDs externos y orden de carga

Un External ID es un campo único del sistema original que también se mantiene en Salesforce, y permite la recarga (Upsert) sin crear duplicados cada vez que se ejecuta un archivo nuevamente. Sin un External ID, cada ejecución repetida de Data Loader puede crear una copia adicional del mismo registro, ya que el sistema no sabe cómo "identificar" un registro existente.

El orden de carga se determina por las dependencias entre objetos: no se puede cargar un contacto antes de que exista la cuenta a la que está asociado, y no se puede cargar un artículo de pedido antes del propio pedido.

Desviarse de este orden es uno de los fallos más comunes en proyectos de migración: un equipo que intenta "ahorrar tiempo" y carga todos los archivos en paralelo descubre miles de errores de Lookup difíciles de cribar posteriormente, porque no está claro si el error se debe a datos faltantes o a un orden de carga incorrecto.

Entornos y pruebas

La migración no se carga directamente a producción. Una estructura de entornos recomendada incluye un Sandbox dedicado a la migración (separado del Sandbox de desarrollo habitual), donde se carga el mismo volumen de datos y la misma configuración de Validation Rules y Triggers que en producción, para exponer problemas antes de que afecten a usuarios reales.

Las pruebas en esta etapa incluyen pruebas de volumen (si la carga se completa en un tiempo razonable), pruebas de errores (qué porcentaje de registros se rechaza y por qué), y pruebas de comportamiento de automatizaciones – un Flow o Trigger que se ejecuta al crear un registro podría activar el envío de un correo electrónico real a un cliente si no se desactiva temporalmente en el entorno de prueba. Olvidar este detalle causó en un proyecto el envío de miles de correos electrónicos de "bienvenida" duplicados a clientes existentes.

Dry Run: Ejecución de prueba completa

El Dry Run es una ejecución completa del proceso de carga en condiciones lo más cercanas posible a la producción – el mismo volumen, los mismos archivos, el mismo orden – pero en un Sandbox. El objetivo es medir dos cosas: el tiempo de ejecución real (para planificar la ventana de "Cutover" de manera realista) y el porcentaje de errores en cada etapa.

Se recomienda realizar al menos dos ejecuciones completas de Dry Run: la primera expone la mayoría de los problemas, la segunda verifica que las correcciones los hayan resuelto y no hayan creado un nuevo problema. Si una segunda ejecución aún arroja más del 1%-2% de errores en objetos críticos, a menudo es preferible posponer la fecha del Cutover en lugar de comprometer la calidad.

Cutover y conciliación de datos (Reconciliation)

El Cutover es la ventana real en la que el sistema antiguo se “congela” (Freeze), se carga la información más actualizada en Salesforce y los usuarios comienzan a trabajar en el nuevo sistema. El éxito en esta fase se mide no solo por "si la carga finalizó", sino por la conciliación (Reconciliation), una comparación sistemática entre el origen y el destino.

Lista de verificación para la conciliación que conviene ejecutar al finalizar cada Cutover:

• ☐ El recuento de registros es idéntico (o la discrepancia es conocida y explicada) en cada objeto principal.
• ☐ Los totales de campos financieros (por ejemplo, el valor total de oportunidades abiertas) coinciden entre las fuentes.
• ☐ Se ha revisado manualmente, campo por campo, una muestra aleatoria de 30-50 registros.
• ☐ Se han verificado las relaciones: ¿cada Contact tiene una Account válida?, ¿cada Opportunity Line Item tiene una oportunidad?
• ☐ Se han revisado los registros "huérfanos": aquellos cargados sin una referencia válida.
• ☐ Se ha comparado el recuento de duplicados antes y después con el objetivo establecido en la fase de limpieza.
• ☐ El propietario del proceso de negocio ha confirmado que una muestra de su información es correcta.

Las discrepancias comunes en la conciliación incluyen: recuentos de registros coincidentes pero valores totales incorrectos porque un campo numérico se cargó en un formato erróneo; o relaciones faltantes porque los Lookups se cargaron por valor de texto y no por External ID. La documentación completa del proceso de conciliación, incluyendo un ejemplo de "baseline" (línea de base), se encuentra también en Salesforce Master Data Management.

Correcciones después de Go Live

Incluso un Cutover exitoso deja una "cola" de correcciones: registros individuales que fueron rechazados en la carga, usuarios que reportan datos faltantes y discrepancias que se descubren solo cuando los usuarios reales trabajan con el sistema y no solo lo prueban. Se debe asignar de antemano un período de dos a cuatro semanas para correcciones focalizadas, con un informe de excepciones diario en la primera semana y semanal a partir de entonces.

Es importante distinguir entre una corrección puntual (un registro individual que se actualizó manualmente) y una corrección sistémica (un error de mapeo que se repite en miles de registros y requiere una corrección en la propia herramienta de carga y una nueva ejecución). Mezclar ambos hace que los equipos corrijan manualmente un problema que en realidad es sistemático, perdiendo mucho tiempo.

Escenario organizacional de ejemplo

Una empresa de distribución con aproximadamente 120,000 clientes en un CRM antiguo y otra lista de clientes separada en el sistema de contabilidad, solicitó migrar ambas fuentes a un único Salesforce. Un perfilado inicial reveló que el 11% de los clientes aparecían en ambas fuentes con detalles de contacto diferentes, y el campo "Sector de actividad" contenía 340 valores de texto libre que debían ser unas 25 categorías.

El equipo construyó un mapeo de campos detallado, estableció una regla de fusión basada en la combinación de NIF y teléfono, y definió el sistema de contabilidad como "Fuente de Verdad" (Source of Truth) para los detalles de facturación y el CRM antiguo como "Fuente de Verdad" para los detalles de contacto. Una primera ejecución de Dry Run reveló que el 4% de los registros eran rechazados debido a un formato de fecha incorrecto – una corrección que se tuvo en cuenta en la segunda ejecución. El Cutover se realizó durante un fin de semana, con una conciliación completa el lunes por la mañana antes de abrir el sistema a los usuarios.

El resultado: menos del 0.3% de los registros requirieron corrección manual después del Go Live, en comparación con una estimación inicial del equipo que esperaba alrededor del 5% de excepciones. La diferencia se debió casi en su totalidad a las dos ejecuciones de Dry Run realizadas antes de la fecha oficial.

Riesgos comunes y acciones preventivas

A nivel de gestión de una migración de datos a Salesforce, esta tabla de riesgos es solo un punto de partida. Una ampliación sobre la gestión continua de la calidad, incluida la diferencia entre la limpieza puntual y el gobierno de datos continuo, se encuentra en Data 360 Zero Copy.

Cómo se mide el éxito

Para la mayoría de los proyectos, entre tres y cinco métricas son suficientes para la primera versión. Una buena métrica se puede calcular antes y después del cambio, se relaciona con el propietario de un proceso de negocio y no puede mejorarse artificialmente mediante la entrada parcial de datos. Cuando no existe una línea de base documentada del sistema antiguo, es recomendable invertir uno o dos días en medir el estado actual antes de informar sobre una mejora.

Checklist antes de Go Live

• ☐ El perfilado de origen se ha realizado e incluye porcentajes de campos vacíos y duplicados.
• ☐ El documento de mapeo de campos está completo, incluyendo transformaciones y manejo de valores nulos.
• ☐ External ID está definido para cada objeto que requiere recarga.
• ☐ El orden de carga está documentado y acordado por el equipo técnico.
• ☐ Se han realizado dos Dry Runs y los errores se han reducido por debajo del umbral establecido.
• ☐ Un escenario de "Rollback" está escrito para el caso de que el Cutover falle.
• ☐ El "Checklist" de conciliación está preparado y la persona responsable de ejecutarlo se conoce de antemano.
• ☐ Se ha asignado una ventana para correcciones después del Go Live en el cronograma.
• ☐ Las automatizaciones que podrían enviar comunicaciones a los clientes se han revisado y están desactivadas durante la carga.
• ☐ El propietario del proceso de negocio ha aprobado una muestra final de datos.

Notas profundas de implementación y mantenimiento

Nota del arquitecto: La migración no es un evento único

Incluso después de un Go Live exitoso, los cambios en el sistema de origen (si sigue funcionando temporalmente en paralelo) o las correcciones manuales crean desviaciones en los datos. Por ello, es importante mantener un informe de conciliación regular – semanal en el primer mes, mensual después – que compare una muestra de datos entre los informes antiguos y nuevos e identifique desviaciones tempranamente. Un proyecto que trata la migración como una línea de meta pasa por alto que la calidad de los datos es un proceso continuo.

Desde una perspectiva gerencial, la verdadera prueba de una migración de datos a Salesforce no es solo si los registros se cargaron, sino si los gerentes de Datos, CRM y proyectos pueden confiar en los informes al día siguiente sin verificar manualmente cada número. Las organizaciones que desean acompañamiento profesional para un proceso así pueden recurrir a Servicios de Integraciones y Datos, que acompaña tanto la fase de planificación como la ventana de Cutover.

Fuentes profesionales

• Salesforce Data 360 — https://www.salesforce.com/data/
• Salesforce Data 360 Architecture — https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html
• HPI Pro – Integraciones y Datos — https://hpi.pro/integrations-data