Cargar con volumen

🌐 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. (11)

Módulo 2 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: La migración es, ante todo, un proyecto de calidad · Siguiente: La automatización durante la carga

La pregunta que responde este módulo: ¿cómo cambia el Número de Ceros la forma de cargar datos en Salesforce?

¿Diez registros? Casi puedo teclearlos. ¿Mil? Ahora necesito una herramienta. ¿Un millón? Eso es un problema de arquitectura. La operación no ha cambiado (crear o actualizar registros), pero el Número de Ceros cambia cómo la hago. Lo hemos visto con el modelado, las consultas, el uso compartido y las integraciones, y la migración no es distinta. Con volumen, me importa cómo muevo los datos, cómo los divido en trabajo, en qué orden se mueven, qué más está haciendo Salesforce mientras cargo, cómo me recupero cuando algo falla y si puedo volver a ejecutarlo todo.

Empieza por el dibujo

El mismo panorama, la misma flecha ámbar que en el módulo 1: el trabajo abierto de RouteDesk entrando en Salesforce el fin de semana en que se retira RouteDesk.

Clic para ampliar

El módulo 1 decidió qué se mueve por esta flecha. Este módulo trata de cómo se mueve.

El módulo 1 decidió qué entra: las entregas aún no realizadas y las que siguen dentro del plazo de reclamación de 60 días, unas 196.400 entregas. Cada una se convierte en una orden de trabajo, con sus partidas (unas 1,6 por entrega, así que unas 314.000) y su cita de servicio (unas 196.400 más). Son aproximadamente 707.000 registros, preparados en el almacén de datos de preparación y listos para salir. No son millones, pero sí muchos más de los que enviaría de uno en uno. Entonces, ¿cómo entran?

El muelle de carga detrás del banco

Cuando enseño la Bulk API, uso el banco. Entras con un montón de depósitos, y el cajero coge 200 y te manda al final de la cola. Con un millón de registros, son 5.000 vueltas a la cola, 5.000 llamadas a la API. Mientras tanto, un camión se para al lado del banco, descarga una cantidad enorme de depósitos y, veinte minutos después, se va mientras tú sigues en la cola. Ese es el muelle de carga, y se llama Bulk API.

El 200 sigue siendo real. Una solicitud REST de sObject Collections acepta “hasta 200 registros” (Create Records Using sObject Collections (se abre en una pestaña nueva), REST API Developer Guide), y una llamada SOAP create() lo mismo: “Si una solicitud de creación supera los 200 registros, falla toda la operación” (create() (se abre en una pestaña nueva), SOAP API Developer Guide; ambas consultadas el 2026-10-27). Cada 200 registros más es otra llamada. Los 707.000 registros de RouteDesk serían más de 3.500 viajes a la ventanilla del cajero.

Clic para ampliar

Los mismos registros, otra puerta.

El muelle de carga tiene cinco pasos:

1. Abrir el trabajo. Pulsa el timbre rojo y recibe un número: el ID del trabajo.
2. Subir. Se abre el muelle y cargas tus archivos CSV con ese número, un archivo o cien.
3. Cerrar el trabajo. Salesforce no sabe que has terminado hasta que pulsas el gran botón azul: subida completa. Ahora empieza a procesar.
4. “¿Ya llegamos?” Como mis hijos en el asiento de atrás: preguntas, con tu ID de trabajo, si ya terminó. ¿Ya está? ¿Ya está?
5. Recoger los resultados. Descarga los registros correctos (con sus nuevos ID de Salesforce) o los fallidos (con sus errores).

Clic para ampliar

Enviar, esperar, recoger.

Un millón de registros cuesta un puñado de llamadas en lugar de miles. Pero fíjate en lo que cambió: el trabajo es asíncrono. No recibes una respuesta por registro; envías, esperas y recoges. Así que quien llama necesita saber qué se envió, qué se sigue procesando, qué terminó, qué falló y qué volvió. Eso no es un detalle de la API. Es el control de la migración.

Dos muelles de carga: Bulk API 2.0 y Bulk API

Hay dos versiones, y importa cuál usas.

• Bulk API 2.0 es por la que hay que empezar. Subes los datos de un trabajo y Salesforce los divide en lotes por ti, reintenta por ti y los ejecuta en paralelo. Un trabajo admite 150 MB, medidos después de que Salesforce lo codifique, así que Salesforce aconseja no subir más de 100 MB de CSV por trabajo.
• Bulk API (1.0) te obliga a crear tú los lotes, de hasta 10.000 registros cada uno. Es más antigua, pero sigue teniendo dos palancas que la 2.0 no te da: el modo en serie para las cargas y el PK chunking para las exportaciones muy grandes (módulo 5).

Las dos comparten una asignación de 15.000 lotes en 24 horas móviles, y cualquiera de las dos puede cargar hasta 150 millones de registros en 24 horas. Los resultados de los trabajos se conservan siete días después de que termine el trabajo (Bulk API and Bulk API 2.0 Limits and Allocations (se abre en una pestaña nueva), consultado el 2026-10-27). La línea de Salesforce entre las dos puertas: “Cualquier operación de datos que incluya más de 2.000 registros es una buena candidata para Bulk API 2.0”; por debajo, las llamadas síncronas “agrupadas” (bulkified) están bien (Loading Data from the API (se abre en una pestaña nueva), Best Practices for Deployments with Large Data Volumes, Winter ‘27, consultado el 2026-10-27). Esas son las cifras de hoy: compruébalas antes de planificar en torno a ellas.

Uno a uno, por conjuntos y masivo es como pienso en la forma del trabajo: una sola actualización por la acción de un usuario, unos cientos de registros relacionados por un proceso de negocio, millones de registros históricos en una migración. No son nombres de productos. Pregunta cuál es la forma del trabajo antes de elegir la herramienta.

Conocimiento para el examen. Sabe cuándo la respuesta es Bulk API: más de unos 2.000 registros, asíncrono, un trabajo que envías y recoges. Distingue las dos versiones: Bulk API 2.0 divide los lotes por ti y los ejecuta en paralelo; Bulk API (1.0) te hace construir lotes de hasta 10.000 registros, y solo ella ofrece el modo en serie y el PK chunking. Las dos comparten 15.000 lotes en 24 horas móviles.

La herramienta no elimina la arquitectura

“Usaremos la Bulk API”. De acuerdo. Eso no me dice qué objetos se cargan primero, si insert o upsert, cuál es la clave externa, cómo se reconstruyen las relaciones, qué pasa cuando fallan algunos registros, si los trabajos pueden ejecutarse en paralelo, si el trabajo en paralelo va a pelearse por los mismos padres, qué automatización se ejecutará, ni cómo conciliaremos y reanudaremos. La Bulk API resuelve un problema de transporte. No resuelve la migración.

El orden viene del modelo, y el módulo 1 lo dibujó para RouteDesk: primero los datos de referencia, luego las órdenes de trabajo, luego sus partidas y citas, luego los casos de reclamación que apuntan a ellas (Conserva la identidad del origen, y carga por claves). Cada oleada es su propio trabajo, y la siguiente no empieza hasta que llegan los resultados de la anterior. Los objetos de unión dependen de dos padres, las jerarquías que se referencian a sí mismas pueden necesitar varias pasadas, y las relaciones circulares pueden necesitar primero los registros y después las relaciones. No lo descubras el fin de semana del corte.

A veces cargas el registro y luego la relación. Una empresa matriz, una filial y una filial regional se crean todas en la migración. En lugar de resolver todas las relaciones en una sola pasada, carga las cuentas con sus claves de origen estables y luego haz una segunda pasada que establezca la jerarquía. La misma idea ayuda con las autobúsquedas y las dependencias circulares. El objetivo no es una sola pasada. Es un resultado determinista y repetible.

Insert, update o upsert

Insert dice crea esto como nuevo. Update dice ya sé qué registro de Salesforce estoy cambiando. Upsert dice usa esta clave para averiguar si el registro existe; actualízalo si existe, créalo si no. Con External ID estables, el upsert facilita mucho los ensayos: cargar, encontrar un problema de transformación, corregirlo, volver a ejecutar, sin que la ejecución dé por hecho que todo es una primera inserción. Las claves son arquitectura, no solo fontanería de integración. Las órdenes de trabajo de RouteDesk hacen upsert por la clave del socio, el mismo campo que usa la integración, así que un manifiesto que Redrock reenvía el fin de semana del corte actualiza el registro migrado en lugar de duplicarlo.

Pero el upsert tiene un precio. La propia guía de grandes volúmenes de datos de Salesforce ordena las operaciones: “insert() es la más rápida, update() la siguiente, y upsert() la siguiente después de esa. Si es posible, divide también upsert() en dos operaciones: create() y update()” (Loading Data from the API (se abre en una pestaña nueva), consultado el 2026-10-27). ¿Cómo sabes qué registros son nuevos y cuáles ya existen? Lo sabe el almacén de datos de preparación, porque trajo lo que Salesforce ya tiene y guarda los ID que volvieron (módulo 1). Así que las 190.000 órdenes de trabajo entregadas que nada en Salesforce ha tocado pueden entrar con un insert normal, y solo las abiertas que puede que la integración ya haya creado necesitan el upsert.

Dos líneas más de la misma guía. Carga datos limpios: “Los errores en los lotes provocan el procesamiento fila a fila de ese lote, y ese procesamiento afecta mucho al rendimiento.” Ese es el módulo 1 dando sus frutos en el muelle de carga. Y cuando actualices, “envía solo los campos que han cambiado”. Una recarga que reenvía todos los campos de 196.400 órdenes de trabajo hace un trabajo que nadie ha pedido.

Pero el upsert no es magia. Si la estrategia de claves está mal, la operación está mal. Dos registros de origen del mismo cliente con claves distintas son dos registros para Salesforce; una clave de origen que puede identificar varios destinos significa que entendimos mal la cardinalidad. El trabajo de calidad del módulo 1 sigue importando; una función de la API no lo sustituye.

Conocimiento para el examen. Insert es la operación más rápida, luego update, luego upsert; Salesforce sugiere dividir un upsert en creaciones y actualizaciones cuando puedas. Upsert necesita un External ID, y es lo que hace seguras las repeticiones. Carga datos limpios, porque los errores en un lote de Bulk API llevan ese lote al lento procesamiento fila a fila, y envía solo los campos que cambiaron.

En paralelo es más rápido, hasta que deja de serlo

El procesamiento en paralelo aumenta el rendimiento. Pero si muchos registros de la carga apuntan al mismo padre, las transacciones compiten por los bloqueos de ese padre, y lo que hicimos para ir más rápido crea contención de bloqueos, errores y reintentos. Son otra vez los puntos calientes del capítulo 7: si un millón de hijos convergen en unos pocos padres, la forma de los datos importa para la carga. Cuando dos lotes esperan cada uno un bloqueo que tiene el otro, tienes un interbloqueo (deadlock), dos coches atascados en un cruce.

RouteDesk tiene exactamente esa forma. Casi 196.400 órdenes de trabajo, y casi todas apuntan a una de las tres cuentas de socios minoristas. Cárgalas en paralelo en el orden en que las exportó RouteDesk, y cada lote contiene órdenes de trabajo de los tres socios.

Clic para ampliar

En el orden de exportación, cada lote necesita a todos los padres. Uno bloquea, los demás esperan.

Dos palancas. Primera, ordena los archivos por padre, para que los hijos de un mismo padre viajen juntos en el mismo lote en lugar de repartirse entre lotes que chocan. Salesforce da el mismo consejo: “Cuando cambies registros hijos, agrúpalos por padre: agrupa los registros por el campo ParentId en el mismo lote para minimizar los conflictos de bloqueo” (Loading Data from the API (se abre en una pestaña nueva), consultado el 2026-10-27).

Clic para ampliar

Ordenados por socio, cada lote trabaja con su propio padre.

Segunda, en Bulk API 1.0, el modo en serie procesa un lote cada vez: más lento, pero elimina la contención. Recurro al modo en serie cuando los datos son complejos y nos encontramos con choques y tiempos agotados. La propia guía de Salesforce es más prudente: el modo en serie “solo se usa cuando trabajos asíncronos enviados anteriormente han provocado accidentalmente contención por bloqueos. Úsalo solo cuando te lo aconseje Salesforce” (Limits (se abre en una pestaña nueva), Bulk API 2.0 and Bulk API Developer Guide, consultado el 2026-10-27). Así que ordena primero, y trata el modo en serie como el recurso de reserva. Y solo está en el muelle antiguo: la referencia de trabajos de Bulk API 2.0 dice “Actualmente solo se admite el modo en paralelo”, y si algún día llegan otros modos, “la API elegirá el modo automáticamente y el usuario no podrá configurarlo” (Create a Job (se abre en una pestaña nueva), Bulk API 2.0, consultado el 2026-10-27). Una carga que necesita procesamiento en serie es una razón para usar Bulk API 1.0.

Serial mode is a setting on the job, chosen when you create it. On Bulk API 1.0, RouteDesk’s Work Orders would be: ⟲

POST /services/async/68.0/job
{
  "operation": "upsert",
  "object": "WorkOrder",
  "externalIdFieldName": "Partner_Delivery_Key__c",
  "contentType": "CSV",
  "concurrencyMode": "Serial"
}

Leave concurrencyMode out and you get Parallel, the default. Salesforce’s job reference says when to change it: “If parallel mode results in too many failed records or failed jobs, submit the job with Serial concurrency mode,” and adds that it “can significantly increase the processing time” (JobInfo (se abre en una pestaña nueva), Bulk API 2.0 and Bulk API Developer Guide, checked 2026-10-31). ⟲

Y si tres padres son demasiado pocos para que ordenar ayude, mira el modelo. El Checkpoint 1 ya ofrecía una forma de repartirlos: vincular las órdenes de trabajo a una cuenta hija por centro de distribución, para que nueve padres compartan la carga en lugar de tres. Esa es una decisión de diseño, tomada antes de la migración, no un ajuste del cargador.

No empiezo con “siempre en paralelo” ni con “siempre en serie”. Miro la forma de las relaciones, los padres calientes, la automatización que se dispara, qué más bloquea y qué pasó en el ensayo. Luego elijo. Primero correcto, luego rápido.

Conocimiento para el examen. Las cargas en paralelo bloquean los registros padre. Cuando muchos hijos comparten unos pocos padres, espera errores “unable to lock row”: ordena el archivo de carga por padre para que cada lote toque los menos padres posibles. El modo en serie (solo Bulk API 1.0) elimina la contención a costa de la velocidad; Salesforce lo reserva para la contención por bloqueos que no resolvió la ordenación.

El tamaño del lote es una decisión de ajuste

La gente quiere un número mágico. Yo no lo tengo. El tamaño correcto depende del objeto, la complejidad del registro, la automatización, las relaciones, los bloqueos, el payload y el mecanismo. Demasiado grande, y los fallos salen caros y las transacciones hacen demasiado trabajo; demasiado pequeño, y domina la sobrecarga y la ejecución tarda mucho más de lo que debería (y, en 1.0, consume tu asignación de lotes). Empieza dentro de los límites que admite la herramienta y luego mide con datos representativos.

Y los datos del ensayo necesitan la misma forma que los de producción. Veinte millones de registros en producción, diez mil en la prueba, y todo va como un rayo: ¿qué hemos demostrado? Poco sobre la escala. La prueba no necesita todos los registros, pero debe poner al descubierto la arquitectura: mucha concentración en unos pocos padres, millones de hijos, campos de texto grandes, relaciones complejas, sesgos históricos, automatización desencadenada por valores concretos. El Número de Ceros importa, y también la forma que hay detrás de los ceros. Para RouteDesk eso significa un conjunto de ensayo en el que un tercio de las órdenes de trabajo siga apuntando a Redrock.

El usuario de carga, y quién es propietario de los registros

Para una migración importante quiero un usuario de migración dedicado, no la cuenta de administrador personal de alguien: por trazabilidad, permisos controlados, decisiones sobre la automatización (módulo 3), monitorización y resolución de problemas. Un millón de registros creados por el usuario de migración durante el corte me dice algo. Un millón creados por Daniel Reyes porque Daniel ejecutó Data Loader el sábado por la noche mezcla la identidad de una persona con la actividad del sistema. Dale los permisos que necesita el trabajo, y no dejes que se convierta en un superusuario misterioso y permanente que nadie se atreve a desactivar.

Luego no confundas quién cargó un registro con quién debería ser su propietario. Creado por es procedencia; Propietario es arquitectura, con consecuencias de uso compartido y de negocio. Establece la propiedad de negocio de forma deliberada. A veces no hay una buena respuesta en el origen: el propietario del registro se fue hace años, o nunca existió. Puede ser difícil asignar registros a usuarios activos, y he creado un usuario dedicado de “carga de datos” como propietario. Es una práctica sensata con una condición del capítulo 7: un usuario propietario de más de 10.000 registros de un objeto es sesgo de propiedad, así que ese propietario no debería tener función, o tener una función propia en la cima de la jerarquía (Ownership Data Skew (se abre en una pestaña nueva)), y los registros deberían tener un camino hacia propietarios reales. Quién es propietario de los registros, y dónde se sitúa ese propietario en la jerarquía de funciones, es una decisión importante que el equipo toma para cualquier importación masiva, no algo que decida por defecto el cargador. Para las órdenes de trabajo de RouteDesk, lo decide la pregunta del capítulo 7: ¿determina la propiedad quién ve una entrega? En Steve Trucking no (los socios ven sus propias entregas a través del socio que figura en el registro), así que un único propietario sin función está bien.

Herramientas: elige por la repetibilidad

Hay muchas formas de cargar datos, y la herramienta importa menos que cómo la usas. Data Loader de Salesforce ha sido fiable y probado, pero se ha quedado viejo: una herramienta de escritorio que trabaja CSV a CSV. Su versión de línea de comandos se puede automatizar con scripts y apuntar a tu almacén de datos de preparación, que es como he ejecutado cargas repetidas. Algunas herramientas conectan una base de datos SQL directamente con Salesforce, copiando los datos hacia abajo y enviando los cambios de vuelta con SQL. Las plataformas de ETL y de integración hacen el mismo trabajo a escala empresarial. Y con las API puedes manejar Bulk API directamente: sf data upsert bulk de la CLI de Salesforce carga un CSV mediante Bulk API 2.0 con un External ID en un solo comando (data upsert bulk (se abre en una pestaña nueva), Salesforce CLI Command Reference, consultado el 2026-10-27). Incluso puedes hacer que la IA escriba los pequeños scripts que ejecutan cada paso complejo.

Sea cual sea la herramienta, esta es mi preferencia más firme: no quiero que la migración en producción sea la primera vez que hacemos la migración, y no quiero que cada ensayo sea una aventura artesanal. Si el paso 17 dice “abre este CSV, ordena por la columna G, borra las filas vacías, copia esta fórmula hacia abajo y ejecuta Data Loader con esta configuración”, me pongo nervioso. Cada paso manual es una oportunidad para un archivo equivocado, una fila olvidada, una versión obsoleta, una mala ordenación, un filtro olvidado, una configuración distinta de la del ensayo. Algunos pueden ser inevitables: documéntalos y pruébalos. Pero el objetivo es la repetibilidad, así que extraer, transformar, validar, cargar, capturar los resultados y conciliar deberían ejecutarse igual cada vez.

Si programas cargas, no las programes con más frecuencia de la que pueden terminar. Un trabajo cada hora que a veces tarda noventa minutos empezará encima de sí mismo; comprueba que la ejecución anterior terminó antes de que empiece la siguiente.

Guarda cada resultado y trae las claves de vuelta

Para cada carga, conserva la versión de entrada, el archivo de carga transformado, el ID del trabajo, los resultados correctos y fallidos con sus errores, los tiempos, los recuentos de registros y las salidas de la conciliación. Después de una gran migración, alguien preguntará “¿qué le pasó a este registro?”, y quiero pruebas, no “creo que estaba en el tercer CSV del sábado por la mañana”. Los resultados de la carga masiva solo se conservan siete días, así que descárgalos sobre la marcha. Dales a estos artefactos un ciclo de vida más adelante; no los tires mientras todavía necesites demostrar el traslado.

Luego trae las claves de vuelta. Los resultados correctos llevan el nuevo ID de Salesforce de cada registro junto a la clave que enviaste. Escríbelos de nuevo en el almacén de datos de preparación, en la fila que produjo el registro: ese es el último paso de los tres juegos de claves del módulo 1. En la migración de Zendesk que describí en el módulo 1, eso es lo que hizo posible todo lo demás. Con los ID de Salesforce de vuelta en cada fila, podía cargar por fases (primero las cuentas y los contactos, luego los casos, luego los comentarios y archivos que cuelgan de ellos), y cada fase encontraba a sus padres por los ID que había devuelto la anterior. Podía hacer una carga parcial: solo las filas que fallaron, o solo un grupo. Y podía recargar: corregir una transformación, regenerar las filas afectadas y enviar solo esas, sabiendo exactamente qué registros de Salesforce actualizarían. Sin las claves de vuelta, cada repetición es una conjetura.

El tamaño de los fallos también es una cuestión del Número de Ceros. Veinte fallos de 100 es malo; veinte de 20 millones sigue necesitando una investigación, pero es otra señal. Vigila las tasas, no solo los recuentos, y clasifica los fallos: validación, padre que falta, clave duplicada, bloqueo, tipo de dato, automatización, permisos. Clasificados, te muestran problemas de arquitectura en lugar de un archivo de errores gigante.

Y el rendimiento es más que registros por segundo. “Duplicamos el rendimiento”. ¿Qué cambió? ¿Aumentaron los bloqueos, los fallos o los reintentos? ¿Se quedó atrás la automatización posterior, se atascó el recálculo del uso compartido, se vio desbordada otra integración? ¿Se acortó de verdad el corte en total? Una migración no se ejecuta en el vacío.

Conocimiento para el examen. Los resultados correctos de Bulk API devuelven el nuevo ID de Salesforce de cada registro con los datos que enviaste, y sus resultados de fallo devuelven cada error; ambos se conservan siete días. Captúralos, escribe los ID de vuelta en los datos de origen o de preparación, y podrás cargar por fases, reintentar solo los fallos y conciliar lo que llegó.

Prueba la ejecución completa

Cargar cuentas, luego contactos, luego pedidos, cada uno probado por separado, no es una migración probada. Quiero un ensayo completo, de principio a fin, con la misma secuencia, las mismas transformaciones, identidades, estrategia de automatización y conciliación, con un volumen representativo. Aparecen dependencias entre los pasos: un retraso de diez minutos hace que la siguiente carga empiece a la hora equivocada, una tasa de fallos inesperada cuesta horas de corrección, un recálculo del uso compartido mueve el calendario. La ejecución completa te dice si funciona la migración, no solo si funciona cada comando.

Si el ensayo incluye una prueba de rendimiento o de escala, incluye en el plan el plazo de antelación de Salesforce. “Todas las pruebas deben aprobarse previamente. Las pruebas no aprobadas pueden ser limitadas o bloqueadas”, y para las pruebas de 120 solicitudes por segundo o menos, la solicitud se presenta “al menos una semana antes de la fecha de la prueba” (Salesforce Performance and Scale Test FAQs (se abre en una pestaña nueva), Salesforce Help, consultado el 2026-10-27). Un ensayo que se ve limitado no demuestra nada sobre el fin de semana del corte.

La IA puede escribir el script. La ejecución sigue siendo tu responsabilidad.

La IA es muy buena generando scripts de transformación, orquestación de cargas, analizadores de errores, consultas de conciliación y lógica de reintentos. Úsala. Pero el código generado puede equivocarse a una velocidad enorme: una transformación errónea en diez registros son diez correcciones; en diez millones, el Número de Ceros también se aplica al error. Mi forma de usarla es paso a paso: pasos de limpieza, transformación y migración, con cada comando y cada acción generados registrados. Eso es automatización determinista y auditable, no un criterio sin supervisión. Pruébala a una escala realista antes de confiarle datos de producción.

Más allá del examen: lo que cambia la IA. La IA reduce el esfuerzo de construir las herramientas de migración, y facilita generar y ejecutar operaciones masivas rápidamente. Cuanto mayor es la operación, más se necesitan transformaciones deterministas, pasos bajo seguimiento, ensayos, controles y conciliación.

Lo que decide aquí un arquitecto

• Qué mecanismo de carga y qué versión de la API encajan con el volumen y la forma del trabajo, en lugar de tratar una migración como tráfico transaccional.
• La secuencia de objetos y relaciones que marcan las dependencias, incluido cuándo los registros y las relaciones necesitan pasadas separadas.
• Qué operación recibe cada conjunto de registros (insert, update o upsert), según lo que el almacén de datos de preparación sabe que ya existe.
• Dónde es seguro el procesamiento en paralelo, y dónde la concentración, los bloqueos o la automatización justifican ordenar por padre, un cambio de modelo o el procesamiento en serie.
• Qué claves estables, identidad de migración, propiedad de los registros y herramientas repetibles hacen deterministas los ensayos y las cargas en producción.
• Cómo vuelven los resultados y los ID nuevos, para que las cargas puedan ejecutarse por fases, reintentar solo los fallos y recargar con seguridad.
• Qué pruebas, clasificación de fallos y ensayo completo se exigen antes de confiar en el proceso a escala de producción.

El muelle de carga sigue necesitando un plan

El muelle de carga mueve cantidades enormes de datos. No decide qué camión descarga primero, adónde van los palés, qué envío pertenece a qué cliente, qué pasa con un palé dañado, si dos carretillas usan el mismo pasillo ni si llegó todo lo que debía llegar. Eso es arquitectura. Conoce el Número de Ceros y la forma que hay detrás. Carga en el orden de las dependencias, usa claves estables, controla la concurrencia, trae las claves de vuelta, haz el proceso repetible, conserva la evidencia y ensaya todo. Luego usa el muelle de carga tan rápido como la arquitectura lo permita con seguridad.

Explora

• Salesforce, Bulk API and Bulk API 2.0 Limits and Allocations (se abre en una pestaña nueva), Developer Limits and Allocations Quick Reference, checked 2026-11-01. ⟲
• Salesforce, General Guidelines for Data Loads (se abre en una pestaña nueva) and Limits (se abre en una pestaña nueva), Bulk API 2.0 and Bulk API Developer Guide, checked 2026-11-01. ⟲
• Salesforce, Best Practices for Deployments with Large Data Volumes, Loading Data from the API (se abre en una pestaña nueva), Winter ‘27, checked 2026-11-01. ⟲
• Salesforce, REST API Developer Guide, Create Records Using sObject Collections (se abre en una pestaña nueva), checked 2026-11-01. ⟲
• Salesforce, SOAP API Developer Guide, create() (se abre en una pestaña nueva), and Bulk API 2.0, Create a Job (se abre en una pestaña nueva), checked 2026-11-01. ⟲
• Salesforce, Bulk API 2.0 and Bulk API Developer Guide, JobInfo (se abre en una pestaña nueva) (the Bulk API 1.0 job fields, concurrencyMode), API version 68.0 (Winter ‘27), checked 2026-11-01. ⟲
• Salesforce Help, Salesforce Performance and Scale Test FAQs (se abre en una pestaña nueva), checked 2026-11-01. ⟲
• El curso Integration Architect: Bulk (coming soon) trata la Bulk API a fondo.
• En este curso: Diseñar para la escala (puntos calientes y sesgo de propiedad).
• Salesforce Developers, Designing Record Access for Enterprise Scale, Ownership Data Skew (se abre en una pestaña nueva), checked 2026-11-01. ⟲
• Salesforce Developers, Salesforce CLI Command Reference, data upsert bulk (se abre en una pestaña nueva), checked 2026-11-01. ⟲