La mayoría de los equipos que describen una «migración CRM» no están realmente cambiando de plataforma. Están heredando una instancia HubSpot o Salesforce que alguien más construyó, nunca documentó del todo, y luego entregó junto con un trimestre de números de revenue. La instancia funciona, apenas, y el modelo operativo está ahora restringido por ella. Eso es una migración CRM brownfield. Es una categoría distinta de proyecto a una instalación limpia, y fingir lo contrario es el error más caro que puede cometer en los primeros treinta días.
Por qué importa ahora
Los costes de cambio en CRM ya no son lo que eran. Como dijo Jason Lemkin en abril, a dos o tres agentes de IA, cambiar de CRM es molesto; a diez, es caro; a veinte, es funcionalmente imposible. El sistema que tolera hoy es el sistema en el que va a quedar bloqueado para la siguiente generación de agentes. El brief de febrero de Harvard Business Review sobre por qué las inversiones digitales no crean valor apuntaba a la misma causa raíz desde otro ángulo, el modo de fallo no es el tooling. Es el fallo en rediseñar cómo la organización comercial realmente genera insight, toma decisiones y coordina la acción. Una migración brownfield es, en la práctica, donde ese rediseño o sucede o se aplaza otros dos años.
La regla de la migración brownfield, no hay tabula rasa, así que construya la auditoría antes que la arquitectura
Una migración greenfield arranca desde un schema en blanco. Usted decide qué objetos existen, qué campos viven en ellos, qué asociaciones están permitidas, qué significan los stages del pipeline. Una migración brownfield arranca con varios años de decisiones de otra persona horneadas dentro de un sistema de revenue vivo. La mayoría de esas decisiones tenían sentido en su momento y ahora no. Algunas nunca fueron bien pensadas. Un número sorprendente resulta ser portante de carga en formas que nadie documentó.
La regla a la que sostenemos cada engagement brownfield es, no cambie nada en la arquitectura de datos hasta que haya triageado cada decisión existente. El triage no es opcional, y el triage es el proyecto. El cambio de plataforma es solo lo que sucede al final.
El framework keep / edit / delete
Para cada dato existente, cada campo existente, cada stage de pipeline existente, cada automatización existente, cada reporte existente, la respuesta es una de tres cosas:
- Keep. Aún sirve a un caso de uso comercial actual. No necesita rework. Está documentado, está cableado correctamente, y eliminarlo rompería un reporte o workflow aguas abajo que alguien está usando activamente.
- Edit. Sirve a un caso de uso actual pero la implementación está mal, el tipo de dato está mal, los valores son inconsistentes, o el workflow está parcialmente roto. Los edits se acotan, se asignan por nombre y se agendan antes de cualquier merge.
- Delete. Sirvió a un caso de uso que ya no existe, nunca se usó en primer lugar, o duplica algo más. Los deletes se revisan por impacto aguas abajo, luego se van.
Este framework parece ligero sobre el papel. El coste está en la disciplina. Cada propiedad, cada workflow, cada record type pasa por los tres cubos. Una instancia HubSpot B2B SaaS típica de etapa media carga entre varios cientos y varios miles de decisiones de triage individuales. El equipo que dice «lo iremos averiguando sobre la marcha» es el equipo que entrega la migración con la deuda intacta.
Dónde el framework se vuelve concreto
Tres lugares donde el frame keep / edit / delete se afila rápido en la práctica:
Stages de pipeline y definiciones de stage
La mayoría de los pipelines heredados tienen stages que significan cosas distintas para personas distintas. «Closed Won» a veces significa contrato firmado; a veces significa kickoff agendado; a veces significa revenue reconocido. La migración es el momento para forzar la definición. Edit, no delete, pero cada stage recibe una definición de una frase, un criterio de entrada, un criterio de salida y un owner.
Propiedades custom en Deal, Contact, Company
Las instancias brownfield acumulan propiedades custom aproximadamente al ritmo al que el equipo acumula ideas. Una auditoría seria normalmente elimina entre el 30 y el 50% de ellas. La pregunta diagnóstica para cada una, ¿quién la ha leído en los últimos 90 días, y qué decisión tomó a partir de ella? Si la respuesta es nadie y nada, se va.
Workflows y automatizaciones
La fuente más común de deuda brownfield son los workflows que se disparan sobre triggers ya deprecated, fijan campos que nadie usa, o notifican a antiguos empleados. Cada workflow se lee de extremo a extremo, se mapea su estado final y se triagea. Los workflows que sobreviven se renombran a una convención; el resto se pausa antes de que se mueva ningún dato.
Patrón desde el campo
Un equipo B2B SaaS de DACH en Series B nos llegó hace poco con dos portales HubSpot y una instancia Salesforce que necesitaban fundirse en un único sistema. El instinto fue cambiar de plataforma: levantar todo, dejarlo caer en un nuevo portal, entregar en ocho semanas. La forma real del proyecto, tras el triage, fue distinta. Aproximadamente el 38% de las propiedades custom legacy se marcaron delete en la primera pasada de auditoría. Otro 24% necesitaba edits, cambios de tipo, consolidación de picklists, recableado de workflow. El 38% restante se mantuvo tal cual. La instancia fusionada salió en producción con cerca de un tercio de la superficie de propiedades custom de los sistemas legacy combinados, y el primer trimestre de reporting sobre ella fue el primero en dos años que no requirió un paso manual de limpieza pre-pull. La migración no fue el speed-to-platform que acotamos al principio. Fue la limpieza.
Resolución, un playbook de migración brownfield
Para cualquier equipo a punto de heredar o fusionar una instancia HubSpot o Salesforce:
- Congele la arquitectura. Sin nuevas propiedades, sin nuevos workflows, sin nuevos stages de pipeline hasta que la auditoría esté completa. La auditoría dura más si sigue añadiendo a la superficie.
- Corra la pasada keep / edit / delete sobre cada objeto. Propiedades, pipelines, workflows, record types, membresías de lista, etiquetas de asociación. Documente la decisión en una hoja de cálculo que alguien esté dispuesto a defender.
- Concilie contra el sistema que de hecho conduce el revenue. Si tiene datos en dos sistemas, trate uno como fuente de verdad y conforme el otro a él. La migración no es el momento para debatir qué sistema gana.
- Arregle los workflows antes de mover los datos. Datos brownfield encima de automatización heredada es lo peor de los dos. Pause cada automatización que toque una propiedad que esté editando o eliminando; reescriba los supervivientes contra el schema post-auditoría.
- Escenifique la fusión en un sandbox. Las migraciones de producción se testean primero en sandbox, se validan contra un workload de reporting real, y solo entonces se agendan.
- Entrene sobre el sistema post-auditoría, no sobre el legacy. Una migración brownfield es un cambio de comportamiento para el equipo. La documentación escrita contra el sistema legacy fija la deuda legacy.
Si hace los pasos uno a seis, la migración real de datos es un viernes por la tarde. Si se los salta, la migración son los próximos doce meses.
Dónde entra Checkpoint
La razón por la que el framework keep / edit / delete aguanta bajo presión es que no es un póster de metodología, es el trabajo. Las migraciones brownfield son la mayor parte del trabajo CRM que hacemos en Checkpoint, y hemos corrido el ciclo de auditoría sobre suficientes herencias HubSpot, Salesforce y Pipedrive para saber qué decisiones aparecen cada vez y cuáles son genuinamente únicas a su stack. Si su migración brownfield arranca desde deuda heredada en lugar de un schema en blanco, hable con nosotros antes de elegir la plataforma, la decisión correcta de plataforma cae de la auditoría, no al revés.
Fuentes
- Sinha, Shastri, Lorimer. «Why Your Digital Investments Aren't Creating Value». Harvard Business Review, 16 de febrero de 2026. hbr.org
- Lemkin, Jason. «Which CRM Should You Use in 2026/2027? Follow the Agents». SaaStr, 6 de abril de 2026. saastr.com