Migración y sincronización

🌐 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)

Imagen generada con IA

Traducido con IA. Aún no revisado por la comunidad. Leer en inglés Esta sección cambió en inglés y aún no se ha vuelto a traducir. (1)

Guía de estudio del capítulo 10 del curso Data Architect. Lee primero los cinco módulos; esta página te ayuda a comprobar qué se te ha quedado.

Sobre esta guía de estudio. Está construida solo con el contenido de este curso y con la lista de objetivos publicada en la guía del examen de Salesforce. Nunca se basa en preguntas reales del examen, y no pretende saber qué hay en el examen. Si ya hiciste el examen, por favor no me envíes preguntas: el acuerdo de certificación prohíbe compartirlas, y memorizar respuestas es, de todos modos, la forma equivocada de convertirse en arquitecto.

Este capítulo lleva toda la sección Data Migration del examen (15 %): la calidad en el momento de la carga, la carga de grandes volúmenes y la extracción de datos. Las cifras de la Bulk API cambian, así que aprende para qué sirve cada palanca y comprueba los límites actuales antes de planificar en torno a ellos.

Para el examen

Márcalos a medida que avanzas. Cada uno enlaza con el lugar donde se enseña.

MIG-1: alta calidad de datos en el momento de la carga

• Migro lo que el sistema nuevo necesita para funcionar, no todo lo que guardaba el antiguo: migrar, archivar o descartar, con la conservación decidida por el negocio. (Migrar, archivar o descartar, y saber por qué)
• Preparo los datos en un almacén de datos de preparación fuera de Salesforce, con los registros actuales de la organización traídos para fusionar con ellos. (Dónde ocurre la preparación)
• Conozco el orden: estandarizar, limpiar, enriquecer, desduplicar, validar, y por qué no puedes emparejar registros hasta que sus valores tienen una sola forma; las listas de selección se asignan con una tabla de transformación que firma el negocio. (Mi orden)
• Guardo cada clave heredada en un External ID, cargo los padres antes que los hijos y dejo que cada hijo encuentre a su padre por clave (una columna de relación como Parent.External_Id__c), nunca por nombre. (Conserva la identidad del origen, y carga por claves)
• Desduplico dentro de los datos entrantes y frente a Salesforce, elijo un superviviente campo a campo y decido qué pasa con los hijos del registro fusionado. (Los registros fusionados necesitan una estrategia para los hijos)
• Conservo el origen en bruto sin cambios y cada transformación repetible, sin ningún paso que pierda fidelidad. (Transformaciones repetibles, origen en bruto conservado)
• Doy a los registros malos una cuarentena con el motivo, y compruebo si lo que está mal es la regla y no el registro. (Los registros malos necesitan un lugar adonde ir)
• Demuestro una migración de cuatro formas: recuentos, totales, comprobaciones puntuales e informes agregados, frente a cifras esperadas fijadas antes de la carga, y los responsables de negocio también validan. (Cuatro formas en que demuestro los datos)

MIG-2: cargar grandes volúmenes

• Sé cuándo la respuesta es Bulk API: más de unos 2.000 registros, asíncrono, un trabajo que envías y recoges; por debajo, llamadas síncronas agrupadas (hasta 200 registros por llamada). (El muelle de carga detrás del banco)
• Distingo Bulk API 2.0 de Bulk API (1.0): la 2.0 divide los lotes por ti y se ejecuta en paralelo; la 1.0 te hace construir lotes de hasta 10.000 y es la única que ofrece el modo en serie; las dos comparten 15.000 lotes en 24 horas. (Dos muelles de carga)
• Sé que insert es lo más rápido, luego update, luego upsert, divido un upsert cuando puedo, cargo datos limpios (un lote que falla pasa a procesarse fila a fila) y envío solo los campos que cambiaron. (Insert, update o upsert)
• Ordeno la carga por padre para que los lotes en paralelo no se peleen por los mismos bloqueos, y trato el modo en serie como el recurso de reserva. (En paralelo es más rápido, hasta que deja de serlo)
• Establezco la propiedad de los registros de forma deliberada y vigilo el sesgo de propiedad (más de 10.000 registros en un mismo propietario). (El usuario de carga, y quién es propietario de los registros)
• Guardo los resultados de cada trabajo (conservados siete días) y traigo de vuelta los ID nuevos, para poder cargar por fases, reintentar solo los fallos y recargar con seguridad. (Guarda cada resultado y trae las claves de vuelta)
• Para cada automatización decido: no la necesito, la simulo, la aplazo, o la dejo ejecutarse, sabiendo que desactivarla significa hacerme responsable de su lógica de negocio. (Tres opciones)
• Incorporo un bypass en los desencadenadores y los flujos desde el principio, probado activado y desactivado e implementado con antelación; desactivar flujos a mano antes de una carga es un antipatrón. (Incorpora el bypass desde el principio)
• Sé dónde vive un bypass: un permiso personalizado ($Permission, FeatureManagement.checkPermission), una configuración personalizada de jerarquía (organización, perfil o usuario; $Setup, getInstance()) o metadatos personalizados por automatización. (Cómo es un bypass)
• Sé que las cargas grandes desencadenan el recálculo del uso compartido, que el soporte puede habilitar los cálculos de uso compartido diferidos, y que el trabajo aplazado se ejecuta dentro de los límites de Apex asíncrono. (Datos derivados, uso compartido y el objeto de staging)
• Planifico el corte: la mayor parte de los datos cargados días antes, ocultos mediante el uso compartido, luego una actualización y una carga incremental, con el origen congelado o sus cambios capturados. (Día −7, día −1, día 0)
• Dejo fuera a los usuarios congelando sus cuentas, con el horario de inicio de sesión, los intervalos de IP o un flujo de inicio de sesión, nunca desactivándolos, y mantengo una puerta trasera. (Deja fuera a los usuarios cuando necesites control)

MIG-3: exportar datos

• Conozco las vías de salida: Data Export Service (semanal o mensual según la edición; archivos conservados 48 horas; sin campos de fórmula ni de resumen acumulado), Data Loader y los informes, la consulta masiva y los productos de copias de seguridad. (Las formas de salir)
• Conozco el PK chunking: una consulta grande dividida en intervalos de ID de registro, para tablas de más de unos 10 millones de registros; un encabezado en Bulk API 1.0, automático en la consulta de Bulk API 2.0; ORDER BY y LIMIT lo desactivan. (Copias muy grandes: PK chunking)
• Mantengo una copia al día con una marca de agua (SystemModstamp), detecto las eliminaciones con queryAll dentro de los 15 días de la Papelera de reciclaje y uso eventos cuando importan los minutos. (Luego, mantenlo al día)
• Sé que una migración tiene un principio y un final definidos; la sincronización es continua, y el espejo nunca es el maestro. (Una copia una vez, o una copia para siempre, La autoridad cambia de manos el Día 0)

Más allá del examen

El examen es el piso, no el techo. Estos son los hábitos de este capítulo que necesita un arquitecto, los pregunte o no el examen.

• La migración es, ante todo, un proyecto de calidad. Mover datos malos más rápido no es un éxito.
• Una migración es una integración con final. Pregúntale todo lo que le preguntarías a cualquier flecha.
• Prepara fuera y luego carga el resultado. Conserva el origen en bruto; ningún paso puede perder fidelidad.
• Tres juegos de claves: las del origen, las de las transformaciones y las de Salesforce, todas conservadas.
• El modelo fija el orden de carga, y cada hijo encuentra a su padre por una clave, nunca por un nombre.
• Cada vez que desactivas una automatización, asumes toda la responsabilidad de que esa lógica de negocio no ocurra.
• El bypass forma parte del diseño original, no es algo que construyes la semana en que lo necesitas.
• Producción debería ser aburrido. No hagas que producción sea la primera vez que ejecutas la migración.
• La reversión tiene un reloj. Sabe en qué momento se agota.
• Los datos desconocidos y los envíos olvidados provocan las reversiones, no el cargador.
• Confía, pero verifica: recuentos, totales, comprobaciones puntuales e informes agregados.
• Si el sistema antiguo está muerto, deja de alimentarlo.
• Sacar datos no es salir de Salesforce. La primera copia lleva el espejo hasta ahí; la sincronización lo mantiene ahí.

Palabras que conviene conocer

Término	En una línea
Almacén de datos de preparación	Una base de datos fuera de Salesforce donde se preparan los datos antes de la carga
Tabla de transformación	Una tabla que asigna cada valor de origen a su valor de destino, firmada por el negocio
Cuarentena	Adonde van los registros que fallan un paso, con el motivo, un responsable y un plazo
Superviviente	El registro que queda cuando se fusionan los duplicados
External ID	La clave de otro sistema en un registro de Salesforce, que se usa para emparejar y para el upsert
Bulk API	La API asíncrona para grandes cargas y extracciones, en trabajos
Upsert	Actualizar el registro que coincide si existe, crearlo si no
Modo en serie	El procesamiento de Bulk API 1.0 de un lote cada vez, para evitar la contención por bloqueos
Bypass	Un interruptor que una automatización comprueba primero, para poder saltársela con seguridad (algunos lo llaman interruptor de emergencia)
Permiso personalizado	Un permiso concedido mediante un conjunto de permisos, que comprueban la automatización y las reglas
Configuración personalizada de jerarquía	Una configuración con valores de organización, perfil y usuario, en la que gana el más específico
Cálculo de uso compartido diferido	Suspender el recálculo del uso compartido durante los grandes cambios y ejecutarlo después
Runbook	El plan de corte paso a paso, con responsables, tiempos y pruebas
Go/no-go	La decisión, según criterios fijados de antemano, de pasar o no a producción
Punto de reversión	El momento a partir del cual volver atrás perdería trabajo real
Conciliación	Comparar lo que se esperaba con lo que llegó
PK chunking	Dividir una consulta grande en intervalos de ID de registro
Marca de agua	El punto hasta el que estaba al día una copia, para que la siguiente ejecución sepa qué cambió
Sincronización	Un proceso continuo que mantiene coherentes dos sistemas

Ponte a prueba

Escenarios cortos al estilo del curso. Decide tu respuesta antes de abrirla.

1. Una empresa retira un sistema heredado con ocho años de historial y quiere "todo" en Salesforce. ¿Tu primera pregunta?

¿Qué necesita el sistema nuevo para funcionar? Normalmente se migran los registros activos y recientes; el historial más antiguo va a un archivo o a un almacén de datos donde sigue siendo accesible, con la conservación decidida por el negocio. Vuelve a leer Migrar, archivar o descartar, y saber por qué.

2. Los contactos deben vincularse a sus cuentas durante la carga, y nadie tiene todavía los ID de cuenta de Salesforce. ¿Cómo?

Guarda la clave de cada cuenta heredada en un campo External ID de Account, carga primero las cuentas y luego carga los contactos con una columna de relación (Account.Legacy_Id__c) para que cada contacto encuentre a su padre por clave. Vuelve a leer Conserva la identidad del origen, y carga por claves.

3. Tres registros de cliente heredados resultan ser un solo cliente. ¿Qué decides, además de qué registro sobrevive?

Qué pasa con los hijos de los registros fusionados: pasarlos al superviviente, dejarlos fuera y archivarlos, o conservarlos en un registro inactivo vinculado. Cada opción tiene un coste; sopesa el riesgo de una fusión errónea. Vuelve a leer Los registros fusionados necesitan una estrategia para los hijos.

4. Una carga en paralelo con Bulk API de 2 millones de registros hijos no deja de fallar con "unable to lock row". ¿Qué pruebas primero?

Ordena el archivo de carga por padre para que cada lote toque los menos padres posibles. Si sigue habiendo contención, el modo en serie de Bulk API 1.0 es el recurso de reserva, a costa de la velocidad. Vuelve a leer En paralelo es más rápido, hasta que deja de serlo.

5. Hace falta una recarga después de corregir una transformación. ¿Cómo evitas los duplicados y recargas solo lo que cambió?

Upsert por el External ID, y usa los ID que trajiste de vuelta de la primera carga para saber qué registros ya existen; envía solo las filas afectadas y los campos cambiados. Vuelve a leer Guarda cada resultado y trae las claves de vuelta.

6. El plan de carga dice "desactivar estos doce flujos el viernes por la noche". ¿Qué falla?

Desactivar flujos a mano antes de una carga masiva es un antipatrón. Cada automatización debería tener un bypass incorporado desde el principio, probado activado y desactivado y ya implementado, que se activa solo para el usuario de migración. Vuelve a leer Incorpora el bypass desde el principio.

7. Un flujo crea una tarea de bienvenida para cada cliente nuevo. Están a punto de cargarse dos millones de clientes históricos. ¿Opciones?

No se necesita (bypass para los registros migrados), simularla (fijar el resultado en los datos), aplazarla (un lote posterior) o dejarla ejecutarse de forma deliberada. Para clientes de hace ocho años, una tarea de bienvenida no hace falta. Vuelve a leer Tres opciones.

8. La carga completa tarda 18 horas; el negocio permite 4 horas de inactividad. ¿Cómo?

Carga la mayor parte de los datos días antes, ocultos a los usuarios mediante el uso compartido, y luego una actualización y una pequeña carga incremental dentro de la ventana, con el origen congelado o sus cambios capturados. Vuelve a leer Día −7, día −1, día 0.

9. Los recuentos coinciden exactamente, 475.000 frente a 475.000. ¿Listo?

Todavía no. Los recuentos no ven los datos erróneos: comprueba los totales de control, haz comprobaciones puntuales de registros reales de principio a fin y compara informes agregados por región, estado o año. Vuelve a leer Cuatro formas en que demuestro los datos.

10. Tienes que extraer 30 millones de registros de un objeto, y la consulta masiva no deja de agotar el tiempo de espera. ¿Qué cambia?

El PK chunking: la consulta se ejecuta por intervalos de ID de registro. En la consulta de Bulk API 2.0 es automático (salvo que ORDER BY o LIMIT lo desactiven); en Bulk API 1.0 fijas el encabezado. Vuelve a leer Copias muy grandes: PK chunking.

11. Un almacén de datos refleja Salesforce cada noche, y los registros eliminados en Salesforce siguen apareciendo en sus informes. ¿Por qué?

Una consulta normal no devuelve los registros eliminados. Usa queryAll para encontrarlos, y ejecuta esa comprobación muy dentro de los 15 días de la Papelera de reciclaje. Vuelve a leer Luego, mantenlo al día.

12. "Tenemos cargas de diferencias, así que estamos sincronizando." ¿Es así?

No necesariamente. Si las diferencias se ejecutan hasta el corte y luego se detienen, eso es migración. Si los dos sistemas siguen activos y tienen que seguir coincidiendo, eso es sincronización, con un dueño para cada valor. Vuelve a leer Una copia una vez, o una copia para siempre.

Explora

• Salesforce Certified Platform Data Architect Exam Guide (se abre en una pestaña nueva), Salesforce Help (checked 2026-11-01): the official list of objectives and their weights. Always check the current version before you book the exam. ⟲
• La sección Explora de cada módulo enumera la documentación de Salesforce detrás de sus datos, con la fecha en que se comprobaron.