Probar la Migración con una Importación Sombra

Una importación sombra es la diferencia entre "encontramos 3 errores de mapeo en el sandbox" y "encontramos 3 errores de mapeo el día del cutover con 30 representantes esperando." Toma 2–3 horas ejecutarla correctamente. Previene el tipo de problemas que retrasan el go-live una semana.

Un equipo de migración omitió la importación sombra porque ya habían probado en una hoja de cálculo. Verificaron que el mapeo de campos se veía correcto en Excel, confirmaron que los valores de la lista de selección coincidían y se sintieron seguros. El día del cutover, descubrieron que los campos de relaciones entre Contacts y Deals no se resolvían — la herramienta de importación manejaba los lookups de asociación de manera diferente a lo que la comparación de la hoja de cálculo había sugerido. Cada deal en el sistema quedó huérfano de sus contactos. El cutover se pospuso cinco días mientras resolvían las asociaciones manualmente. Este tipo de falla de relaciones es más difícil de detectar si no ha mapeado el diseño del modelo de datos del CRM de destino antes de ejecutar su prueba.

Una importación sombra en un sandbox real lo habría detectado en los primeros 10 minutos.

Esta guía lo lleva por el proceso completo de importación sombra: configuración, selección del conjunto de datos de prueba, la propia ejecución de importación, verificación de QA y los criterios de aprobación que lo habilitan para el cutover.

Paso 1: Configure un Sandbox o Entorno de Prueba

Necesita una instancia real del CRM de destino — no una comparación en hoja de cálculo, no una verificación visual lado a lado. El objetivo es ejecutar su herramienta de importación real contra un entorno de CRM real y ver qué sucede.

HubSpot: Las cuentas sandbox de HubSpot están disponibles en los niveles Professional y Enterprise. Vaya a Configuración > Gestión de Cuenta > Sandboxes. Cree un sandbox, luego configure las mismas propiedades personalizadas, etapas de pipeline y definiciones de etapa del ciclo de vida que existen en su cuenta de producción. El sandbox debe reflejar la configuración de producción — de lo contrario, está probando contra una configuración diferente a la que usará el día del cutover. La documentación del sandbox de HubSpot cubre qué se sincroniza automáticamente desde producción y qué debe configurar manualmente.

Salesforce: Salesforce tiene múltiples tipos de sandbox. Para pruebas de migración, un sandbox de Developer es suficiente — tiene la misma configuración (objetos, campos, valores de lista de selección) que producción. Los sandboxes completos incluyen datos de producción pero son más lentos de aprovisionar y generalmente innecesarios para pruebas de migración. Configuración > Entornos > Sandboxes > Nuevo Sandbox.

Pipedrive: Pipedrive no tiene un sandbox nativo. Cree una cuenta de prueba gratuita bajo una dirección de email diferente. Configúrela para que coincida con las etapas de pipeline y campos personalizados de su producción. Los límites del nivel gratuito son suficientes para probar con 500–1.000 registros.

Zoho CRM: Zoho tiene un entorno sandbox disponible en Configuración > Developer Space > Sandbox. La configuración refleja su instancia de producción.

Cuando un sandbox no está disponible:

Cree una nueva cuenta de producción con un nombre de empresa de prueba y un email de administrador dedicado
Use una etiqueta de importación claramente etiquetada ("IMPORTACIÓN DE PRUEBA - ELIMINAR") en todos los registros de prueba
Después de las pruebas, elimine todos los registros con esa etiqueta antes del cutover

El sandbox debe tener:

Todos los campos personalizados creados y configurados (mismo tipo, mismos valores de lista de selección que producción)
Las etapas de pipeline y etapas del ciclo de vida definidas para que coincidan con su configuración de destino
Cuentas de usuario configuradas si está probando campos de asignación de usuarios
Webhooks de integración desactivados — no quiere que las importaciones de prueba desencadenen notificaciones reales

Paso 2: Prepare un Conjunto de Datos de Prueba Representativo

El conjunto de datos de prueba es donde la mayoría de las importaciones sombra se quedan cortas. Los equipos usan 50 registros limpios y bien formateados y concluyen que la migración funciona. Luego el conjunto de datos completo incluye 40 registros con caracteres acentuados, 200 con campos de relación nulos y 15 con notas que contienen etiquetas HTML — y la importación completa falla de maneras que la prueba no predijo.

Tamaño objetivo: 500–1.000 registros. Es lo suficientemente grande para exponer casos extremos pero lo suficientemente pequeño para verificar manualmente.

Criterios de Selección del Conjunto de Datos de Prueba

Construya su conjunto de datos incluyendo deliberadamente registros problemáticos, no solo los limpios:

Categoría	Cantidad de registros	Qué probar
Registros limpios y completamente completos	150	Línea base — todos los campos presentes, formato estándar
Número de teléfono faltante	60	Manejo de nulos en campo de teléfono
Email faltante	40	Cómo se manejan los nulos en campos requeridos
Caracteres inusuales en campos de nombre	50	O'Brien, Müller, José, Li Wei, nombres compuestos
Longitud máxima de campo	30	Nombres de empresa de 255 caracteres, notas largas, URLs de longitud máxima
Candidatos a duplicados (2 contactos, mismo email)	20	Cómo maneja la herramienta de importación los duplicados
Contactos sin asociación de empresa	30	Contactos independientes sin vínculos Account/Company
Contactos asociados a múltiples deals	30	Registros de relaciones múltiples
Registros con HTML en notas o campos de descripción	20	Renderizado del campo de notas en destino
Registros con las fechas más antiguas del conjunto de datos	20	Casos extremos de formato de campo de fecha
Registros de cada valor de etapa del ciclo de vida	1 por valor	Cobertura del mapeo de lista de selección
Registros de cada valor de fuente de lead	1 por valor	Cobertura del mapeo de lista de selección
Total	~500

Exporte este conjunto específicamente — no tome simplemente las primeras 500 filas. Las primeras 500 filas son generalmente los registros creados más recientemente, que típicamente están más limpios que los registros más antiguos. Quiere el desorden en su conjunto de datos de prueba.

Paso 3: Ejecute la Importación con Su Herramienta Exacta

Esto es crítico: use la misma herramienta de importación, el mismo archivo de mapeo de campos y las mismas reglas de transformación que usará el día del cutover. Si usa un método diferente para la importación de prueba, está probando un proceso diferente.

Herramientas de importación comunes por combinación de origen/destino:

HubSpot → Otro CRM: Exportación nativa CSV + importación CSV del CRM de destino, o una herramienta de migración como el asistente de importación nativo de HubSpot para objetos planos. La documentación de importación de HubSpot detalla el formato de encabezado de columna requerido para cada objeto — su CSV de prueba debe seguir esto exactamente o la importación omitirá filas silenciosamente.
Salesforce → Otro CRM: Salesforce Data Loader (gratuito, herramienta propia de Salesforce) para exportaciones CSV, o una herramienta de migración de propósito específico. El modo por lotes de Data Loader es esencial para las ejecuciones de prueba — produce un registro de éxito/error por fila que hace que el QA sea mucho más rápido.
Pipedrive → Otro CRM: Exportación nativa CSV + asistente de importación del destino
Cualquiera → Cualquiera: Herramientas de migración de terceros como Trujay, Migrate.io o Import2 manejan la resolución de relaciones automáticamente

Antes de ejecutar: Cargue su documento de mapeo de campos y las reglas de transformación. Debe seguir el documento, no improvisar. Si está tomando decisiones sobre la marcha durante la importación de prueba, el documento no está terminado — vuelva y complételo antes de la ejecución real. Si está cambiando desde HubSpot, cambiar de HubSpot a Rework cubre las peculiaridades de secuencia de importación específicas de ese sistema de origen.

Orden de importación (esto importa):

Companies / Accounts primero
Contacts segundo (para que las asociaciones de empresa puedan resolverse)
Deals / Opportunities tercero (las asociaciones de contactos deben existir)
Activities último (las asociaciones de deal y contacto deben existir)

Ejecute la importación en este orden incluso para la prueba. Desviarse del orden es una de las causas más comunes de campos de relaciones rotos.

Observe el registro de importación en tiempo real. No se aleje y regrese. El registro mostrará errores de validación de campos, fallos de conversión de tipo y registros que fueron omitidos. Anote cada error con el ID de registro y el mensaje de error — necesitará esta lista para el paso de QA.

Paso 4: Lista de Verificación de QA Post-Importación

Después de que se complete la importación, no asuma que funcionó porque terminó sin errores. Pase sistemáticamente por esta lista de verificación.

Lista de Verificación de QA Post-Importación

Verificación del recuento de registros:

El total de contactos importados coincide con el recuento esperado (línea base menos los omitidos intencionalmente)
El total de empresas importadas coincide con el recuento esperado
El total de deals importados coincide con el recuento esperado
El recuento de errores de importación coincide con el registro de errores (sin omisiones silenciosas)

Corrección del tipo de campo:

Los campos de fecha se muestran como fechas (no como cadenas de texto, no como marcas de tiempo Unix)
Los campos numéricos (Annual Revenue, monto de deal) se muestran como números, no como texto
Los campos de moneda tienen formato correcto en el destino
Los campos de teléfono se muestran en un formato consistente
Los campos Checkbox son True/False (no "1"/"0" o "Sí"/"No" a menos que ese sea el objetivo)

Mapeo de valores de lista de selección:

Todos los valores de etapa del ciclo de vida mapean a valores de destino válidos (sin etapas del ciclo de vida en blanco)
Los valores de fuente de lead mapean correctamente
Los valores de etapa de deal mapean correctamente
Cualquier campo de lista de selección personalizada mapea correctamente

Integridad de las relaciones:

Abra 20 registros de contacto y verifique que la asociación de empresa es correcta
Abra 10 registros de deal y verifique que la asociación de contacto es correcta
Verifique que al menos 3 registros de deal tienen al propietario del deal asignado correctamente
Para cualquier registro de múltiples asociaciones (contactos vinculados a múltiples deals), verifique que todas las asociaciones están presentes

Resultados de fórmulas y campos calculados:

Si el CRM de destino calcula campos (días desde última actividad, antigüedad del deal, etc.), verifique valores plausibles en 5 registros

Verificación del disparador de automatización:

Verifique que los registros de importación de prueba no dispararon workflows/secuencias en vivo (importante si ejecutó en un entorno adyacente a producción)

Registre cada fallo. Una verificación de QA que "funciona mayormente" no es un aprobado — cada fallo es un defecto en su documento de mapeo de campos que afectará la importación completa.

Paso 5: Pruebe los Tres Informes Más Usados

La verificación a nivel de campo detecta errores en registros individuales. La verificación de informes detecta problemas de mapeo sistémicos que solo aparecen cuando los datos se agregan.

Identifique sus tres informes más usados:

Generalmente: resumen de pipeline por etapa, contactos por etapa del ciclo de vida y deals creados este mes
Pregunte a su equipo de ventas qué informes abren diariamente — esos son los que debe verificar. El artículo de revisión semanal de pipeline describe qué formatos de informe de pipeline más confían los equipos de ventas, contexto útil para decidir qué informes son más importantes probar.

Para cada informe:

Ejecute el mismo informe contra el sistema de origen en su muestra de prueba de 500 registros
Ejecute el mismo informe (filtrado a los registros importados) en el destino
Compare los números

Los recuentos deben coincidir. Si su sistema de origen muestra 85 contactos SQL en la muestra de prueba y el destino muestra 79, tiene un error de mapeo de etapa del ciclo de vida que afecta a 6 registros. Encuéntrelos antes de la importación completa.

Discordancias comunes a nivel de informe y sus causas:

Diferencia de recuento en una etapa del ciclo de vida: Valor de lista de selección que no mapeó correctamente
Totales de ingresos incorrectos: Campo de moneda importado como texto (no suma correctamente)
Filtros basados en fecha que devuelven registros incorrectos: Formato de fecha importado incorrectamente; los registros se atribuyen al período incorrecto
Informes de propietario vacíos: La asignación de usuarios no se resolvió

Paso 6: Haga que un Representante de Ventas Pruebe Cinco Registros de Extremo a Extremo

El QA técnico encuentra errores técnicos. Los representantes de ventas encuentran errores de usabilidad — los campos que se ven correctos en el registro de importación pero se sienten incorrectos cuando está intentando trabajar un deal.

Elija un representante que conozca bien los datos de origen. Proporciónele los IDs de registro de cinco contactos y pídales que:

Encuentren el registro en el nuevo sistema
Verifiquen que la información se ve correcta — empresa, cargo, teléfono, email, etapa del ciclo de vida
Revisen el historial de actividad de esos contactos
Abran cualquier deal asociado y verifiquen la información del deal
Informen cualquier cosa que se vea incorrecta o falte

No les dé una lista de verificación de QA. Su reacción no guiada a la calidad de los datos es más valiosa que una verificación estructurada. El feedback que quiere es "esto se ve bien" o "¿dónde está la etapa de deal que estaba usando?" — esa es la señal que le indica si la migración causará problemas al equipo el primer día.

Paso 7: Documente Cada Error y Corrija Antes del Cutover

Después del QA, tendrá una lista de errores. Cada error tiene una de dos causas:

Un error en el documento de mapeo de campos
Un caso extremo en los datos que el documento de mapeo no consideró

Ambos necesitan corregirse en el documento de mapeo antes del cutover. No corrija errores editando manualmente registros en el destino — eso parcha 3 registros y deja la causa raíz en su lugar para los 47.000 restantes.

Para cada error:

Identifique la causa raíz: regla de transformación incorrecta, manejo de tipo incorrecto, mapeo de lista de selección incorrecto
Actualice el documento de mapeo
Vuelva a ejecutar los registros de prueba afectados a través del proceso corregido
Verifique que la salida es correcta

Si corregir un error requiere volver a ejecutar la importación de prueba completa, hágalo. Sí, toma otras 2–3 horas. Pero descubrir el día del cutover que su corrección introdujo un error secundario es peor.

Mantenga un registro de todos los errores encontrados y cómo se corrigieron. Este registro se convierte en parte de su documentación de migración y es útil si un problema post-cutover aparece que no fue detectado en las pruebas.

Lista de Verificación de Aprobación Antes de Programar el Cutover

No programe el cutover hasta que cada elemento de esta lista esté completo:

Verificación de datos:

El recuento de registros en la importación de prueba coincide con el recuento esperado dentro del 0,5%
Cero errores de tipo de campo sin resolver en el registro de importación
Tasa de nulos en etapa del ciclo de vida < 1% de los registros importados
Todos los campos de relaciones se resuelven correctamente (sin contactos o deals huérfanos)

Verificación de informes:

Los tres informes clave coinciden con los recuentos del sistema de origen dentro del 2%
Los totales de ingresos/moneda coinciden con el origen dentro del 0,1%
Los filtros basados en fecha devuelven los conjuntos de registros correctos

Aprobación de partes interesadas:

QA del representante de ventas completado — al menos un representante ha probado 5+ registros y confirmado que los datos se ven correctos
El liderazgo de ventas ha visto los informes clave y confirmado que se ven bien
TI/administración ha verificado el acceso de usuarios y la configuración de permisos

Preparación del proceso:

Documento de mapeo de campos finalizado (todos los errores de la importación de prueba corregidos)
Secuencia de importación documentada
Plan de rollback documentado
Comunicación de cutover redactada

No programe el cutover hasta que cada casilla esté marcada. La lista de aprobación no es burocracia — es el punto de control que separa "creemos que funcionará" de "hemos verificado que funciona."

Errores Comunes

Probar con muy pocos registros para exponer casos extremos. Una prueba de 50 registros con todos los datos limpios pasará el QA y aún fallará en la importación completa cuando llegue a los 200 registros con HTML en el campo de notas. Use 500+ registros con casos extremos deliberados.

No probar las relaciones — solo los campos de contacto planos. El QA de campos de contacto es la parte fácil. El QA de relaciones es donde las migraciones se rompen. Cada asociación de deal a contacto, cada vínculo de contacto a empresa necesita probarse explícitamente, no inferirse de las verificaciones a nivel de campo.

Omitir el paso de QA del representante de ventas. Los usuarios técnicos verifican si los campos son correctos. Los representantes verifican si los datos son utilizables. Esos son estándares diferentes. Un número de teléfono que es técnicamente válido pero en un formato inutilizable (sin código de área, código de país incorrecto) pasa el QA técnico y falla la prueba del representante.

Corregir errores en el destino en lugar de en el documento de mapeo. Este es el error más común. Encuentra 5 registros donde la etapa del ciclo de vida está en blanco, las configura manualmente en "SQL" en el destino y continúa. El día del cutover, 500 registros se importan con etapas del ciclo de vida en blanco. Corrija la causa raíz en el documento de mapeo.

Programar el cutover antes de que la importación sombra esté completa. La presión del liderazgo para alcanzar una fecha de go-live específica es real. Pero programar el cutover antes de que se cumplan los criterios de aprobación es cómo las migraciones fallan públicamente, con el liderazgo de ventas mirando. Un retraso de una semana en la importación sombra es mejor que un rollback del cutover. Cultura de higiene del pipeline es contexto relevante aquí — los equipos con disciplina débil de pipeline a menudo subestiman cuántos datos malos aparecen durante las pruebas sombra.

Qué Hacer Después

Programe la importación sombra al menos 5 días hábiles antes de su cutover planificado. Ese margen le da tiempo para corregir errores, volver a ejecutar la importación de prueba si es necesario y obtener la aprobación de las partes interesadas sin prisa. Y una vez que haya aprobado, implementación y adopción del CRM tiene los pasos de capacitación de representantes y gestión del cambio que convierten una migración de datos limpia en un sistema que el equipo realmente usa.

La importación sombra debe ser la última actividad antes de programar el cutover — no una de varias tareas paralelas que ocurren simultáneamente. Déle la atención que requiere.

Una vez que la lista de verificación de aprobación esté completa, estará listo para programar el cutover y preparar el playbook del día. Ese proceso se cubre en la guía del día del cutover.

Data Migration Guide