Donde la arquitectura de datos se encuentra con la realidad

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

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. (4)

Capítulo 10 de Data Architect, Parte 2: Arquitectura a escala. Anterior: Integración y movimiento de datos.

La migración es donde la arquitectura de datos se encuentra con la realidad. Cada decisión de modelado, calidad, datos maestros y volumen que hemos tomado se pone a prueba el día en que llegan millones de registros de golpe. Y una migración que “se cargó correctamente” puede ser igualmente un fracaso: propietarios equivocados, relaciones rotas, clientes duplicados, un millón de correos de bienvenida, registros bloqueados o un fin de semana de corte que se queda sin tiempo.

Image generated with AI. ⟲

Todo escenario de CTA tiene un sistema heredado que traer, y el candidato tiene que decir cómo entran los datos, cómo se limpian y cómo se eliminan los duplicados. Este capítulo es esa respuesta, desde la extracción del origen hasta el momento en que el sistema antiguo deja de importar, y luego las copias que siguen adelante.

Un ejemplo recorre los cinco módulos: Steve Trucking retirando RouteDesk, su antigua herramienta de despacho, con ocho años y unos 5 millones de entregas. Qué entra en Salesforce, cómo se prepara, cómo se carga, qué hace la automatización al respecto y el fin de semana en que todo ocurre. Luego la otra dirección: Salesforce, ya convertido en el sistema de registro, manteniendo sincronizada la copia de Snowflake.

Las ideas de este capítulo

• La migración es, ante todo, un proyecto de calidad, y una migración es una integración con final.
• Migrar, archivar o descartar, y saber por qué se mueve, o no, cada clase de datos.
• Prepara fuera y luego carga el resultado: un almacén de datos de preparación, el origen en bruto conservado, ningún paso que pierda fidelidad y tres juegos de claves (las del origen, las de las transformaciones, las de Salesforce).
• El modelo fija el orden de carga, y cada hijo encuentra a su padre por una clave, nunca por un nombre.
• Bulk API es el muelle de carga detrás del banco, y el muelle sigue necesitando un plan: insertar antes que upsert, ordenar por padre, el usuario de carga y los ID devueltos.
• Cada vez que desactivas la automatización, te haces responsable de que esa lógica de negocio no ocurra. El bypass forma parte del diseño original, se prueba activada y desactivada y se implementa mucho antes de que haga falta.
• El corte en producción debería ser aburrido: ensayado, ejecutado con un runbook, cargado pronto y oculto mediante el uso compartido, con el go/no-go y un reloj de reversión decididos de antemano.
• Demuéstralo de cuatro formas: recuentos, totales, comprobaciones puntuales e informes agregados.
• Sacar datos no es salir de Salesforce. Una migración tiene un principio y un final definidos; la sincronización es continua, y el espejo nunca es el maestro.

El recorrido de este capítulo

Cinco módulos, cada uno se sostiene por sí solo.

1. La migración es, ante todo, un proyecto de calidad. RouteDesk en el panorama; migrar, archivar o descartar; el almacén de datos de preparación; los cinco pasos de Steve; cargar por claves; los registros fusionados y sus hijos; tres juegos de claves.
2. Cargar con volumen. La ventanilla del cajero y el muelle de carga; Bulk API 2.0 y 1.0; insertar, actualizar o upsert; ordenar por padre; el usuario de carga; traer de vuelta las claves; ensayar la ejecución completa.
3. La automatización durante la carga. Las flechas que desencadena una carga; no necesitarla, simularla, aplazarla; cómo es un bypass en Apex, en los flujos y en las reglas de validación; el uso compartido; el inventario de la automatización.
4. El fin de semana del corte. El runbook; el Día −7, el Día −1, el Día 0 y el punto de reversión; dejar fuera a los usuarios; las cuatro pruebas; la autoridad cambia de manos el Día 0.
5. Sacar los datos: mantener otro sistema sincronizado. Salesforce sigue siendo el sistema de registro; Snowflake necesita un espejo. Las vías de salida, PK chunking, mantenerlo al día, una copia una vez o una copia para siempre.

Lo que decide aquí un arquitecto

• Qué se mueve en absoluto: migrar, archivar o descartar, y por qué.
• Cómo se ponen en condiciones los datos antes de llegar, y cómo cada registro sigue siendo trazable hasta su origen.
• El plan de carga: secuencia, claves, concurrencia, identidad y propiedad.
• Qué puede disparar la carga, y cómo vuelve el funcionamiento normal.
• Cómo se ejecuta y se demuestra el corte, y cuándo la reversión deja de ser una opción.
• Dónde termina la migración, qué mantiene sincronizada después la copia de otro sistema, y quién es dueño de cada valor.

Más allá del examen: la IA acelera la mitad analítica de una migración: el perfilado, el mapeo, la detección de anomalías, la escritura de los scripts. Úsala paso a paso, con cada comando generado bajo seguimiento. La validación, la conciliación y el go/no-go siguen siendo deterministas y responsabilidad de personas. Cada módulo termina con lo que cambia la IA.

Explora

• Salesforce, General Guidelines for Data Loads (se abre en una pestaña nueva) and Bulk API and Bulk API 2.0 Limits and Allocations (se abre en una pestaña nueva), checked 2026-11-01. ⟲
• Salesforce, Best Practices for Deployments with Large Data Volumes (se abre en una pestaña nueva), Winter ‘27, checked 2026-11-01. ⟲
• El curso Integration Architect: Bulk (coming soon).

Siguiente: Transactions, Concurrency, and Reliability