Español

Archivo a largo plazo de datos heredados del CRM: qué conservar y cómo

Una empresa migró su CRM desde Salesforce en 2021. La migración salió bien. El nuevo CRM funcionaba. Pero nadie tomó una decisión sobre qué hacer con la organización de Salesforce anterior.

Dos años después, seguían pagando licencias de Salesforce. Veinte licencias a 150 USD/mes cada una: 36.000 USD al año por acceso read-only a datos históricos que tres personas en la empresa habían consultado en los últimos seis meses. El motivo por el que no se había cancelado: "No sabemos qué hay ahí que podamos necesitar."

Un incidente de gobernanza de datos en 2023 (una solicitud de borrado bajo el GDPR que requería encontrar y eliminar registros en todos los sistemas) obligó finalmente a tomar la decisión. Pasaron tres semanas auditando la organización de Salesforce, descubrieron que la mayor parte era redundante con el nuevo CRM, exportaron lo que no lo era y cancelaron. El coste total de la espera: 72.000 USD en tarifas de licencias innecesarias, tres semanas de tiempo de IT y una respuesta al GDPR que tardó 14 días en lugar de 2.

La decisión de archivo que debería haberse tomado en 2021 se tomó en 2023. Esta guía es esa decisión, tomada en el momento adecuado. Retoma donde deja la auditoría posmigracion de datos: una vez que las auditorías de 72 horas y 30 días confirman que el nuevo CRM está completo, el rol del sistema de origen pasa de red de seguridad ante un rollback a archivo histórico.

Qué está obligado a conservar legalmente

Antes de decidir qué archivar, comprenda qué está legalmente obligado a retener. La respuesta varía según la región, el sector y el tipo de registro.

GDPR (Unión Europea y Reino Unido):

El GDPR genera una tensión que muchas empresas no resuelven del todo: el derecho al borrado (las personas pueden solicitar la eliminación de sus datos) frente a las obligaciones de retención legítimas (es posible que usted necesite ciertos datos por razones legales o contractuales). El artículo de Wikipedia sobre el GDPR cubre las disposiciones del derecho al borrado (Artículo 17) y las excepciones para retención por obligación legal, ambas con impacto directo en qué datos archivados del CRM puede verse obligado a eliminar bajo solicitud.

En la práctica, para datos del CRM:

  • Puede retener datos sobre los que tenga un interés empresarial legítimo (relación activa con el cliente, obligación contractual)
  • Debe eliminar datos ante una solicitud de borrado, con excepciones limitadas
  • Los períodos de retención deben estar definidos; "los conservamos indefinidamente" no cumple el GDPR
  • Debe poder demostrar que los datos heredados archivados están incluidos en su mapa de datos (es decir, si alguien envía una solicitud de borrado, debe poder encontrar y eliminar sus registros en el archivo también)

Retención de datos en EE. UU.:

No existe una ley federal única sobre retención de datos del CRM, pero sí aplican normas sectoriales:

  • Servicios financieros (Regla 17a-4 de la SEC): ciertos registros comerciales deben retenerse durante 3-7 años en un formato no borrable
  • Salud (HIPAA): si su CRM contiene PHI, las reglas de retención son estrictas y los procedimientos de eliminación deben estar documentados
  • California (CCPA): los consumidores tienen derechos de eliminación similares al GDPR; su archivo debe admitir esas solicitudes de borrado

Las directrices del NIST sobre retención y eliminación de datos ofrecen un marco tecnológicamente neutral para definir períodos de retención y procedimientos de eliminación segura, útil como referencia de cumplimiento independientemente de las regulaciones sectoriales que apliquen a su negocio.

Registros comerciales generales:

Los datos relacionados con contratos (condiciones de acuerdos, contratos firmados, comunicaciones con clientes en torno a negociaciones contractuales) suelen estar sujetos a la retención general de registros comerciales, típicamente 7 años en EE. UU. y la UE para registros financieros.

Quién toma esta decisión:

Legal o cumplimiento, con aportación de IT y RevOps. Esta no es una decisión unilateral de IT. Obtenga un memorando firmado de legal o cumplimiento que especifique los períodos de retención por tipo de registro antes de archivar nada. Los tipos de registros sobre los que toma decisiones de retención aquí se superponen directamente con el alcance definido en gestión de actividades históricas, notas y correos electrónicos: lo que decidió migrar, archivar o descartar en el momento de la exportación determina qué categorías necesitan ahora un tratamiento formal de retención.

El marco de decisión de retención

Con la base legal comprendida, aplique una política de retención por tipo de registro.

Plantilla de política de retención:

Tipo de registro Retención recomendada Justificación
Acuerdos cerrados-ganados (datos del contrato, condiciones del trato) 7 años mínimo Registros comerciales, contratos auditables
Acuerdos cerrados-perdidos 3 años Análisis de Pipeline, referencia competitiva
Contactos activos en el momento de la migración 3 años posmigracion Referencia de relación comercial en curso
Contactos inactivos (sin interacción en más de 2 años) 1 año posmigracion, luego eliminar Sin interés legítimo tras el borrado
Registros de actividad: notas ingresadas por el representante 3 años Contexto de la relación, resolución de disputas
Registros de actividad: eventos generados por el sistema 1 año máximo Bajo valor; sin obligación de retención
Metadatos de correo electrónico (asunto, fecha, remitente) 2 años Suficiente para la mayoría de necesidades de referencia
Contenido del cuerpo del correo electrónico 3 años para correos relacionados con acuerdos Referencia contractual/en disputa
Instantáneas de informes personalizados 5 años Registros de rendimiento empresarial
Registros de acceso de usuarios y auditoría 3-5 años Requisitos de seguridad y cumplimiento

Quién decide:

Legal o cumplimiento aprueba los períodos de retención. RevOps propone los tipos de registros y la justificación empresarial. IT es responsable de la implementación (qué formato, dónde se almacena, cómo se accede).

Documente la decisión formalmente. Una política de retención no necesita ser un documento de 50 páginas, pero sí debe existir como registro escrito que haya sido revisado y aprobado. Si un regulador pregunta por sus prácticas de retención de datos dentro de dos años, "lo discutimos en una reunión" no es una respuesta válida.

Elección del formato de archivo

El formato de archivo determina qué puede hacer con los datos más adelante. Optimice para: portabilidad (legible sin el sistema de origen), capacidad de consulta (¿puede alguien buscarlo?) y coste.

Opción A: exportación CSV + JSON

Exporte todos los objetos como archivos CSV planos (un archivo por objeto) más cualquier dato de relaciones como JSON o tablas de unión separadas. Almacene con un diccionario de datos que mapee cada columna a un nombre y tipo de campo.

Ventajas: cualquier herramienta puede leerlo. Sin dependencia de proveedor. Fácil de auditar para solicitudes de borrado. Se puede abrir en Excel, Sheets o cualquier herramienta de datos.

Desventajas: la consulta requiere cargar en una base de datos o usar herramientas de hoja de cálculo. Las relaciones entre objetos requieren uniones manuales.

Ideal para: la mayoría de los equipos. Simple, duradero y portátil.

Opción B: volcado de base de datos

Una copia de seguridad completa de la base de datos subyacente del CRM de origen (si el proveedor la proporciona).

Ventajas: se puede restaurar en una nueva instancia si es necesario. Preserva todas las relaciones de forma nativa.

Desventajas: el formato suele ser propietario o específico de la versión. La restauración requiere infraestructura coincidente. No es legible por humanos sin herramientas.

Ideal para: equipos con capacidad IT que quieran la opción de restaurar temporalmente el sistema de origen (por ejemplo, para una solicitud de descubrimiento legal importante).

Opción C: almacén de datos en la nube (BigQuery, Redshift, Snowflake)

Exporte los datos del CRM a un almacén en la nube estructurado donde se pueda consultar mediante SQL.

Ventajas: totalmente consultable. Gestiona solicitudes de borrado mediante SQL DELETE. Escalable. Se puede conectar a herramientas de BI.

Desventajas: requiere configuración de infraestructura en la nube y mantenimiento continuo. Excesivo para la mayoría de los equipos con menos de 100.000 contactos.

Ideal para: equipos que ya usan un almacén de datos y quieren que el historial del CRM forme parte de él.

Opción D: exportación gestionada SaaS-a-nube (Salesforce Data Archive, herramientas de archivado de HubSpot)

Algunos proveedores ofrecen archivado nativo que mueve los datos más antiguos a niveles de almacenamiento más económicos manteniéndolos consultables a través de la plataforma.

Ventajas: permanece dentro de la interfaz familiar de la plataforma. Esfuerzo de migración mínimo.

Desventajas: sigue requiriendo licencias del proveedor. No desactiva realmente el sistema de origen. No resuelve el problema de "estamos pagando por un sistema que no usamos".

Ideal para: empresas que necesitan una solución de archivo a corto plazo mientras planifican una desactivación completa.

Comparación de formatos de archivo:

Formato Portabilidad Capacidad de consulta Coste Complejidad
CSV + JSON Alta Baja (manual) Casi nulo Baja
Volcado de base de datos Baja (propietario) Baja (requiere restauración) Baja Media
Almacén en la nube Alta Alta (SQL) Bajo-medio (solo almacenamiento) Media
Exportación gestionada SaaS-a-nube Media Media Media (licencias) Baja

Opciones de almacenamiento y coste

Una vez elegido el formato de archivo, decida dónde reside.

Almacenamiento en frío (AWS Glacier, Azure Archive, Google Coldline):

  • Coste: ~0,004 USD/GB/mes (AWS Glacier Deep Archive)
  • Tiempo de recuperación: horas a días
  • Ideal para: datos que podría necesitar por razones legales/de cumplimiento pero que no espera consultar regularmente
  • Coste de recuperación: 0,02 USD/GB en modo urgente; menor en modo estándar

Para una exportación de CRM de 100 GB (típica para un CRM de 5 años con 100.000 contactos), el almacenamiento en frío cuesta aproximadamente 0,40 USD/mes. Un archivo de 5 años cuesta aproximadamente 24 USD en almacenamiento. No hay error tipográfico.

Almacenamiento estándar en la nube (AWS S3, Azure Blob, Google Cloud Storage):

  • Coste: ~0,023 USD/GB/mes (AWS S3 Standard)
  • Recuperación: inmediata
  • Ideal para: datos a los que accede ocasionalmente (mensual o trimestralmente)
  • Buen equilibrio entre coste y velocidad de acceso

Almacén de datos en la nube (BigQuery, Redshift, Snowflake):

  • Coste de almacenamiento: ~0,02 USD/GB/mes (BigQuery)
  • Coste de consulta: adicional por TB analizado
  • Ideal para: datos que consulta regularmente (semanalmente) o que necesita para búsquedas de autoservicio

Instalaciones locales:

  • Coste: gasto de capital en hardware más mantenimiento de IT
  • Acceso: inmediato
  • Ideal para: organizaciones con infraestructura local existente y fuertes requisitos de soberanía de datos
  • Desventajas: carga de mantenimiento; riesgo de fallo de hardware

Para la mayoría de las empresas que migran desde un CRM de mercado medio:

El almacenamiento en frío es la opción predeterminada correcta para datos de más de 2 años. Almacenamiento estándar en la nube para datos de los últimos 2 años que puedan consultarse. Almacén en la nube solo si ya ejecuta uno y el coste incremental es mínimo.

Creación de una vía de acceso para el equipo de ventas

Los representantes solicitarán registros antiguos. Cree un proceso antes de que llegue la primera solicitud.

El volumen realista de solicitudes:

En los primeros 30 días posmigracion, espere entre 5 y 15 solicitudes por cada 50 representantes. Después de 90 días, cae a 1-3 por mes. Después de 6 meses, casi nada. Planifique un volumen alto al principio y luego un volumen bajo estable.

Opciones de acceso, clasificadas por practicidad:

Opción 1: mantener el sistema de origen en modo read-only durante 90 días

El enfoque más sencillo. No desactive inmediatamente. Dé a los representantes acceso read-only directo al CRM anterior durante 90 días. Después de eso, el volumen de solicitudes cae lo suficiente como para que un proceso de consulta manual lo gestione.

Coste: un trimestre de tarifas de licencias. Para 20 usuarios a 75 USD/mes en modo read-only: 4.500 USD. Vale la pena para la mayoría de los equipos evitar construir un sistema de acceso paralelo. Este período de 90 días en modo read-only es también lo que hace viable el rollback planning: no inicie el proceso de desactivación hasta que esté seguro de que el nuevo CRM está completamente validado y la ventana de rollback se ha cerrado.

Opción 2: enviar una solicitud a IT

Una vez que finaliza el período en modo read-only, "enviar una solicitud" se convierte en la vía de acceso. El representante envía un correo a Ops o IT con el nombre del contacto y el motivo. IT consulta el archivo y responde en 24 horas.

Esto funciona con volumen bajo (menos de 5 solicitudes por mes). No escala si las solicitudes se mantienen altas.

Opción 3: consulta de archivo de autoservicio (para equipos técnicos)

Una UI web ligera o una herramienta de consulta de base de datos que los representantes puedan usar para buscar en el archivo por nombre de contacto o correo electrónico. Requiere tiempo de configuración, pero reduce la carga de IT a escala.

Viable para: equipos que ya tienen una herramienta de BI (Tableau, Looker, Metabase) donde se puede agregar el archivo como fuente de datos.

Desactivación limpia del sistema de origen

La desactivación es el último paso y el que genera problemas si se hace con prisa.

Lista de verificación para la desactivación:

  • Exportación del archivo verificada y validada (los recuentos de filas coinciden con el origen, registros de muestra legibles)
  • Política de retención aprobada por legal/cumplimiento
  • Todas las integraciones activas que apuntan al CRM de origen identificadas y redirigidas o desactivadas
  • Configuración de SSO/SAML actualizada (eliminar el CRM anterior del proveedor de identidad)
  • Cualquier sincronización de correo o calendario conectada al CRM anterior desconectada
  • Claves API y tokens OAuth emitidos por el CRM anterior revocados o rotados en los sistemas conectados
  • Cancelación del contrato con el proveedor enviada con el período de aviso correcto (típicamente 30 días)
  • Documentación interna actualizada (runbooks, documentos de IT que referencian el sistema anterior)
  • Mapa de datos actualizado para eliminar el CRM anterior (especialmente importante para la documentación de cumplimiento del GDPR)
  • Copia de seguridad final tomada el día de la cancelación (medida de precaución adicional)

Plazos de cancelación:

La mayoría de los proveedores de CRM requieren 30 días de aviso por escrito antes del final del período de facturación. Revise su contrato. Perder la ventana de cancelación por un día puede significar otro ciclo de facturación completo.

Las integraciones son el punto de fallo más común en la desactivación. Una herramienta interna que sigue realizando llamadas API al CRM anterior comenzará a arrojar errores al día siguiente de la desactivación. Audite todas las integraciones antes de cancelar. Una búsqueda simple del nombre de dominio del CRM anterior en sus repositorios de código, flujos de trabajo de Zapier y herramientas de automatización suele revelar conexiones que nadie recordaba. Esta auditoría también confirma que la sincronización de correo electrónico y calendario se ha redirigido completamente al nuevo CRM antes de que el sistema heredado quede offline.

Errores comunes

Archivar en un formato propietario que solo el proveedor puede leer. Si su archivo es una exportación con formato Salesforce que solo pueden interpretar las herramientas de Salesforce, estará pagando a Salesforce indefinidamente. Archive en formatos abiertos: CSV, JSON, SQL o un formato de base de datos estándar. La investigación de asesoría en gobernanza de datos de PwC recomienda formatos abiertos neutros respecto al proveedor para la retención de datos a largo plazo como parte de una gobernanza de datos responsable, garantizando que los datos archivados permanezcan accesibles y auditables con independencia de las relaciones con los proveedores.

Mantener el sistema de origen activo más allá de su utilidad de retención. Los costes se acumulan silenciosamente. Establezca una fecha de desactivación antes de que la migración esté completa. Incorpórela al plan del proyecto. Trátela como un entregable.

No documentar dónde reside el archivo y cómo acceder a él. Dentro de dos años, la persona que gestionó la migración podría ya no estar. Documente la ubicación del archivo, las credenciales de acceso y el proceso de consulta en un lugar que sobreviva a la rotación de personal.

Olvidar las claves API e integraciones vinculadas al sistema heredado. Cada herramienta que estaba conectada al CRM anterior (sincronización de correo, automatización de marketing, enriquecimiento de datos) debe auditarse antes de la desactivación. Un flujo de trabajo de Zapier olvidado que envía un correo de confirmación a nuevos contactos a través de la API del CRM anterior se romperá al día siguiente de la cancelación, y puede que no se detecte durante semanas.

Qué hacer a continuación

Complete el documento de política de retención y la decisión sobre el formato de archivo antes de la marca de los 90 días posmigracion. La ventana entre "migración completa" y "desactivación completa" es típicamente de 90-180 días. Aprovéchela bien.

El archivo se conecta directamente con gestión de actividades históricas, notas y correos electrónicos, concretamente los registros que decidió archivar en lugar de migrar. Esos registros deben poder encontrarse en el archivo cuando los representantes los soliciten.

Y la auditoría posmigracion de datos es un buen detonante para iniciar la decisión de archivo: una vez que las auditorías de 72 horas y 30 días confirman que el nuevo CRM está completo, el rol del sistema de origen pasa de "copia de seguridad ante un rollback" a "archivo de datos históricos". Ese es el momento para iniciar el proceso de desactivación.

Para el rollback planning, tenga en cuenta que una vez que haya iniciado la desactivación del sistema de origen, el rollback ya no es una opción. No inicie el proceso de desactivación hasta que esté seguro de que el nuevo CRM está completamente validado.

Más información