TheFittClub — Wargame: Migración Legacy (Zenler → MVP)

Wargame — Migración de Ritual Core Legacy y sus usuarias al código propio

📋 Datos canónicos: NEGOCIO_SSOT. Este doc simula escenarios de fallo de la migración Zenler → MVP; no define datos numéricos canónicos.

Objetivo simulado (decisión de Gala, Jul 2026): Zenler se mantiene con pago mensual hasta que Ritual Core Legacy funcione completo en el MVP y las usuarias puedan migrar al código propio. La Fase 1 ya está montada; quedan por extraer de Zenler las fases 2, 3 y 4. De ese material se derivará después el nuevo Ritual Core con 3 versiones por sesión/día (Express, Base, Progressive). Al final del camino: usuarias migradas, Zenler apagado, y el producto de lanzamiento construido.

Datos reales de producción (Jul 2026): extraer la Fase 1 de Zenler costó 4 días; Gala estima ~4 días por fase para montar las 3 versiones por sesión. Aritmética resultante para fases 2-4: ~3×(4+4) = ~24 días de trabajo de contenido, más el desarrollo del MVP que ahora mismo tiene prioridad (el MVP debe servir Ritual Core Legacy primero). Hito declarado: Ritual Core Legacy en marcha en Septiembre 2026, con las usuarias legacy como beta users — la beta del plan (Fase 3 del roadmap) deja de ser un reclutamiento de 20 testers y pasa a ser el propio cohorte legacy usando el producto real. La secuencia completa de escenarios post-septiembre vive en Plan_Escenarios.

Por qué este wargame condiciona a todos los demás: es el camino crítico del calendario. Lanzamiento_Ritual no puede fijar fecha sin el producto derivado de aquí, y cada mes que la migración se alarga es una mensualidad más de Zenler drenando el runway. Además, las 114 alumnas legacy (más 41 colaboradoras) son el segmento más caliente del negocio: la migración bien hecha es también el primer contacto de reactivación con las mejores clientas históricas — testimonios, beta testers y embajadoras salen de aquí.

---

PASO 1 — Inventariar y extraer las fases 2-4 de Zenler

• MOVIMIENTO: Inventario completo del contenido de las fases 2-4 en Zenler (courseIDs 136001, 136003, 136005): nº de sesiones, duración, calidad de vídeo, materiales anexos. Descarga sistemática con checklist, verificando cada archivo (la pérdida del portátil de Mayo 2026 ya enseñó que los vídeos locales sin backup no existen).
• OBSERVACIÓN ESPERADA: El 100% del material descargado, verificado y respaldado (local + nube) con un inventario que diga exactamente qué hay y en qué estado.
• FALLO MÁS PROBABLE: El material antiguo no cumple el estándar visual actual de la marca (fue grabado en 2023 para otro contexto): resolución, luz o audio por debajo de lo que el brand book exige hoy. La tentación de “ya lo arreglaré en edición” esconde semanas de trabajo no presupuestado.
• CONTRAMEDIDA: Triaje explícito en el inventario: cada sesión se clasifica A (publicable con edición de plantilla), B (rescatable con retrabajo) o C (necesita re-grabación). El presupuesto de horas se calcula sobre esa clasificación real, no sobre el supuesto de que todo es A.
• BIFURCACIÓN: Si ≥80% del material es A/B → seguir pipeline con presupuesto ajustado. Si hay un bloque C significativo → decisión de calendario inmediata (regla nº1: calidad sobre calendario): re-grabar solo lo C crítico para la progresión y aplazar lo accesorio, antes que retrasar todo el lanzamiento por perfeccionismo uniforme.

PASO 2 — Montar Ritual Core Legacy completo en el MVP

• MOVIMIENTO: Integrar las fases 2-4 en el MVP bajo el producto prod_ritual_core_legacy (shell y entitlement ya definidos en T204), respetando la ley de cohorte: solo quienes pagaron íntegra una edición de “Core y Suelo Pélvico Poderosos” (clasificador + mapa de precios en legacy-membership.ts).
• OBSERVACIÓN ESPERADA: Una usuaria legacy puede completar las 4 fases en el MVP con la misma progresión que tenía en Zenler; el clasificador de cohorte asigna acceso correcto en el 100% de los casos de prueba (incluidos los bordes: pagos fraccionados completados, abandonos de cuotas, colaboradoras).
• FALLO MÁS PROBABLE: Los casos borde del entitlement se resuelven mal en silencio: una alumna que pagó íntegro no ve su acceso (enfado de la mejor clienta posible) o una que abandonó cuotas sí lo ve (regala el producto). Con datos de ventas de 2023-2025 en exports heterogéneos, los bordes son más numerosos de lo que parece.
• CONTRAMEDIDA: QA con la lista real antes de abrir la puerta: correr el clasificador contra el export completo de ventas y revisar a mano los casos dudosos (son decenas, no miles — es revisable). La regla ante la duda es generosa hacia la clienta con historial de pago: el coste de regalar un acceso dudoso es cero; el de negárselo a quien pagó, altísimo.
• BIFURCACIÓN: Si el QA sale limpio → abrir migración (Paso 4). Si aparecen >5-10% de casos dudosos → congelar la migración de usuarias, resolver el mapa de precios/ediciones primero, y solo entonces invitar — una primera impresión de acceso roto en este segmento no tiene segunda oportunidad.

PASO 3 — Derivar Ritual Core (3 versiones por sesión) sin triplicar la producción

• MOVIMIENTO: Producir el nuevo Ritual Core a partir del material legacy: por cada día de sesión, versión Express (5m), Base (20m) y Progressive. Estimación de Gala: ~4 días de trabajo por fase para el montaje de versiones (más ~4 días por fase de extracción, calibrado con el dato real de Fase 1). Validar la estimación con la primera fase que se monte, cronometrada.
• OBSERVACIÓN ESPERADA: La primera fase montada confirma el ~4 días/fase: las 3 versiones salen como cortes y recombinaciones del mismo máster (Express = subconjunto de bloques de Base; Progressive = Base + bloques de intensidad), no como tres ediciones independientes.
• FALLO MÁS PROBABLE: La estimación se hizo sin haber montado aún ninguna fase en 3 versiones: si el real es 8-10 días/fase (versiones que exigen edición propia, o el estándar de marca alarga cada corte), las fases 2-4 pasan de ~24 a ~40-50 días de trabajo — y como el MVP tiene prioridad ahora mismo, el hito de Septiembre se come el margen sin que nadie lo decida explícitamente.
• CONTRAMEDIDA: Cronometrar la primera fase real y recalcular el calendario con ese dato, no con la estimación. Diseño modular antes de editar (bloques calentamiento/principal/cierre alineados con la rutina de 3 series del producto) para que los cortes se reutilicen entre versiones. Si el real supera ~6 días/fase, recortar alcance de lanzamiento: lanzar con Express+Base y añadir Progressive post-lanzamiento como mejora anunciada — nadie cancela por recibir más contenido después.
• BIFURCACIÓN: Si la primera fase confirma ≤4-5 días/fase → producción en masa con calendario verificable. Si da >6 días/fase → lanzamiento con 2 modalidades (decisión de alcance, no de calidad) y Progressive en el roadmap post-lanzamiento; actualizar Lanzamiento_Ritual Paso 1(d) y Plan_Escenarios con el nuevo alcance.

PASO 4 — Migrar a las usuarias legacy al código propio

• MOVIMIENTO: Invitación por oleadas al segmento legacy: email personal (es el segmento que justifica el toque manual de Gala), acceso vitalicio respetado en el MVP, y un incentivo de bienvenida que solo existe en la app nueva (p. ej. los marcadores de bitácora o una sesión extra). Ventana larga con Zenler aún encendido como red de seguridad. Las migradas son las beta users oficiales del MVP (decisión Jul 2026): su uso real valida producto, player, bitácora y onboarding antes del lanzamiento de Ritual Core.
• OBSERVACIÓN ESPERADA: ≥50-60% del segmento activa su cuenta en el MVP en 4-6 semanas; las activas más comprometidas emergen como candidatas naturales a testimonios, métricas de beta (completado, NPS) y primeras embajadoras (Reactivacion_Audiencia, Club_Embajadoras).
• FALLO MÁS PROBABLE: Las usuarias no completan la migración: compraron en 2023-2025, muchas ya no consumen el contenido, sus emails están fríos y “crearte una cuenta nueva” es fricción sin urgencia. Un 20-30% de activación deja a la mayoría del segmento atrapada en un Zenler que no se puede apagar.
• CONTRAMEDIDA: Reducir la migración a 1 clic (enlace mágico pre-vinculado a su compra, sin formulario) y secuencia multi-toque (email + recordatorio + último aviso con fecha). Aceptar de antemano que una fracción del cohorte está inactiva para siempre: el objetivo real es migrar a todas las que consumen, no al 100% del censo — medir consumo en Zenler para saber cuántas son.
• BIFURCACIÓN: Si las consumidoras activas migran (aunque el total sea <50%) → fijar fecha de corte con aviso de 30-60 días y pasar al Paso 5. Si ni siquiera las activas migran → el problema es el flujo de alta del MVP (fricción o desconfianza), no la apatía: arreglar el enlace mágico/onboarding antes de insistir con más emails.

PASO 5 — Apagar Zenler

• MOVIMIENTO: Con paridad de contenido verificada (4 fases en MVP) y las activas migradas: aviso formal de cierre con fecha (30-60 días), recordatorios, y cancelación de la suscripción mensual de Zenler.
• OBSERVACIÓN ESPERADA: El apagado pasa sin incidencias: cero quejas de acceso perdido de alumnas con derecho, y el coste mensual desaparece del runway.
• FALLO MÁS PROBABLE: Un corte prematuro o mal comunicado rompe la promesa de “acceso vitalicio” ante las clientas fundadoras de la marca — exactamente el segmento del que saldrán testimonios, embajadoras y boca a boca. El precedente del cierre de la membresía (aviso público de un mes, Nov 2025) ya marca el estándar mínimo de comunicación que este segmento espera.
• CONTRAMEDIDA: Checklist de apagado innegociable: paridad de contenido verificada sesión a sesión + toda alumna que accedió a Zenler en los últimos 90 días ya migrada o contactada personalmente + canal de rescate post-cierre (email de soporte que restaura acceso en <48h). El ahorro de 1-2 mensualidades extra nunca justifica quemar la confianza del núcleo histórico.
• BIFURCACIÓN: Si tras el aviso formal aparecen usuarias activas sin migrar → extender Zenler 1 mes más (coste conocido, daño evitado) y contacto personal. Si tras la extensión ya no queda actividad → apagar y archivar el export final completo (contactos + ventas + consumo) como backup permanente.

---

CONDICIONES DE ABORTO

Aquí “abortar” significa replantear el camino de migración — el destino (salir de Zenler, producto propio) no está en cuestión, pero el cómo y el cuándo sí:

1. La aritmética del Paso 3 mata el calendario: si el piloto de derivación demuestra que ni siquiera el recorte a 2 modalidades permite lanzar antes de la primavera de 2027 (línea de Lanzamiento_Ritual, atada al pago único del paro), se detiene la producción en masa y se replantea el alcance del producto de lanzamiento desde cero (¿lanzar con RCL remozado y construir Ritual Core después?) antes de seguir quemando semanas de edición.
2. El material legacy es mayoritariamente clase C (re-grabación) en el triaje del Paso 1: el supuesto fundacional del plan (“60 sesiones ya filmadas = 3-4 meses de ventaja”) es falso en la práctica. Parar y re-presupuestar todo el proyecto de contenido con números de grabación real — decidir con el calendario y el runway delante, no descubrirlo a mitad.
3. Coste de Zenler fuera de control: si a los 6 meses de la decisión (Ene 2027) la migración no tiene fecha de fin creíble, el pago mensual “temporal” se ha vuelto estructural. Sentarse con el acumulado gastado y decidir en frío: sprint final con fecha dura, o export completo + apagado anticipado asumiendo la pérdida de la red de seguridad. Lo único prohibido es la deriva indefinida — un coste recurrente sin fecha de fin es un agujero en el runway, no una herramienta.
4. Línea roja reputacional (siempre activa): Zenler jamás se apaga sin paridad de contenido verificada y sin el protocolo de aviso del Paso 5, aunque todas las demás presiones (coste, calendario) empujen a ello. Las alumnas legacy son el activo de confianza más antiguo del negocio.