La respuesta corta
Reemplazar un sistema CRM con Salesforce no es un proyecto técnico de "migración de datos"; es una decisión organizacional sobre lo que merece ser conservado, lo que debe dejarse atrás y cómo mantener la operación del negocio mientras se realiza la transición. El error más común no radica en la definición de Salesforce en sí, sino en la suposición tácita de que todo lo que existe en el sistema antiguo debe transferirse tal cual.
El enfoque correcto comienza con la elaboración de un mapa de procesos, no con la exportación de tablas. Posteriormente, se construye un nuevo modelo de datos que se alinee con la forma en que la organización opera actualmente, no con la estructura establecida hace diez años en otro sistema. Un período de operación en paralelo controlado y, finalmente, la desconexión ordenada del sistema antiguo con documentación para fines regulatorios, completan el proceso.
Las organizaciones que enfrentan estas preguntas encontrarán información complementaria en Implementación de Salesforce en la organización, donde se detalla el proceso integral de toma de decisiones en un proyecto de Salesforce.
Mapeo de procesos existentes: no exportar, sino comprender
El primer paso en cualquier transición de sistemas CRM no es presionar "Exportar", sino sentarse con los propietarios de los procesos y comprender qué ocurre realmente desde la apertura de un lead hasta el cierre de un negocio, o desde la recepción de una consulta hasta el cierre de un caso de servicio. Un documento de procesos antiguo, si es que existe, está casi siempre desactualizado en relación con lo que sucede en la práctica.
En las reuniones de mapeo, conviene documentar no solo los pasos oficiales, sino también los "procesos en la sombra": archivos de Excel paralelos, campos que nadie rellena, aprobaciones que se envían por WhatsApp en lugar de a través del sistema. Estos son precisamente los puntos donde un nuevo sistema, incluso si está bien construido, falla en la adopción si no se tienen en cuenta.
El resultado del mapeo debe incluir una tabla con los procesos clave, el propietario del proceso, la frecuencia de uso y el grado de dependencia del sistema antiguo. Un proceso ejecutado una vez al trimestre que genera un informe crítico para el regulador requiere un tratamiento diferente al de un proceso diario de alto volumen. Esta clasificación determina tanto el orden de la migración como el nivel de pruebas necesario para cada proceso.
Qué no migrar: una decisión que ahorra la mitad del trabajo
Una de las decisiones más significativas en un proyecto de migración de CRM no es qué migrar, sino qué no migrar. En la mayoría de los sistemas antiguos que se han acumulado durante años, existen capas de campos duplicados, estados que han sido reemplazados y procesos definidos para un proyecto puntual que ya concluyó.
Una regla práctica: cualquier objeto o campo que no haya sido utilizado en los últimos dos años se traslada a la lista de "no migrar" por defecto, a menos que un propietario de proceso específico solicite una excepción justificada. Esta lista se construye a partir de los registros de uso real del sistema antiguo, no de la memoria de los usuarios, ya que la memoria humana suele describir el sistema tal como se suponía que funcionaba y no como funciona en la práctica.
Es importante distinguir entre tres categorías de información:
- Información activa – Debe migrar al nuevo sistema como un registro operativo con todas sus relaciones asociadas.
- Información histórica relevante – Migra como archivo para consulta, generalmente sin necesidad de edición o automatización.
- Información inactiva – No migra en absoluto, se conserva únicamente en una copia de seguridad externa en caso de auditoría.
Una ampliación sobre la gestión de los límites entre la fase de planificación y la de construcción se encuentra en Scope Creep en Salesforce, ya que la tendencia a añadir "un poco más de datos antiguos" es una de las fuentes más comunes de desviación del alcance en proyectos de este tipo.
Modelo de datos nuevo versus antiguo: no es una traducción, es un diseño
Un error común es abordar el modelo de datos como una traducción 1:1: cada tabla del sistema antiguo se convierte en un objeto en Salesforce, cada columna en un campo. Este enfoque conserva todas las debilidades del sistema antiguo dentro de una nueva plataforma y desaprovecha la principal ventaja de Salesforce: la capacidad de construir relaciones flexibles entre objetos, automatización integrada y una rica capa de permisos.
Una comparación entre los dos enfoques principales para la migración ayuda a tomar una decisión informada:
| Aspecto | Lift-and-Shift (Migración tal cual) | Rediseño |
|---|---|---|
| Tiempo del proyecto | Relativamente corto, generalmente 6-10 semanas | Más largo, típicamente 3-5 meses |
| Adecuación al proceso de negocio | Baja — conserva limitaciones antiguas | Alta — construido alrededor del proceso actual |
| Riesgo de deuda técnica | Alto, se manifiesta en uno o dos años | Menor, ya que la estructura se planifica de antemano |
| Costo de mantenimiento futuro | Aumenta con el tiempo | Relativamente estable |
| Adecuado para | Organizaciones con presión de tiempo extrema o un Scope muy limitado | La mayoría de las organizaciones que migran de un sistema de más de tres años |
| Riesgo principal | "Sistema nuevo, problemas antiguos" | Desviación del cronograma si el Scope no está bien definido |
En la práctica, la mayoría de las organizaciones optan por un enfoque intermedio: Rediseño para el modelo central (cuentas, contactos, oportunidades o casos de servicio), y un Lift-and-Shift controlado para entidades secundarias que no tienen un impacto procesal significativo. Esta decisión debe tomarse explícitamente en la fase de planificación, no surgir de forma aleatoria durante la construcción.
Período de paralelismo: cómo mantener la continuidad del negocio
El período de paralelismo es la ventana de tiempo en la que ambos sistemas operan en paralelo, generalmente entre cuatro y ocho semanas. Su objetivo es exponer las brechas en tiempo real, antes de que se conviertan en un problema irreversible. Una venta cerrada, una llamada de servicio abierta o un informe de comisiones generado, todo esto debe verificarse simultáneamente en ambos sistemas y mostrar un resultado idéntico o explicable.
Una pregunta que se repite en casi todos los proyectos: ¿cuál es el sistema considerado "fuente de la verdad" durante este período? La respuesta debe ser única y definida de antemano, generalmente Salesforce desde el primer día, donde el sistema antiguo se utiliza solo para verificación y no para el trabajo diario. El trabajo duplicado de los usuarios en ambos sistemas es una receta para la fatiga y el abandono real del nuevo sistema.
Herramientas prácticas para gestionar el período:
- Un informe de comparación diario o semanal entre los datos clave de ambos sistemas (número de leads, monto de transacciones, llamadas abiertas).
- Una lista de excepciones en vivo que se actualiza tan pronto como se detecta una brecha, con un Propietario responsable de cerrarla en un plazo definido.
- Un grupo de "usuarios ancla" de cada departamento que informan diariamente sobre problemas de uso, no solo sobre problemas técnicos.
Gran parte de los conocimientos recopilados durante este período son relevantes también para el proceso de pruebas sistemáticas, detallado en la Guía de UAT para Salesforce, y para el período posterior al lanzamiento, descrito en el Plan de Hypercare para Salesforce.
Desconexión del sistema antiguo: no es un evento único, sino una secuencia de decisiones
La desconexión del sistema antiguo se realiza por fases, no con un solo clic el día del Cutover. La regla general: el sistema se desconecta de la operación diaria inmediatamente el día del Go Live, pero permanece accesible solo en modo de lectura por un período de gracia corto, generalmente de 30 a 60 días, en caso de que se detecte un dato faltante o una pregunta del equipo financiero.
Lista de verificación para la decisión de Cutover
Antes de emitir un anuncio oficial de que el sistema antiguo ha sido desconectado, es aconsejable verificar lo siguiente:
- ☐ Todos los informes que se generaban regularmente desde el sistema antiguo han sido recreados con éxito en Salesforce o desde el archivo.
- ☐ Se ha completado un ciclo de negocio completo (por ejemplo, un cierre de mes completo) íntegramente dentro del nuevo sistema.
- ☐ Las discrepancias de datos entre los sistemas han disminuido por debajo de un umbral predefinido (por ejemplo, menos del 1% de los registros).
- ☐ Existe una confirmación por escrito del departamento legal o financiero de que el archivo cumple con los requisitos de conservación.
- ☐ Se ha definido quién es el responsable del acceso de solo lectura durante el período de gracia y cuándo se cerrará definitivamente.
- ☐ Se ha realizado y verificado una copia de seguridad completa de todos los datos del sistema antiguo antes de cancelar la licencia.
- ☐ Se ha enviado una notificación a todos los propietarios de procesos sobre la fecha de desconexión final y la forma de acceder al archivo.
Saltarse cualquiera de estos puntos es la razón más común por la que, meses después del proyecto, se descubre que no hay acceso a la información que de repente se necesita para una auditoría fiscal o un litigio.
Archivo y regulación: qué se debe conservar y por cuánto tiempo
Los requisitos de retención de datos varían entre los sectores, pero casi siempre existe la obligación de conservar datos financieros, contractuales o relacionados con quejas de clientes por un período de siete años o más. El error común es intentar "empujar" todo este historial a Salesforce como registros activos, lo que sobrecarga el rendimiento y confunde a los usuarios que ven transacciones de hace una década en sus listas diarias.
La solución habitual es la separación en dos capas:
| Capa | Contenido | Ubicación | Accesibilidad |
|---|---|---|---|
| Información operativa activa | Últimos 24-36 meses | Salesforce | Completa, incluyendo edición y automatización |
| Archivo regulatorio | Historial completo según lo 법 | Almacén de datos externo o Salesforce Archive | Solo lectura, con capacidad de búsqueda |
Es crucial documentar la política de archivo por escrito y obtener la aprobación del departamento legal antes de revocar el acceso al sistema antiguo, ya que una vez que la licencia es cancelada, no hay vuelta atrás si se descubre que falta un dato.
Escenario organizacional de ejemplo
Una empresa de servicios financieros migró de un sistema CRM local de 12 años a Salesforce. Durante la fase de mapeo, el equipo identificó que aproximadamente el 40% de los campos existentes no se habían tocado en dos años o más, y decidió excluirlos de la migración. Esto ahorró aproximadamente un mes de trabajo en construcción y pruebas.
Durante el período de paralelismo, que duró seis semanas, se detectó una discrepancia en el cálculo de comisiones debido a una diferencia en el redondeo de números entre los sistemas, un error que no se habría descubierto sin un informe de comparación diario. El equipo corrigió la fórmula antes de que afectara a una nómina real. El sistema antiguo se desconectó de la operación diaria el día del Go Live, pero el acceso de lectura se mantuvo durante 45 días adicionales para la verificación de un informe trimestral que ya estaba en proceso.
El resultado: a los tres meses de la desconexión final, no se requirió acceso adicional al sistema antiguo, y el ahorro en costos de licencias cubrió una parte considerable del costo del propio proyecto de migración.
Riesgos comunes y acciones preventivas
| Riesgo | Cómo se manifiesta en la práctica | Acción preventiva |
|---|---|---|
| Migrar "todo" sin filtrar | El nuevo sistema está abarrotado de datos inactivos y ralentiza la adopción | Definir un criterio de filtrado basado en el uso real en los últimos dos años |
| Modelo de datos copiado | Las mismas limitaciones del sistema antiguo se repiten en Salesforce | Diseñar un nuevo modelo alrededor del proceso actualizado, no de las tablas antiguas |
| Paralelismo sin Owner | Las brechas entre los sistemas se detectan tarde o no se detectan | Informe de comparación periódico con un responsable definido para cada excepción |
| Desconexión demasiado apresurada | Se descubre un dato faltante después de que la licencia ya ha sido cancelada | Período de gracia de acceso de solo lectura antes de la cancelación definitiva |
| Ignorar los requisitos de archivo | Una auditoría regulatoria revela que la información requerida no se conservó correctamente | Obtener aprobación legal por escrito sobre la política de archivo antes del Cutover |
Cómo medir el éxito de la transición
| Área | Qué se mide | Frecuencia de revisión |
|---|---|---|
| Integridad de los datos | Tasa de registros transferidos con éxito y sin errores | Antes y después de cada ejecución de migración |
| Coincidencia entre sistemas | Discrepancias en informes clave entre el sistema antiguo y el nuevo | Diariamente durante el período de paralelismo |
| Adopción por parte de los usuarios | Tasa de trabajo en el nuevo sistema frente al retorno al antiguo | Semanal durante el primer mes |
| Costo operativo | Ahorro en licencias y mantenimiento tras la desconexión | Mensual a partir de los tres meses tras el Go Live |
Para el reemplazo de un sistema CRM por Salesforce, es recomendable seleccionar de antemano entre tres y cinco métricas clave, y medirlas tanto antes como después del proyecto. De lo contrario, es difícil demostrar que la transición realmente mejoró el proceso y no solo lo trasladó a otra plataforma. La ejecución práctica de un proceso así puede realizarse con el apoyo de servicios de implementación de Salesforce, que acompañan a las organizaciones desde la fase de mapeo hasta la desconexión del sistema antiguo.
Fuentes profesionales
- Salesforce Well-Architected — https://architect.salesforce.com/docs/architect/well-architected/guide/overview.html
- HPI Pro – Implementación de Salesforce — https://hpi.pro/salesforce-implementation
- HPI Pro – Metodología de trabajo — https://hpi.pro/methodology