La mayoría de las migraciones de CRM se gestionan como una lista de tareas. Mapear los datos, construir los workflows, agendar la capacitación, elegir una fecha de launch. La lista se pone en verde, alguien declara el proyecto terminado, y la mañana del go-live el equipo de cara al cliente entra a un sistema que nadie ha usado realmente de punta a punta. Ese es el momento en que aparecen las fallas, en producción, con clientes reales en los registros.
El problema es que una lista de tareas confirma que el trabajo está hecho. No confirma que el flujo funciona. Un workflow puede estar construido y aun así dispararse con el trigger equivocado. Una property puede estar mapeada y aun así caer en una view que el rep nunca abre. Una pipeline puede estar configurada y aun así no tener camino desde la stage en la que entra un lead hasta la stage en la que se gana un deal. Nada de eso aparece en un status sheet. Aparece la primera vez que un registro real intenta recorrer todo el journey, y si esa primera vez es su go-live, está depurando la infraestructura de ingresos mientras su gente intenta vender sobre ella.
Antes había holgura en el sistema para absorber un launch accidentado. Unas pocas personas apagaban los workflows rotos durante una semana, el admin parchaba en vivo, y el equipo llegaba a la adoption a duras penas. Ese colchón casi desapareció. El análisis GTM 2026 de SaaStr encontró que la empresa mediana prevé un crecimiento de headcount de RevOps de cero por ciento este año, con organizaciones GTM entre 20 y 30 por ciento más ajustadas y mucho más planas que antes. Las personas que absorbían un cutover fallido ya no existen en el organigrama.
Lo que está en juego del otro lado también es mayor. No tiene muchos intentos. Como lo plantea SaaStr en su artículo de 2026 sobre el lock-in de CRM, la migración suele ser «demasiado dolorosa para justificarse» una segunda vez, y a medida que cablea agents y automatizaciones sobre el CRM, el cambio pasa de molesto a «prácticamente imposible». El CRM go-live es casi una puerta de un solo sentido. El dry run es la forma de asegurarse de que abra hacia la habitación correcta.
Aquí está la distinción que grabaría en todo plan de migración. Hay dos tipos de confirmación, y los equipos recolectan sistemáticamente el primero y se saltan el segundo.
El primero es la confirmación de tareas: los datos están mapeados, los workflows construidos, las views configuradas, el deck de capacitación escrito. Es necesario y es lo que su plan de proyecto rastrea. El segundo es la confirmación del flujo: un registro real, que arranca donde arrancaría un cliente real, llega hasta el deal ganado, y cada stage, property, workflow y view que toca en el camino hace lo que debe. Casi nadie reserva tiempo para el segundo. Es el seguro más barato que puede comprar antes de un CRM go-live, y es el paso que se recorta cuando la fecha de launch se aprieta.
Un dry run no es una demo y no es un UAT en un sandbox donde el admin hace clic por los happy paths. Es un ensayo cronometrado y de punta a punta de todo el customer journey en el sistema que está por lanzar, ejecutado por las personas que son dueñas de cada parte, con la mirada puesta específicamente en qué se rompe.
Lo que recomiendo: bloquee dos horas, ponga un registro en la pantalla, y hágalo recorrer desde el primer contacto hasta el deal ganado frente a todo el equipo. Entra un lead. ¿Cae en la pipeline correcta? ¿El workflow que debería dispararse se dispara de verdad? Cuando el rep abre el contact, ¿ve la misma view que su colega, o hay cinco layouts distintos de modo que nadie mira los mismos datos? Cuando el deal cambia de stage, ¿se crea la siguiente acción? Cuando se gana, ¿se dispara el handoff hacia onboarding o service? No está probando si las piezas existen. Está probando si las piezas se conectan.
La razón para hacerlo en vivo, juntos y en voz alta es que las fallas viven en las costuras entre el trabajo de unos y otros. La persona que construyó el workflow de lead-routing y la que construyó las deal stages probaron cada una su propia pieza en aislamiento, y cada pieza pasó. El journey cruza ambas, y la rotura casi siempre está en la unión. Solo ve la unión cuando un registro recorre todo el camino en una sola sentada.
Hace poco trabajamos con una empresa B2B SaaS en Series B en la región DACH que migraba de Salesforce a HubSpot, con una fecha de go-live firme y un equipo de cara al cliente que nunca había tocado el nuevo setup. El plan de proyecto estaba en buena forma: mapping de datos con scope definido, workflows construidos, capacitación agendada.
De insistir en un dry run antes del cutover salieron dos cosas. Primero, al hacer recorrer un registro por el journey, varios workflows estaban construidos correctamente en aislamiento pero nunca se habían cableado al trigger que produce el customer journey real, así que un contact podía entrar y simplemente quedarse ahí, sin un paso siguiente. Un status sheet habría mostrado esos workflows como «hechos». El dry run los mostró como callejones sin salida. Segundo, el equipo no había planeado migrar las notas y la actividad históricas del sistema viejo, solo los registros abiertos. Suena razonable hasta que uno cae en cuenta de que el día uno un rep toma una cuenta activa, no ve historial, y abre en silencio el CRM viejo en otra pestaña para encontrarlo. En el momento en que su gente mantiene el sistema viejo abierto, la adoption ya está perdida, y está pagando dos CRM para operar uno. Atrapamos ambas cosas antes del launch porque recorrimos el journey, no la checklist.
- Reserve el dry run como su propio evento, antes del go-live. Dos horas, todo el equipo, agendado como una working session, no como un status call. Si no está en el calendario con un owner claro, lo aplastará la fecha de launch. Trátelo como un gate que el go-live tiene que pasar, no como un nice-to-have.
- Haga recorrer a un registro real desde el primer contacto hasta el cierre. Elija un escenario representativo y sígalo hasta el final: creación del lead, routing, calificación, cada stage, el cierre, y el handoff después del cierre. No salte a la parte interesante. En las transiciones aburridas se esconden los callejones sin salida.
- Pruebe las costuras, no las piezas. En cada handoff, pregúntese si lo siguiente se dispara: el workflow, la tarea, la notificación, el cambio de view, la asignación. Los objetos individuales ya los probó quien los construyó. Su trabajo en el dry run son las conexiones entre ellos.
- Migre el historial, no solo los registros abiertos. Decida de forma explícita qué historial de cliente pasa: notas, actividad pasada, contexto previo. Si los reps no pueden ver lo que ocurrió antes del go-live, mantendrán el sistema viejo abierto, y esa es la forma más rápida de perder la adoption. Si no puede traer todo, traiga lo suficiente para que ningún rep tenga motivo de reabrir el CRM viejo.
- Estandarice las views antes del launch, no después. Una view común y adecuada al rol, para que todos vean los mismos datos cuando comparten un registro. Mi regla: cambie la view según dónde está el registro en su lifecycle, no según quién lo mira. Un contact antes de ser cliente debería verse distinto de un contact que ya es cliente. Cinco layouts personales el día uno significan cinco personas hablando en paralelo la primera semana.
- Escriba la documentación desde la versión que funciona. Grabe el dry run y luego construya la guía de usuario a partir del flujo que acaba de confirmar, con screen grabs de los pasos reales. Una documentación escrita antes de confirmar el sistema documenta un sistema que todavía no existe.
- Agende el dry run temprano en el día, y reserve el tiempo de corrección después. Asuma que el dry run encontrará fallas, porque lo hará, y que algunas necesitarán nuevos workflows. Córralo en la mañana para que quien tiene que corregir todavía tenga la tarde. Un dry run sin tiempo de corrección reservado después es solo una lista de problemas que ahora conoce y no puede resolver antes del launch.
No necesita un programa formal para esto. Necesita dos horas, un registro, las personas correctas en la sala, y la disciplina de seguir todo el journey en lugar de las partes de las que está seguro. El dry run es la diferencia entre encontrar sus fallas en una working session agendada una semana antes del launch y encontrarlas en producción con un cliente en la línea. Una es barata. La otra le cuesta el go-live y una parte de su adoption.
Si está planeando un CRM go-live y quiere un partner que corra el dry run antes del cutover, esa es exactamente la clase de trabajo que hacemos: definir el scope de la migración, cablear los workflows y ensayar todo el customer journey antes de que alguien tenga que vender sobre él. Lea el artículo complementario sobre la brecha de adoption del CRM que se abre después del launch, o vea cómo abordamos las revenue operations de punta a punta.
- SaaStr. «The Modern GTM Org in 2026: Leaner, Flatter, and More Revenue Per Rep.» SaaStr, enero de 2026. saastr.com
- SaaStr. «Which CRM Should You Use in 2026/2027? Follow the Agents.» SaaStr, febrero de 2026. saastr.com
Carolina Decastri