La mayoría de los proyectos de migración de CRM eligen una plataforma antes de elegir un arquetipo. Ese es el orden equivocado. Si está ejecutando una migración greenfield o brownfield cambia el scope, timeline, equipo y perfil de riesgo más de lo que lo hace la elección de plataforma. La decisión de plataforma es aguas abajo de la decisión de arquetipo. Equivóquese de arquetipo y gastará los siguientes doce meses explicando por qué el proyecto se salió del scope, aunque cada workstream técnicamente entregó.
Por qué importa ahora
Los costes de switching en CRM están subiendo rápido. La nota de abril de Jason Lemkin en SaaStr hizo el punto sin rodeos, a dos o tres agentes de AI, cambiar de CRM es molesto; a diez, caro; a veinte, funcionalmente imposible. La arquitectura a la que migra hacia, schema limpio o deuda heredada, se queda fijada junto con la plataforma. Una migración brownfield mal etiquetada como greenfield envía deuda heredada hacia la próxima década. Una migración greenfield que debería haber sido brownfield quema el funnel de inbound camino a un schema que nadie pidió. La decisión de arquetipo es donde se establece ese lock-in.
Los tres arquetipos de migración
Reconstrucción limpia (greenfield)
Una nueva entidad, un nuevo dominio, un nuevo ICP, o una decisión deliberada de abandonar el sistema legacy. El schema se diseña hacia adelante contra el modelo operativo actual. No hay debate sobre source-of-truth porque no hay segunda fuente. El histórico de marketing-attribution, si existe, se trata como un archivo de solo lectura más que como una restricción viva. Greenfield es raro en empresas con más de dos años.
Limpieza de sandbox (semi-greenfield)
El sistema legacy se queda, pero el equipo ha aceptado que la instancia de producción es irrecuperable como está. La migración es a un portal construido en sandbox con un cutover deliberado. Algo de histórico se mueve; la mayoría de la automatización no. El arquetipo más común para equipos Series A o B que construyeron rápido en el año uno y ahora necesitan un schema real para el año tres. Parece greenfield desde fuera, corre como brownfield por dentro.
Brownfield merge
Dos o más sistemas en vivo: típicamente HubSpot, Salesforce, Pipedrive, más una herramienta de marketing-automation: convergen en una sola instancia sin perder histórico, atribución, o los workflows de los que el equipo depende actualmente. La migración es la auditoría; la auditoría es el proyecto. El framework keep / edit / delete para triagiar una instancia heredada se cubre en un post anterior, ese trabajo ocurre después de la decisión de arquetipo, no en lugar de ella.
Las tres preguntas que eligen el arquetipo
La hoja de decisión es corta, tres filas, cada una respondida honestamente. Dos de tres apuntando en la misma dirección es suficiente para comprometerse.
1. Valor del histórico, ¿cuánto de los datos del sistema legacy es load-bearing para el trabajo comercial actual?
Si la atribución de marketing, el histórico de ownership, o las analíticas del pipeline están dirigiendo activamente forecasts, motions de renovación, o reporting de board, el histórico es load-bearing y está en territorio brownfield. Si el sistema legacy es principalmente una lista de contactos con workflows a medio construir en los que nadie confía, el histórico es de archivo y greenfield está sobre la mesa. Diagnóstico, ¿quién ha leído estos datos en los últimos 90 días, y qué decisión tomó a partir de ellos?
2. Presión de plazos, ¿puede el funnel de inbound apagarse durante un trimestre?
Una reconstrucción limpia típicamente cuesta al funnel de inbound un trimestre de continuidad de atribución. Si tiene el runway y el respaldo de liderazgo para eso, greenfield es viable. Si los números de revenue, board reviews, o un fundraise están anclados al pipeline marketing-sourced del próximo trimestre, brownfield está forzado, independientemente de cuán limpia se vería una reconstrucción sobre el papel. Nadie debería descubrir en el mes cuatro que el forecast del CRO no puede sobrevivir un trimestre de atribución apagada.
3. Scope de deuda de schema, ¿cuánto de la implementación legacy está activamente mal?
Una auditoría seria de una instancia heredada de HubSpot o Salesforce normalmente marca el 30–50% de las propiedades custom para borrar y otro 20–30% para editar. Si el schema legacy es mayormente defendible: las definiciones aguantan, los workflows disparan en triggers actuales, las etapas significan lo que dicen, brownfield es un proyecto más pequeño de lo que parece. Si el schema es mayormente indefendible, el cálculo de coste-de-historia se invierte: está pagando precios de auditoría brownfield por trabajo de limpieza greenfield, y el arquetipo sandbox-cleanup es la respuesta correcta. Diagnóstico, un paseo de treinta minutos por la lista de propiedades con la persona que la construyó. Si no puede defender la mitad de sus campos, el schema es el proyecto.
Por qué los mergers caen por defecto en brownfield aunque greenfield sea más limpio
Las consolidaciones de CRM post-merger casi siempre presentan un argumento limpio de greenfield en la pizarra: nueva entidad combinada, nuevo ICP, nuevo positioning, nuevo dominio. El argumento se cae en la primera conversación de scoping. Uno de los dos sistemas siempre lleva histórico que nadie está dispuesto a abandonar, meses de atribución de marketing, un programa activo de partners construido sobre association labels, una definición de lifecycle-stage contra la que el equipo de renovaciones está haciendo forecasting. El coste de apagar cualquiera de esos durante un trimestre es mayor que el coste de heredar la deuda de schema. Greenfield es técnicamente posible. Brownfield es lo que se entrega.
Cómo se ve una decisión equivocada a 90 días vista
Los dos modos de fallo son imágenes especulares uno del otro.
Greenfield-cuando-debió-ser-brownfield: el nuevo portal está limpio, el schema es correcto, y nadie confía en los números porque la cadena de atribución se rompió en el cutover. Los reports del nuevo sistema no coinciden con los del viejo en el periodo solapado. El CRO hace forecast desde el export legacy durante dos trimestres mientras el equipo reconstruye la atribución. Técnicamente exitoso y comercialmente invisible.
Brownfield-cuando-debió-ser-greenfield: el portal fusionado funciona, pero lleva quince lifecycle stages donde debería haber cinco, tres deal pipelines que significan lo mismo con nombres de etapa distintos, y mil propiedades custom de las cuales un tercio no se usan. Cada workflow nuevo toma el doble porque tiene que navegar deuda heredada. Dieciocho meses después contratan a otra persona para migrar la migración.
Patrón de campo
Un equipo B2B SaaS en DACH en Series B vino recientemente con lo que parecía un caso textbook de greenfield: dos empresas fusionándose, nuevo dominio, nuevo ICP, positioning fresco. El instinto de pizarra era una reconstrucción limpia: nuevo portal en ocho semanas, ambos sistemas legacy retirados en el día del cutover. La hoja de decisión no estuvo de acuerdo. Valor del histórico: uno de los dos portales llevaba aproximadamente dieciocho meses de datos de marketing-attribution sobre los que el funnel de inbound estaba corriendo activamente. Presión de plazos: los próximos dos trimestres tenían un número de pipeline anclado al board atado a ese funnel. Scope de deuda de schema: desordenado pero defendible, la mayoría de las propiedades tenían owners, la mayoría de los workflows disparaban en triggers actuales. Dos de tres filas apuntaban a brownfield. La decisión cambió en la primera sesión de scoping. El proyecto se entregó como un brownfield merge contra el más limpio de los dos portales; el funnel de inbound no se apagó; la limpieza de schema ocurrió en la fase de auditoría. Ocho semanas después el equipo tenía una sola instancia con aproximadamente un tercio del área de superficie de propiedades custom legacy y una cadena de atribución contra la que el CRO podía hacer forecast.
Resolución, el playbook de decisión de arquetipo
Antes de cualquier decisión de plataforma, antes de cualquier movimiento de datos, antes de cualquier kickoff:
- Ejecute las tres preguntas diagnósticas en una sola página. Valor del histórico, presión de plazos, scope de deuda de schema. Dos columnas: greenfield-leaning, brownfield-leaning. Fuerce una respuesta binaria por fila.
- Recorra la lista de propiedades con la persona que la construyó. Treinta minutos, sin slides. Si pueden defender la mayoría de sus campos, el schema es brownfield-recoverable. Si no pueden, sandbox-cleanup está sobre la mesa.
- Verifique la cadena de atribución contra los próximos dos trimestres de forecast. Si el número de pipeline marketing-sourced ancla un board review o un fundraise, brownfield está forzado, escríbalo antes de la conversación de plataforma.
- Nombre el arquetipo en voz alta, por escrito, con el CRO y el head of marketing en la sala. Una migración donde el liderazgo no puede ponerse de acuerdo en el arquetipo se mis-scopeará a sí misma para el mes tres.
- Elija la plataforma al final. La plataforma correcta para una reconstrucción greenfield no es siempre la plataforma correcta para un brownfield merge. El arquetipo estrecha la shortlist de plataforma.
- Re-teste el arquetipo en la semana seis. Si un proyecto brownfield está produciendo más decisiones de delete que de keep, puede ser un sandbox-cleanup mal etiquetado como brownfield merge. Detectar eso en la semana seis cuesta un re-scope; detectarlo en el mes cuatro cuesta el timeline.
Dos de tres filas apuntando en la misma dirección es suficiente para comprometerse. Una de tres es la conversación que vale la pena ralentizar. Cero de tres es un proyecto que aún no se ha scopeado.
Dónde entra Checkpoint
La decisión de arquetipo es la conversación más apalancada en cualquier migración de CRM. Acertarla y el resto del proyecto es ejecución. Equivocarla y cada decisión aguas abajo compone el mis-scope. Checkpoint ejecuta la hoja de decisión de tres preguntas en cada compromiso de migración de CRM antes de cualquier conversación de plataforma. Si no puede decir con confianza cuál de los tres arquetipos es su proyecto, esa es la conversación que tener primero.
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