La migración es, ante todo, un proyecto de calidad
También en 19 idiomas
English · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Українська · Español (México) · Français (Canada) · Deutsch (Schweiz)
Módulo 1 de 5 del capítulo Migración y sincronización, capítulo 10 del curso Data Architect. Cada módulo se sostiene por sí solo. Anterior: el capítulo anterior, Integración y movimiento de datos · Siguiente: Cargar con volumen
La pregunta que responde este módulo: ¿qué debería pasarles a los datos antes de empezar a cargarlos en Salesforce?
Un proyecto de migración puede engañarte. Tienes datos aquí, los necesitas allí, así que alguien empieza a hablar de Data Loader, la Bulk API, archivos CSV, tamaños de lote y orden de carga. Esas cosas importan. No es por donde empiezo. Mi primera pregunta es: ¿qué es exactamente lo que estamos a punto de mover? Si el origen contiene clientes duplicados, direcciones no válidas, valores obsoletos, relaciones rotas y quince años de datos que nadie necesita, Salesforce se convertirá encantado en el nuevo hogar de todo eso. Cargar más rápido no lo arregla. La migración es, ante todo, un proyecto de calidad.
Empieza por el dibujo
Sección titulada «Empieza por el dibujo »Este es el panorama de Steve Trucking del Checkpoint 1, el fin de semana en que se retira RouteDesk. RouteDesk es la herramienta de escritorio de despacho que usaban los coordinadores dentro de cada centro de distribución para convertir los manifiestos en rutas. Guarda ocho años de historial de entregas, unos 5 millones de entregas, y la calidad varía según el centro de distribución. En el Checkpoint 1 decidimos retirarla, y dejamos una pregunta abierta: ¿qué entra en la organización, si es que entra algo? Esa es una decisión de migración, y este es el capítulo para ella.
Una flecha nueva. Se ejecuta una vez y luego desaparece.
Una migración es una flecha en el panorama como cualquier otra. Se aplica todo lo que el capítulo 9 le pedía a una flecha: qué se mueve, cuánto, con qué clave, quién demuestra que llegó. La diferencia es que esta flecha tiene un final. Cuando termina, RouteDesk se apaga y la flecha desaparece del dibujo. Eso hace fácil precipitarse, porque “solo lo hacemos una vez”. Pero los datos que lleva se quedan en Salesforce durante años.
Mover datos malos más rápido no es un éxito
Sección titulada «Mover datos malos más rápido no es un éxito »El sistema heredado tiene 500.000 registros de clientes, y migramos 500.000 registros de clientes. ¿Tuvimos éxito? Quizá. ¿Y si 40.000 son duplicados, 75.000 no han tenido actividad en diez años, miles tienen códigos de estado no válidos, algunos no tienen un identificador utilizable, algunos hijos apuntan a padres que ya no existen y algunos campos significan cosas distintas según cuándo se creó el registro? El informe puede seguir diciendo 500.000 en el origen, 500.000 en el destino, 100 por ciento cargado, y el proyecto puede seguir siendo un fracaso. La integridad importa, pero la integridad por sí sola no demuestra calidad.
Así que, antes de diseñar la carga, quiero entender el origen. ¿Qué datos existen, y qué significan? ¿Qué antigüedad tienen, qué fiabilidad, qué campos se usan de verdad, qué valores son válidos, qué relaciones existen, en qué identificadores puedo confiar? ¿Qué debería sobrevivir a la migración, y qué no? Aquí es donde vencen los capítulos anteriores: el capítulo 4 nos enseñó el panorama de la empresa, el capítulo 5 que la calidad hay que diseñarla, el capítulo 6 la identidad y la autoridad. La migración lo aplica todo a un conjunto de datos existente. No es solo mover filas. Es decidir qué partes del pasado merecen formar parte de la arquitectura futura.
Migrar, archivar o descartar, y saber por qué
Sección titulada «Migrar, archivar o descartar, y saber por qué »Un inventario de migración necesita al menos tres respuestas: migrar, archivar o descartar según la política. Un detalle transaccional de hace cinco años puede tener que conservarse por cumplimiento sin vivir en el modelo de datos activo; unos datos temporales obsoletos pueden no tener ni requisito de retención ni valor; el historial puede pertenecer a un archivo en el que se pueda buscar. El principio de ciclo de vida del capítulo 7 era “diseña la salida”, y la migración es el momento perfecto para aplicarlo. No arrastres cada registro solo porque está ahí.
Así que acércate a RouteDesk y desmóntalo, una clase de datos cada vez.
Cada clase de datos recibe una decisión, un lugar y un motivo.
Las entregas aún no realizadas tienen que entrar: los manifiestos llegan con uno o dos días de antelación, así que el fin de semana del corte RouteDesk guarda unos dos días de trabajo, unas 6.400 entregas, y los equipos las necesitan el lunes por la mañana. El historial reciente entra por las reclamaciones. Una reclamación por daños es un caso en Salesforce, y el agente que la gestiona necesita la entrega que hay detrás. Así que también entran las entregas que siguen dentro del plazo de reclamación. Steve Trucking acepta reclamaciones durante 60 días después de una entrega, así que son unas 190.000 órdenes de trabajo más. Si el negocio hubiera dicho 30 días, sería la mitad. El plazo es una cifra del negocio, no nuestra.
Los otros 4,8 millones de entregas van a Snowflake, adonde el Checkpoint 1 ya envía el historial de estados, guardados por la clave del socio para que una reclamación sobre una entrega antigua pueda seguir encontrándola, y para que los informes a cinco años de la dirección sigan funcionando. No pertenecen al núcleo operativo: eso convertiría Salesforce en la residencia de jubilación de RouteDesk, y el capítulo 7 mostró lo que cuestan las órdenes de trabajo con volumen. ¿Y los planes de ruta y los borradores de los coordinadores? Ocho años de planes de ayer no tienen valor una vez hechas las entregas. Pero eso no lo decido yo solo.
El error opuesto es “no necesitamos lo antiguo”. ¿Quién lo decidió? ¿Legal, finanzas, operaciones, servicio, cumplimiento? El arquitecto de datos no debería inventarse la política de conservación durante una migración; traducimos el requisito de negocio y normativo a arquitectura. Antes de excluir datos, establece si deben conservarse, durante cuánto tiempo, dónde, quién necesita acceso y si deben sobrevivir sus relaciones y sus identificadores de origen. Ocho años de nombres, direcciones y números de teléfono de destinatarios es exactamente ese tipo de pregunta: archivarlos no es lo mismo que conservarlos para siempre. El objetivo no es migrar menos. Es saber por qué se mueve, o no, cada clase de datos.
Conocimiento para el examen. Migra lo que el sistema nuevo necesita para funcionar, no todo lo que guardaba el antiguo. Espera un escenario con años de historial heredado: la respuesta suele ser migrar los registros activos y recientes y archivar el resto fuera de Salesforce, donde siga siendo accesible, con la decisión de conservación tomada por el negocio, no por el equipo de migración.
Dónde ocurre la preparación
Sección titulada «Dónde ocurre la preparación »Antes de los pasos, el lugar. Toda esta preparación ocurre fuera de Salesforce, en una base de datos de trabajo propia: Postgres, SQL Server, Oracle, MySQL, incluso SQLite para un trabajo pequeño, lo que conozca el equipo. No en Salesforce, y no en una hoja de cálculo que va de correo en correo. Lo llamo el almacén de datos de preparación, o el almacén de preparación para abreviar. Está en medio: el origen lo alimenta, y él alimenta a Salesforce.
El almacén de datos de preparación está en medio. Cada paso de este módulo ocurre dentro de él.
La extracción llega ahí en bruto. La estandarización, la limpieza, el enriquecimiento, la desduplicación y la validación se ejecutan todas ahí, como código. La cuarentena es una tabla, los recuentos son consultas, y todo puede volver a ejecutarse desde el principio. Algunas herramientas conectan una base de datos así directamente con Salesforce, copiando los datos hacia abajo y enviando los cambios de vuelta; otras exportan archivos para un cargador de datos. Hay muchas formas de cargar datos. El principio no cambia: prepáralos fuera y luego carga el resultado.
Y guarda más que el origen. Trae también las partes relevantes de la organización de destino. ¿Por qué? Porque la desduplicación tiene que comparar con lo que ya está en Salesforce, y cuando el superviviente de una fusión es un registro que ya está allí, los hijos nuevos necesitan su clave para vincularse a él. No puedes decidir la fusión sin tener los dos lados delante. Para RouteDesk, el almacén de preparación guarda la extracción de RouteDesk y una copia de lo que Salesforce ya tiene: las cuentas de los socios minoristas, los productos y los territorios de servicio, los casos de reclamación con sus referencias de entrega y las órdenes de trabajo que la nueva integración ya ha creado, porque los socios no dejan de enviar manifiestos por nuestro fin de semana del corte.
Luego practicas. Ejecuta la preparación, carga un sandbox, concilia, encuentra la regla que estaba mal, corrígela, vuelve a ejecutarlo todo. Para cuando llegamos a producción, la preparación se ha ejecutado muchas veces, y es aburrida. Ese es el objetivo.
Mi orden: estandarizar, limpiar, enriquecer, eliminar duplicados, validar
Sección titulada «Mi orden: estandarizar, limpiar, enriquecer, eliminar duplicados, validar »Cuando preparo datos para una migración, trabajo en este orden, y el orden importa. Los cinco pasos ocurren en el almacén de datos de preparación.
Estandarizar. Lleva los valores equivalentes a una sola forma. Un origen tiene CA, California y Calif.; otro tiene US, USA y United States. Una empresa llega como Steve Plumbing, Steve's Plumbing y Steve's Plumbing LLC. Los números de teléfono llegan como 5555550142, (555) 555-0142 y +1 555 555 0142. Antes de comparar registros o aplicar reglas de emparejamiento, necesitamos saber qué diferencias son de formato y cuáles tienen significado.
Los nombres son la trampa clásica. Tuve un sistema con el nombre y el apellido en un solo campo, y el contacto de Salesforce los necesita por separado. “Daniel Reyes” se separa fácilmente. Luego te encuentras con “Mr. Daniel Reyes”, “Daniel Reyes PhD”, “Daniel Reyes III” y nombres con dos apellidos, como Roberto González Suárez, donde González no es un segundo nombre: sepáralo mal y tienes un problema. Construye los patrones (dos palabras, tres palabras, un tratamiento, un sufijo), ejecuta las separaciones y haz que el cliente valide los resultados.
Limpiar. Ocúpate de lo que está mal, es inutilizable u obsoleto: códigos no válidos, fechas imposibles, errores ortográficos, valores de relleno, campos con datos que no corresponden a su significado. Mapea los valores de las listas de selección a propósito: un estado de prospecto heredado Cold podría convertirse en Closed en el destino. Cuando la lista es larga (he visto 200 valores), construye una tabla de transformación y haz que el negocio rellene el destino para cada valor de origen. Salesforce valida las listas de selección de forma estricta, así que detéctalos antes de que lleguen, y no esperes a que las reglas de validación te digan qué contiene tu origen.
El “la calidad varía según el centro de distribución” de RouteDesk aparece justo aquí. Cada centro de distribución creó sus propios códigos de estado durante ocho años, así que el mismo resultado llega escrito de nueve maneras. La tabla de transformación asigna cada uno de ellos a los valores de estado de la orden de trabajo en Salesforce:
| Centro de distribución | RouteDesk dice | Estado de la orden de trabajo |
|---|---|---|
| CD 1 | DLV | Completed |
| CD 4 | Delivered - OK | Completed |
| CD 7 | DONE/INST | Completed (la instalación está en su partida) |
| CD 1 | NH | Cannot Complete (no había nadie en casa) |
| CD 4 | Refused | Cannot Complete |
| CD 7 | CXL | Canceled |
Las dos columnas de la izquierda salen del perfilado de la extracción; la columna de la derecha la pone el negocio, no nosotros. Completed, Cannot Complete y Canceled son tres de los valores de estado estándar de la orden de trabajo (WorkOrder (se abre en una pestaña nueva), Object Reference, Winter ‘27, consultado el 2026-10-27). Fíjate en la tercera fila: un código de RouteDesk llevaba dos hechos, la entrega y la instalación, y el modelo de destino los mantiene separados.
Enriquecer. A veces la información que falta se puede añadir de forma fiable: una dirección normalizada, un código postal a partir de la ciudad y el estado, un condado, una geolocalización, una correspondencia de un código heredado con la nueva taxonomía de la empresa, un identificador de empresa. El enriquecimiento necesita procedencia. Si añadimos o cambiamos información, quiero saber de dónde salió y por qué confío en ella. Algunas de las entregas más antiguas de RouteDesk no nombran al socio minorista en absoluto, porque cada centro de distribución atendía a un socio y todo el mundo lo sabía. El centro de distribución y el formato del número de pedido nos dicen qué socio era. Eso es enriquecimiento a partir de una regla que podemos mostrar, no una suposición.
Eliminar duplicados. Luego encuentra los registros que representan la misma cosa del mundo real. ¿Por qué no empezar por aquí? Porque emparejar datos sucios es más difícil: Steve's Plumbing y STEVES PLUMBING LLC son mucho más fáciles de comparar después de estandarizar. Elimina duplicados dentro de los datos entrantes y luego frente a lo que ya está en Salesforce. La regla del capítulo 6 sigue aplicándose: fusionar es destructivo; vincular no. No colapses registros porque una puntuación difusa parezca convincente.
Validar. Por último, prueba los datos transformados contra el destino: la información obligatoria presente, los valores de referencia válidos, las relaciones resolubles, las claves únicas donde deben serlo, los valores encajando en el modelo, las reglas de autoridad preservadas. Solo entonces quiero hablar en serio de la carga. Y no esperes que la herramienta de importación lo detecte todo. El propio proyecto de Trailhead de Salesforce sobre el importador de NPSP lo deja claro: detecta los valores de lista de selección no válidos y los campos obligatorios que faltan, pero si una hoja de cálculo convirtió un código postal como 02134 en el número 2134, el importador carga los cuatro dígitos (Perform an Import Dry Run (se abre en una pestaña nueva), Trailhead, consultado el 2026-10-27). Es una razón más para que la preparación viva en una base de datos con columnas con tipo, no en una hoja de cálculo.
Cinco pasos, en orden. Un registro que falla uno va a algún lugar visible, con su motivo.
Conocimiento para el examen. La calidad de los datos se arregla antes de la carga, no después. Conoce los pasos de preparación (estandarizar, limpiar, enriquecer, desduplicar, validar) y por qué importa el orden: no puedes emparejar registros de forma fiable hasta que sus valores tienen una sola forma. Los valores de las listas de selección se asignan con una tabla de transformación que firma el negocio, porque Salesforce rechaza los valores que no tiene una lista de selección restringida.
Limpia antes de mover
Sección titulada «Limpia antes de mover »La tentación es “metamos primero todo en Salesforce y ya lo limpiaremos después”. No me gusta como opción por defecto. En cuanto los datos malos están en producción, participan en producción: los usuarios los ven, la automatización, los informes, las integraciones y los agentes los ven, los duplicados empiezan a acumular registros relacionados y la limpieza se vuelve más difícil. Donde sea práctico, mejora los datos antes de que entren en el destino. No hay que arreglar cada imperfección histórica; es una decisión de coste y beneficio. Pero “ya lo limpiaremos más adelante” no es una estrategia de migración. Es deuda técnica con fecha de lanzamiento.
Y no todos los registros merecen el mismo esfuerzo. Un cliente activo con pedidos abiertos, casos abiertos, contratos vigentes y relaciones de facturación es distinto de uno que compró algo una vez hace nueve años. Puede que haya que conservar los dos. Para los datos críticos y activos puedo exigir una validación más estricta, más enriquecimiento, una revisión de duplicados más atenta y una conciliación detallada; para el historial de poco valor, conservar la trazabilidad puede importar más que dejar cada registro perfecto. La arquitectura consiste en parte en decidir dónde crea valor el esfuerzo de calidad. Para RouteDesk, las 6.400 entregas a las que irán los equipos el lunes reciben las comprobaciones más estrictas. Los 4,8 millones que van al archivo necesitan bien sus claves y sus fechas; nadie va a corregir ocho años de erratas en las notas de entrega.
Conserva la identidad del origen, y carga por claves
Sección titulada «Conserva la identidad del origen, y carga por claves »Uno de los errores más fáciles es perder la capacidad de rastrear un registro de Salesforce hasta su origen. Si el cliente heredado CUST-847291 se convierte en la cuenta 001…, sigo queriendo saber que vino de CUST-847291, para la conciliación, la resolución de problemas, las recargas, la auditoría, el emparejamiento de los registros hijos, el análisis de una reversión y las preguntas que llegan después del lanzamiento. El nuevo ID de Salesforce importa dentro de Salesforce; no borra la identidad del origen. Es el principio del External ID del capítulo 9. La migración y la integración se encuentran en la identidad.
En Steve Trucking se encuentran en un solo campo. Cada orden de trabajo ya lleva la clave del socio, Partner_Delivery_Key__c, un External ID marcado como único, con valores como REDROCK-8472914-1 (capítulo 9, módulo 2). RouteDesk guardaba el número de pedido del socio en cada entrega, así que la migración construye la misma clave y hace upsert con ella, exactamente como la integración. Eso importa el fin de semana del corte: si Redrock reenvía un manifiesto para el martes después de que hayamos cargado el martes desde RouteDesk, la integración encuentra la orden de trabajo migrada y la actualiza en lugar de crear una segunda. El propio número de entrega de RouteDesk viene también, en un campo normal, para que cualquiera pueda rastrear una orden de trabajo hasta el registro del que procede.
Así que no reconstruyas las relaciones por nombre (“busca la cuenta cuyo Name es Acme Distribution”). Si el contacto heredado lleva Legacy_Account_ID = CUST-847291 y la cuenta de Salesforce lleva ese identificador como External ID, la relación se reconstruye de forma determinista. Bulk API lo hace en el propio archivo de carga: un encabezado de columna como WorkOrder.Partner_Delivery_Key__c dice “encuentra a mi padre por este campo indexado”, y Salesforce busca el ID del padre por ti (Relationship Fields in a Header Row (se abre en una pestaña nueva), Bulk API 2.0 and Bulk API Developer Guide, consultado el 2026-10-27). Las claves convierten “creo que este hijo va aquí” en “sé de qué padre procede”, y eso importa más a medida que crece el Número de Ceros.
Las relaciones también crean una secuencia. Si los contactos hacen referencia a cuentas, las cuentas deben existir primero; si las partidas hacen referencia a pedidos y productos, esos van antes. Así que una migración no es una carga gigante. Son los datos de referencia, los padres, los hijos, las uniones y luego el historial dependiente, en un orden que dicta el modelo de datos de destino. Es una razón más para que el arquitecto de datos participe en la planificación de la migración: el modelo nos dice cómo hay que montar la migración. Este es el trabajo abierto de RouteDesk, sobre el modelo del Checkpoint 1.
Oleada 1: aquello a lo que apuntarán las órdenes de trabajo tiene que existir primero. La mayor parte ya existe.
Oleada 2: las órdenes de trabajo, con upsert por la clave del socio.
Oleada 3: los hijos, cada uno encontrando su orden de trabajo por la misma clave.
Oleada 4: los casos de reclamación que ya están en Salesforce reciben su vínculo con la entrega. El modelo fija el orden.
Conocimiento para el examen. Guarda la clave de cada registro heredado en un campo External ID, carga los padres antes que los hijos y deja que cada hijo encuentre a su padre por esa clave: un upsert por el External ID, y una columna de relación en el archivo de carga (
Parent.External_Id__c) en lugar de buscar los ID de Salesforce. Así las recargas actualizan en lugar de duplicar, y cada registro se puede rastrear hasta su origen.
Los registros fusionados necesitan una estrategia para los hijos
Sección titulada «Los registros fusionados necesitan una estrategia para los hijos »Este es el problema que la gente subestima. El análisis descubre que los clientes heredados A, B y C son el mismo cliente, así que el destino recibe una sola cuenta. Bien. Pero A tiene 12 casos, B tiene 4 pedidos y C tiene 3 contactos. Fusiona los padres conceptualmente sin rediseñar el mapeo de los hijos y habrás resuelto el padre y roto las relaciones. Cada decisión de eliminación de duplicados necesita una estrategia para los hijos.
RouteDesk tiene su propia versión. Cuando un socio revisaba un manifiesto el mismo día, un coordinador a veces volvía a introducir la entrega en lugar de editarla. Ahora RouteDesk tiene dos entregas con el mismo número de pedido del socio: una con la franja antigua y dos paradas, otra con la franja nueva y las notas del equipo. Salesforce tendrá una sola orden de trabajo, porque la clave del socio es única. ¿Qué franja gana, y qué pasa con las paradas y las notas de la otra?
Primero, los campos: cuando dos registros coinciden, ¿qué valores ganan? Un vacío frente a un valor es fácil. Un conflicto no: ¿Steven o Stephen?, ¿el correo de Salesforce o el de la carga? Elige un superviviente y decide campo a campo, y luego pon casos de ejemplo delante del negocio pronto, para que sus huellas estén en las decisiones.
Luego los hijos. Veo tres opciones: añadir los hijos al superviviente, no cargar los hijos del registro fusionado, o cargar el registro fusionado como inactivo, vinculado al superviviente, con sus hijos conservados en él.
Tres maneras, ninguna gratis. Fíjate en la tercera en RouteDesk: el duplicado inactivo no puede reutilizar la clave del socio, porque ya la tiene el superviviente, así que necesita una clave propia.
Elijas la que elijas, ocurre en el almacén de preparación, antes de cargar nada. Ahí es donde se elige el superviviente, a veces un registro que ya está en Salesforce, traído con su clave. Ahí es donde cada hijo recibe la clave del padre al que apuntará. Y ahí es donde el registro fusionado conserva sus hijos, los entrega o se deja fuera. Salesforce recibe el resultado de la fusión, no el trabajo de hacerla.
¿Cómo elijo? Depende de lo críticos que sean los datos y de si necesitamos trazabilidad hasta lo que se cargó. Y sopesa el riesgo frente al beneficio de fusionar en absoluto. Unir el historial de compras de dos personas equivocadas en una lista de clientes minoristas es una molestia; mostrar la medicación de un paciente en el registro de otro es una infracción grave. Cuanto más alto es lo que está en juego en un emparejamiento erróneo, más conservadora es la fusión. Decidas lo que decidas, ¿se puede seguir rastreando cada hijo hasta su origen? Eliminar duplicados en una migración no es “ejecutar el emparejamiento de duplicados en las cuentas”. Importa todo el grafo de relaciones.
He estado al otro lado de esto. Un minorista al que le compraba desde mis tiempos de universidad estaba migrando sus datos de clientes, y cuando miramos, Steve Simpson aparecía con media docena de correos y direcciones postales: mi dirección de la universidad, la casa que alquilé, los sitios posteriores. ¿Deberíamos fusionarlos? Hay otros Steve Simpson por ahí. El negocio decidió que unir mi historial antiguo no compensaba el riesgo de fusionarme con el Steve Simpson equivocado. Esa es la pregunta que tiene que responder cada fusión: ¿cuál es el beneficio de juntar los datos, y cuál es el riesgo de elegir a las personas equivocadas?
Conocimiento para el examen. Desduplica antes de la carga, dentro de los datos entrantes y frente a lo que ya está en Salesforce, con reglas de emparejamiento y un superviviente elegido campo a campo. Espera la pregunta siguiente: ¿qué pasa con los registros hijos del registro fusionado? Volver a asignarlos al superviviente, dejarlos fuera (y archivarlos) o conservarlos en un registro inactivo vinculado. Cada opción tiene un coste.
Transformaciones repetibles, origen en bruto conservado
Sección titulada «Transformaciones repetibles, origen en bruto conservado »El estado heredado A pasa a ser Active, I pasa a Inactive, S pasa a Suspended. ¿Dónde vive ese mapeo? No en la memoria de alguien, ni en una fórmula de Excel copiada de forma distinta en tres archivos, ni como un paso manual el viernes por la noche. Si recargamos mañana, deberíamos obtener el mismo resultado, así que los mapeos, las reglas de estandarización y limpieza, las transformaciones, las decisiones de eliminación de duplicados y la generación de claves tienen que ser reproducibles. El proceso de migración es código, aunque algunas piezas no estén escritas literalmente en un lenguaje de programación.
Y no destruyas el punto de partida. Guarda la extracción original en tablas en bruto, exactamente como salió, y no las cambies nunca. Cada paso escribe su resultado en una nueva tabla intermedia: estandarizada, limpia, desduplicada, lista para cargar. Cuando algo parece mal, quiero saber si ya estaba mal en el origen, si lo cambió nuestra transformación, si lo cambió la carga o si lo cambió después la automatización de Salesforce, y con todas las tablas conservadas puedo recorrerlas hacia atrás y averiguarlo. Sobrescribe tu única copia del origen mientras la limpias y pierdes la evidencia.
Aprendí lo mucho que compensa esto en una migración de soporte. Una empresa trasladaba su servicio de soporte de Zendesk a Salesforce, y los tickets de Zendesk se parecían mucho a los casos de Salesforce, pero no del todo. Así que cargué cada exportación de Zendesk en una base de datos SQL como tablas en bruto, una por cada estructura de Zendesk: organizaciones, usuarios, tickets, campos personalizados, comentarios, archivos adjuntos. Luego construí tablas intermedias que se acercaban cada vez más a la estructura de Salesforce, con las correspondencias de campos y de listas de selección guardadas como tablas propias. Después cargué Salesforce desde esas tablas y traje de vuelta los ID de Salesforce. Al final cada fila tenía tres cosas: su clave original de Zendesk, las transformaciones que se le habían aplicado, que nunca eran de un solo sentido, y su clave de Salesforce. Eso es lo que me permitió hacer cargas parciales y recargas siempre que lo necesité.
Este es el mismo diseño para RouteDesk, paso a paso.
Extraer: una tabla en bruto por cada estructura de RouteDesk, cada fila con su clave de RouteDesk. Estas tablas no cambian nunca.
Generar: tablas nuevas con forma de Salesforce, construidas a partir de las tablas en bruto con las tablas de correspondencia. Las tablas en bruto siguen ahí.
Cargar: las órdenes de trabajo con upsert por la clave del socio, y luego sus hijos.
Claves de vuelta: cada ID de Salesforce se escribe en su fila. Ahora cada fila sabe de dónde vino, qué se le hizo y dónde acabó.
Así que ninguna transformación puede perder fidelidad. Si un paso descarta información (recorta una nota, elimina un código que no reconoció, se queda con uno de dos valores contradictorios sin decir cuál), no puedo rastrear hacia atrás a través de él, y no puedo repetir la ejecución y obtener la misma respuesta. Conserva las tablas en bruto, conserva las tablas intermedias, conserva lo que envió cada carga y lo que volvió. Entonces puedes volver a ejecutarlo todo desde la extracción en bruto en cualquier momento, y tienes el historial de cada carga. Esta es la versión de la migración del linaje: conserva de dónde vinieron los datos y qué les hiciste.
A veces la preparación está dentro de Salesforce
Sección titulada «A veces la preparación está dentro de Salesforce »El almacén de preparación no es el único lugar donde preparar. En unos pocos casos especiales, la última parada antes de los objetos reales es un objeto personalizado sencillo dentro de Salesforce: una fila plana por registro de origen, sin automatización, cargado rápido. Luego un proceso por lotes recorre las filas y construye los registros reales. Lo he usado cuando la propia lógica de Salesforce tenía que crear los registros y era demasiado lenta para cargar a través de ella: un proceso de programación que tardaba unos segundos por cita. El módulo 3 vuelve sobre ese caso.
Salesforce usa el mismo patrón en sus propios productos, y vale la pena aprender de él. Nonprofit Success Pack carga primero una hoja de cálculo en su objeto NPSP Data Import. Una ejecución de prueba busca coincidencias sin crear nada. Luego el importador crea las cuentas, los contactos y las donaciones, y escribe el ID de cada registro nuevo en la fila de la que procede (How the Import Process Works (se abre en una pestaña nueva), Salesforce Help, consultado el 2026-10-27). Es una referencia, no una regla: preparar dentro de Salesforce es el caso especial, no la forma de cargarlo todo.
Para RouteDesk, un traslado de una sola vez con mucha limpieza y fusión, el almacén de preparación fuera de Salesforce hace el trabajo, y la carga envía el resultado.
Los registros malos necesitan un lugar adonde ir
Sección titulada «Los registros malos necesitan un lugar adonde ir »De 500.000 registros, 497.800 superan la validación y 2.200 no. ¿Los descartamos en silencio? No. ¿Metemos basura a la fuerza en los campos obligatorios? No. ¿Detenemos el proyecto hasta que cada registro histórico sea perfecto? Probablemente no. Quiero una cuarentena y un camino de corrección que registren qué registro de origen falló, por qué, qué regla lo rechazó, si hay que corregirlo antes del corte, quién es responsable de la decisión y si puede aplazarse. Ahora las excepciones son trabajo de arquitectura visible en lugar de pérdida de datos oculta.
Antes de llamar malo a un registro, mira la regla que lo rechazó. A veces el registro está bien y la regla está mal. El marco Well-Architected de Salesforce lo dice claramente: “las decisiones de arquitectura de datos determinan qué poblaciones se vuelven visibles, e invisibles”, y un correo electrónico obligatorio “excluye a las poblaciones que no tienen acceso fiable a internet ni direcciones de correo electrónico personales” (Fairness (se abre en una pestaña nueva), consultado el 2026-10-27). RouteDesk tiene miles de entregas en las que el destinatario solo dio un número de teléfono. Si la nueva orden de trabajo exige un correo electrónico, esos no son registros malos. Son personas reales a las que la regla volvería invisibles. Arregla la regla, no a la persona.
Luego demuestra la transformación antes de la carga. ¿Con cuántos registros de origen empezamos, cuántos excluimos a propósito, cuántos duplicados se consolidaron, cuántos están listos, cuántos en cuarentena, cuántas relaciones padre-hijo se resuelven, y cuáles son los totales de control? Si las cifras no cuadran antes de la carga, cargar más rápido no ayudará. El módulo 4 demuestra la migración con recuentos, totales, comprobaciones puntuales e informes agregados, pero la prueba empieza aquí.
La IA puede ayudar a limpiar. No puede inventarse la verdad.
Sección titulada «La IA puede ayudar a limpiar. No puede inventarse la verdad. »La IA es útil en la migración: sugerir mapeos, encontrar valores sospechosos, agrupar posibles duplicados, detectar anomalías, generar código de transformación, explicar patrones en los registros rechazados. Pero si un proceso de enriquecimiento decide “esta empresa probablemente está en Arizona”, probablemente no basta. Y si decide que dos clientes se parecen lo suficiente como para fusionarlos, recuerda el capítulo 6: un falso emparejamiento puede hacer más daño que quedarse corto emparejando. Usa la IA para acelerar la investigación. No dejes que fabrique en silencio datos de la empresa con autoridad.
Más allá del examen: lo que cambia la IA. La IA puede acelerar drásticamente el perfilado, el mapeo, la detección de anomalías y el emparejamiento de candidatos durante una migración. Mantén reglas deterministas, procedencia y revisión humana en torno a las decisiones que crean, fusionan o alteran datos de negocio con autoridad.
Lo que decide aquí un arquitecto
Sección titulada «Lo que decide aquí un arquitecto »- Qué datos del origen se migran, se archivan o se excluyen, según el valor de negocio y los requisitos de retención.
- Dónde ocurre la preparación (un almacén de preparación fuera de Salesforce, un objeto de staging dentro, o ambos), y qué partes de la organización de destino se traen para fusionar con ellas.
- Cómo se estandarizan, limpian, enriquecen, depuran de duplicados y validan los datos antes de entrar en el destino.
- Qué identificadores de origen y qué linaje sobreviven, para que cada registro de destino importante pueda rastrearse y conciliarse.
- El orden de carga que dicta el modelo de datos de destino, y las claves que usa cada hijo para encontrar a su padre.
- Cómo tratan las decisiones de eliminación de duplicados los campos y los hijos en todo el grafo de relaciones, sopesadas según la criticidad, la trazabilidad y el riesgo de una fusión errónea.
- Qué reglas de transformación y de gestión de excepciones deben ser repetibles antes de que empiece cualquier carga en producción.
No midas la migración por las filas cargadas
Sección titulada «No midas la migración por las filas cargadas »“Cargamos 500.000 de 500.000 registros” me dice que el cargador funcionó. Yo quiero saber: ¿movimos los datos correctos, mejoramos lo que había que mejorar, preservamos la identidad y las relaciones, consolidamos los duplicados con seguridad? ¿Podemos explicar lo que excluimos, reproducir la transformación, rastrear un registro de Salesforce hasta su origen y demostrar el resultado? Haz primero ese trabajo. Luego ya nos preocuparemos de lo rápido que podemos cargarlo.
Explora
Sección titulada «Explora »- Salesforce, General Guidelines for Data Loads (se abre en una pestaña nueva) and Relationship Fields in a Header Row (se abre en una pestaña nueva), Bulk API 2.0 and Bulk API Developer Guide, checked 2026-11-01. ⟲
- Salesforce, WorkOrder (se abre en una pestaña nueva), Object Reference for the Salesforce Platform, Winter ‘27 (API version 68.0), checked 2026-11-01. ⟲
- Salesforce Help, How the Import Process Works (se abre en una pestaña nueva) (the Nonprofit Success Pack’s staging object), checked 2026-11-01. ⟲
- Práctica: la ruta de Trailhead Import Data With Nonprofit Success Pack (NPSP) (se abre en una pestaña nueva) recorre todo el patrón de preparación en una organización de práctica: una plantilla, filas de preparación, una ejecución de prueba, la corrección de las filas que fallan y luego la importación. Se ejecuta en un Trailhead Playground; Trailhead indica que, desde diciembre de 2025, NPSP ya no se ofrece como paquete preconfigurado en las organizaciones de producción. Consultado el 2026-10-27.
- Salesforce Architects, Well-Architected, Fairness (se abre en una pestaña nueva), checked 2026-11-01. ⟲
- En este curso: Datos maestros e identidad (emparejamiento, supervivencia, vincular frente a fusionar), Calidad y gobierno de los datos y Claves y propiedad de la escritura (la clave del socio).
- Trailhead, Perform an Import Dry Run (se abre en una pestaña nueva), checked 2026-11-01. ⟲