Cuando tu Migración se Convierte en una Plataforma: Crecimiento de Alcance Bien Hecho

Nos contrataron para migrar 377 objetos de BI heredados. Terminamos entregando una plataforma analítica de 161 modelos en 7 dominios. El alcance creció casi 5x en cinco meses.

Eso no es una historia de advertencia. Es lo que se ve una buena arquitectura desde afuera.

Cada artículo de gestión de proyectos en internet habla de cómo prevenir el scope creep. Nadie escribe el caso a favor del crecimiento de alcance cuando es, de hecho, el resultado correcto — porque la infraestructura original fue diseñada para soportarlo. Acabamos de terminar uno de esos proyectos. Aquí está cómo se vio, por qué seguimos diciendo que sí, y el marco que usaríamos para decidir exactamente igual otra vez.

Cuál era el alcance original

El proyecto arrancó en noviembre de 2025. Una empresa SaaS de seguridad en la nube necesitaba migrar la lógica de BI heredada — 377 objetos distribuidos en una plataforma BI legacy que había calcificado durante cinco años — a un stack moderno de dbt + Snowflake + Sigma.

El objetivo inicial era analytics de ingresos basados en metering para una sola línea de producto: datos de uso de 12 regiones en la nube, consolidados en modelos de facturación que Finance pudiera confiar. Todo lo heredado del sistema legacy necesitaba aterrizar en dbt con paridad validada contra montos históricos facturados.

Eso era todo. Un dominio. Un producto. Un equipo de stakeholders directos.

La estructura del proyecto dbt que establecimos se veía así:

models/
├── staging/
│   └── product_alpha/          # 12 vistas regionales de metering
├── intermediate/
│   └── product_alpha/          # deduplicación, unión, enriquecimiento
└── marts/
    └── product_alpha/          # hechos de facturación, ARR, dimensiones

Para finales de noviembre, el MVP estaba corriendo: macros de precios por niveles, vistas regionales de staging, cálculo de ingresos netos, metas ELA. Dos semanas del primer commit a tablas de hechos funcionales.

Para finales de marzo, ese proyecto había crecido a 161 modelos en 7 dominios.

Las expansiones, una por una

Diciembre: Profundidad de validación

La primera expansión no fue de nuevos dominios — fue de profundidad. Probar paridad con varianza de 0.002% en el conjunto completo de datos de ingresos de ingresos históricos requirió más modelos de los que el spec original anticipaba: modelos de ARR, tablas de dimensiones, tablas de hechos desagregadas con formato específico para Sigma, parches de archivo para cubrir huecos históricos.

A esto se le podría llamar scope creep. Nosotros lo llamamos trabajar desde el requerimiento real hacia atrás.

"Migramos los datos" no es lo mismo que "Finance puede confiar en estos números." El trabajo de modelado adicional fue lo que cerró esa brecha. Sin él, el proyecto completo habría terminado con una migración técnicamente completa que nadie se atrevía a usar.

La inversión estructural rindió sus frutos: los patrones de validación que construimos en diciembre — queries de varianza con full outer join, debugging a nivel de granularidad, secuenciación con paridad primero — se trasladaron a cada expansión posterior. Cuando llegamos a los precios FY27 en enero, ya teníamos la infraestructura de validación para correrlo con 0.00% de varianza por lote.

Enero: Sprint de precios FY27

En enero, el equipo de Finance tenía una fecha límite inamovible: los nuevos precios del año fiscal necesitaban estar en producción antes de que abrieran las reservas del Q1. Nuevas tarifas por nivel, 11 multiplicadores regionales, una jerarquía de descuentos reestructurada.

Esto estaba claramente fuera del alcance original de la migración. Dijimos que sí por dos razones.

Primero, la arquitectura lo soportaba. El patrón de aislamiento por dominio que habíamos establecido — cada dominio de producto en su propio schema, sin dependencias cruzadas entre dominios — significaba que un nuevo modelo de precios podía coexistir con los modelos de ingresos existentes sin tocarlos. No tuvimos que refactorizar nada para agregar esto.

models:
  project_name:
    staging:
      product_alpha:
        +schema: slv_product_a
      pricing_fy27:
        +schema: slv_pricing_fy27
    marts:
      product_alpha:
        +schema: gld_product_a
      pricing_fy27:
        +schema: gld_pricing_fy27

Segundo, la capacidad del equipo de Finance para confiar en los nuevos modelos de precios dependía de que estuvieran junto a los modelos de ingresos validados que acababan de aprobar. No puedes validar los precios FY27 de forma aislada de los datos de ingresos que los precios están diseñados para generar. Tenían que coexistir.

Entregamos en 9 lotes a lo largo de 9 días. La historia de cómo corrimos ese sprint está documentada por separado aquí. La versión corta: entrega por lotes con puertas de validación entre cada uno, tablas de precios impulsadas por seeds en lugar de macros con valores fijos, y Finance en el ciclo de QA desde el día uno.

Febrero: Expansión de la plataforma

Febrero es donde la historia del alcance se pone interesante.

El proyecto original tenía un dominio de producto. En febrero, el equipo preguntó si la misma infraestructura podría soportar analytics para otras líneas de producto — detección de amenazas, telemetría de plataforma, analytics de agentes, y una fuente de datos de segmentos del front-end que había estado corriendo en su propio stack de reportes.

La pregunta era "¿pueden evaluar si esto es factible?" Resultó ser más que factible.

Porque habíamos establecido un patrón claro de aislamiento por dominio — modelos de staging por dominio, enrutamiento de schemas, sin contaminación cruzada — agregar nuevos dominios era aditivo, no invasivo. Cada nuevo dominio obtuvo su propio nivel de schema y pudo desarrollarse e implementarse de forma independiente de todo lo que ya estaba corriendo.

models/
├── staging/
│   ├── product_alpha/
│   ├── product_beta/         # agregado en feb
│   ├── product_platform/     # agregado en feb
│   ├── product_agent/        # agregado en feb
│   └── product_gamma/        # agregado en feb
├── intermediate/
│   └── [refleja la estructura de staging]
└── marts/
    └── [refleja la estructura de staging]

Este es exactamente el escenario para el que está diseñado el aislamiento por dominio. Los dominios existentes siguieron corriendo. Los nuevos dominios se activaron sin una migración big-bang. El equipo de ingeniería pasó de 1 a 4 colaboradores, cada uno con su propio dominio, sin pisarse los pies.

También agregamos dos capacidades que no estaban en el alcance original: una app de Streamlit-in-Snowflake para consultas semánticas (lenguaje natural contra datos de ingresos vía Cortex Analyst), y una migración del flujo de tablas de entrada de Sigma para que Finance pudiera ajustar precios sin involucrar a ingeniería.

Ninguna de las dos estaba en el spec original. Las dos surgieron cuando el equipo entendió, después de cuatro meses trabajando juntos, lo que era realmente posible con la infraestructura que ahora tenían.

Cómo lo gestionamos operacionalmente

Decir que sí al crecimiento de alcance es fácil. Gestionarlo sin degradar lo que ya se entregó es la parte difícil.

Tres prácticas mantuvieron el proyecto coherente durante cinco meses y 161 modelos en 7 dominios.

Seguimiento de hitos con puertas de validación explícitas. Cada fase terminó con un hito formal de validación antes de empezar la siguiente. El hito de validación de ARR de diciembre ("0.002% de varianza en el conjunto completo de datos de ingresos — completo") quedó commiteado al repositorio junto con el código que lo logró. El hito de precios FY27 de enero ("los 9 lotes validados — completo") se registró de la misma manera. La historia del proyecto es legible en el log de commits.

# PLAN.md (fragmento, hito de enero)

## Sprint de Precios FY27

Status: COMPLETE ✓

Lotes entregados:
- Lotes 1-2: Seeds + macros de precios base ✓
- Lotes 3-4: Multiplicadores regionales + fix JOIN+QUALIFY en Snowflake ✓
- Lote 5: Modelos de ingresos v2 impulsados por seeds — validado 0.00% ✓
- Lotes 6-7: Descuentos por cuenta con retroalimentación de Finance ✓
- Lote 8: [bloqueado por datos de partners — omitido, completado con Lote 9] ✓
- Lote 9: Modelos de ARR con descuentos FY27 — 265,638 filas, 0.00% de varianza ✓

Aprobado por Finance: 2026-01-31

Aislamiento por dominio como restricción de primer orden. Aplicamos una regla desde la semana uno: ningún modelo en el dominio A puede hacer ref() a un modelo en el dominio B. Cada mart es autocontenido. Los datos de consulta compartidos (calendario fiscal, metadatos regionales) viven en tablas seeds compartidas, no en los modelos de otro dominio.

Esto suena a disciplina por disciplina. Se convierte en una característica de continuidad del negocio cuando el alcance crece. Cuando la expansión de febrero agregó cuatro nuevos dominios, ninguno de ellos requirió tocar los modelos de facturación existentes. Los dashboards del equipo de Finance siguieron corriendo. Los nuevos dominios se desarrollaron en paralelo.

Comunicar los cambios de alcance como paquetes de trabajo distintos. Cuando acordamos el sprint de precios FY27 y la expansión de la plataforma, enmarcamos explícitamente cada uno como un nuevo paquete de trabajo con su propio alcance, cronograma y criterios de aceptación — no como una extensión del proyecto original. Esto importó por dos razones: le dio al equipo hitos claros que celebrar, y facilitó decir "eso es una pregunta para la Fase 4" cuando surgía algo durante la Fase 3.

Cuándo decir que sí, cuándo decir que no

Después de cinco meses navegando esto, aquí está el marco que volveríamos a usar.

Di que sí cuando:

El trabajo nuevo es arquitectónicamente aditivo. Si puedes agregarlo sin modificar lo que ya está corriendo, el riesgo es bajo y el beneficio es alto. Nuevos dominios en una arquitectura multidomain con aislamiento son el caso más claro.

El trabajo nuevo comparte una dependencia de validación con el trabajo existente. Si los modelos de precios FY27 necesitaban estar junto a los modelos de ingresos para validarse, eso no es scope creep — esa es la forma natural del problema.

El trabajo nuevo siempre estuvo implícito en el alcance. "Migrar los datos" implícitamente requería "Finance puede confiar en los números", lo que requería más profundidad de validación de la que estimaba el spec original. Eso no es crecimiento de alcance. Eso es descubrir el alcance real.

La confianza del cliente en tu trabajo es lo que impulsa la decisión, no la inercia organizacional. Cuando un equipo pide más porque el primer entregable funcionó, esa es una conversación diferente a cuando el alcance crece porque nadie tenía un spec claro desde el principio.

Di que no cuando:

El trabajo nuevo requiere modificar entregables ya validados. Si agregar un nuevo dominio implica tocar los modelos de facturación que Finance ya aprobó, estás asumiendo un riesgo que no puedes costearte fácilmente. Protege lo que ya está validado.

El trabajo nuevo no tiene un dueño claro. Cada expansión en este proyecto tuvo un stakeholder nombrado que iba a usar el resultado y firmar el visto bueno. Si nadie lo tiene, no se define bien el alcance, no se valida ni se entrega correctamente.

El cronograma está dictando el alcance en lugar del alcance dictar el cronograma. Si la petición es "¿puedes agregar esto para fin de mes?" y la respuesta honesta es "solo si recortamos esquinas", ahí es cuando el scope creep deja de ser productivo. La respuesta honesta a esa pregunta importa más que el sí.

El alcance original todavía no está validado. No expandas antes de haber probado la paridad en lo que ya construiste.

El proyecto que empezó como "migrar 377 objetos de BI heredados" terminó como una plataforma de analytics de ingresos con 161 modelos en 7 dominios, herramientas de autoservicio para Finance, un prototipo de capa semántica y un flujo de desarrollo que cuatro ingenieros podían usar de forma independiente.

Nada de eso estaba en el spec original. Todo fue construido sobre una arquitectura que hizo posible decir que sí con seguridad.

Eso es el crecimiento de alcance que vale la pena tener.