# Armado de la solución de migración del escritorio a la nube

> Guía para partners, distribuidores y desarrolladores que van a implementar, vender o construir sobre la solución de migración descrita en [Migrar del escritorio a la nube sin romper la operación](https://docs.induxsoft.net/es/todos-los-productos-y-servicios/migracion-escritorio-nube.md).

## Qué arma esta solución

Una transición ordenada y gradual de la operación de un cliente desde aplicaciones de escritorio (típicamente R5 o V10) hacia una operación basada en V12 y la plataforma web del ecosistema Induxsoft. La solución acepta múltiples ritmos de migración: completa de un solo movimiento para clientes chicos, gradual por función para clientes medianos, y multifase con piloto para clientes grandes o complejos. La continuidad operativa se preserva en todos los casos, con convivencia de versiones cuando hace falta.

## Piezas del ecosistema utilizadas

**R5 y V10 como sistemas de origen**: los productos de escritorio existentes del cliente. Pueden ser MaxiComercio R5, Déminus R5, VenDesk SE (V10), Nómina SE (V10), Contabilidad SE (V10), CFDI Explorer u otros. El partner no instala estos; ya están operando en el cliente. La migración los toma como punto de partida.

**V12 como plataforma de destino**: la plataforma web del ecosistema. Sobre V12 corren las versiones web de MaxiComercio, Déminus, VenDesk, los módulos de tienda en línea, intranet, agenda multicalendario, gestión multi-sucursal y los verticales como iMedik Cloud.

**MaxiPOS** para puntos de venta web que se incorporan durante la migración (sucursales nuevas, cajas adicionales, operación móvil).

**Plataforma IAE** que se suma típicamente como parte del proyecto de migración: el cliente que moderniza casi siempre quiere agregar agentes conversacionales que el escritorio no podía soportar.

**Herramientas de migración de datos**: scripts y procesos de Induxsoft para transferir clientes, productos, proveedores, históricos de transacciones, configuraciones y catálogos del sistema origen al sistema destino. La capacidad y el alcance varían según el sistema origen y deben validarse caso por caso.

**Conectividad híbrida**: durante el periodo de convivencia, R5 (o V10) y V12 pueden compartir el mismo motor de datos o sincronizarse en tiempo real. El partner configura esta convivencia según la estrategia de migración del cliente.

**Capacidades fiscales nativas en México y proveedores fiscales locales en otros países** que migran con el cliente o se reconfiguran en el destino.

## Combinaciones según el perfil del cliente

### Cliente chico (operación unipersonal o de equipo pequeño con sistema de escritorio antiguo)

**Estrategia:** migración completa en un solo movimiento.

**Stack destino:** V12 con los módulos equivalentes a lo que tenía + MaxiPOS si necesita punto de venta + cumplimiento fiscal local + (opcional) agente IAE para WhatsApp.

**Notas de armado:**
- No vale la pena la complejidad de convivencia para este perfil. Migración limpia.
- Validar antes del proyecto qué se migra y qué se queda. Si hay datos históricos antiguos que el cliente no consulta, dejarlos archivados en el sistema viejo sin migrarlos al nuevo.
- Capacitar al cliente en una o dos sesiones. La curva de aprendizaje es razonable porque la lógica de negocio es la misma.
- Asegurar respaldo del sistema viejo antes de apagarlo. Mantenerlo accesible (aunque sea solo lectura) durante 3-6 meses por seguridad.

**Tiempo típico de implementación:** 1 a 3 semanas.

### Cliente mediano (operación establecida con R5 funcionando bien, varias personas, posiblemente varias sucursales)

**Estrategia:** migración gradual por función.

**Fase 1:** Agregar V12 como capa gerencial y de canales digitales sobre el R5 existente.
- V12 para acceso gerencial y reportes
- Tienda en línea V12 (opcional)
- Agente IAE para WhatsApp (opcional pero recomendado)
- Intranet V12 para coordinación
- R5 sigue operando en el piso sin cambios

**Fase 2:** Evaluar migración del piso operativo.
- Migrar primero una sucursal o un departamento piloto
- Operar en paralelo R5 y V12 con sincronización de datos
- Capacitar al equipo del piloto
- Validar 2-4 semanas antes de avanzar

**Fase 3:** Migración progresiva del resto.
- Una sucursal o departamento a la vez
- Sin presión de calendario; el cliente avanza al ritmo que le funciona

**Notas de armado:**
- La fase 1 produce retorno medible y de bajo riesgo. Es la entrada perfecta porque no toca lo que funciona.
- Mantener al partner involucrado entre fases. No es un proyecto que se entrega y se olvida.
- El cliente debe entender desde el inicio que la migración es un viaje, no un evento. Comunicarlo en la propuesta y en el contrato.

**Tiempo típico de implementación:** 6 a 12 semanas para fase 1, con fases 2 y 3 extendidas según ritmo del cliente.

### Cliente grande (cadena, operación compleja, integraciones críticas, personal numeroso)

**Estrategia:** proyecto multifase con piloto explícito.

**Fase 1: Auditoría y planeación.** Documentar el sistema actual, identificar dependencias, mapear integraciones existentes, identificar módulos que requieren equivalente en V12 y módulos que se pueden retirar.

**Fase 2: Capa moderna sobre lo existente.** Agregar V12 para acceso gerencial, tienda en línea, agentes IAE, intranet. Sin tocar el piso operativo.

**Fase 3: Piloto en unidad seleccionada.** Migración completa de una sucursal o departamento. Operación en paralelo. Validación rigurosa de funcionalidad, desempeño y satisfacción del personal.

**Fase 4: Despliegue progresivo.** Una unidad a la vez, con calendario flexible pero compromisos firmes.

**Fase 5: Desmantelamiento del legacy.** Una vez todo migrado, retiro controlado de la infraestructura de escritorio. Mantener acceso de solo lectura por al menos un año.

**Notas de armado:**
- A esta escala, el partner asigna consultor o equipo dedicado al cliente durante toda la duración del proyecto.
- Considerar resistencia organizacional al cambio. La migración técnica es la parte fácil; la adopción humana es la parte difícil. Invertir en gestión del cambio, comunicación interna del cliente, y capacitación intensiva.
- Validar todas las integraciones críticas (sistemas externos del cliente, conectores con terceros) antes de cada fase de migración.
- Identificar al "campeón interno" del cliente: la persona que va a defender el proyecto cuando aparezcan resistencias. Sin campeón interno, el proyecto se estanca.

**Tiempo típico de implementación:** 3 a 12 meses para el proyecto completo, dependiendo del tamaño y la complejidad.

### Cliente que solo quiere modernizar parcialmente (entrada lateral, sin migrar el escritorio)

**Estrategia:** modernizar sin migrar.

**Stack:** mantener R5 o V10 existente + agregar V12 solo para las capacidades modernas que el escritorio no puede ofrecer.

Capacidades típicamente agregadas sin migrar:
- Agente IAE para WhatsApp conectado al ERP existente
- Tienda en línea conectada al inventario existente
- Dashboards gerenciales en V12 alimentados por datos del R5
- Intranet en V12 paralela a la operación del piso

**Notas de armado:**
- Esta es la entrada de menor riesgo y muy alto retorno. Útil para clientes que tienen miedo a la migración pero quieren beneficios modernos.
- Establecer la conectividad de datos con cuidado. La fuente de verdad debe quedar clara para evitar inconsistencias.
- Esta entrada lateral suele evolucionar orgánicamente hacia migración completa cuando el cliente experimenta los beneficios y empieza a cuestionar por qué sigue con escritorio.

**Tiempo típico de implementación:** 2 a 6 semanas según el alcance.

## Decisiones de arquitectura recurrentes

**¿Migración completa o gradual?** Completa solo para clientes chicos. Gradual para todo lo demás. Forzar migración completa en cliente mediano o grande es la receta para que el proyecto falle.

**¿Convivencia con sincronización en tiempo real o por archivo?** Tiempo real cuando es técnicamente viable y la operación lo justifica. Sincronización por archivo al cierre del día para clientes donde la criticidad permite cierto retraso.

**¿Migrar datos históricos completos o solo recientes?** Recientes (últimos 1-3 años) para la mayoría de los casos, con histórico archivado accesible en formato consultable. Completos solo cuando hay razón regulatoria o operativa específica.

**¿Apagar el sistema viejo después de migrar?** Mantenerlo accesible en solo lectura por al menos 6-12 meses. Es seguro y barato; apagarlo prematuramente puede generar problemas si surgen consultas posteriores.

**¿Capacitar a todo el personal o solo a quienes operan?** Solo a quienes operan en cada fase. Capacitación masiva anticipada se olvida antes de usarse.

**¿Hospedaje nube de Induxsoft, nube privada del cliente, u on-premise?** Nube de Induxsoft por defecto. Privada o on-premise solo cuando hay razón clara (soberanía de datos, requisito corporativo, política interna). On-premise mantiene más responsabilidad operativa en el cliente.

## Modelo de ingreso para el partner

La migración del escritorio a la nube típicamente genera estas líneas de ingreso para el partner:

1. **Proyecto de migración**: facturado por fases. Cada fase con entregables claros y aceptación formal antes de avanzar.
2. **Suscripciones recurrentes** de V12, módulos adicionales, planes IAE, MaxiPOS. Crecen conforme el cliente incorpora capacidades.
3. **Servicios continuos post-migración**: optimización, capacitación a personal nuevo, ajustes operativos, integración de nuevas capacidades, soporte de primer nivel.
4. **Capacidades agregadas durante la migración**: tienda en línea, agentes IAE, intranet, integraciones. Cada una es un proyecto adicional facturable.
5. **Servicios de auditoría inicial**: en clientes grandes, la fase de auditoría y planeación es un proyecto en sí mismo, facturable antes de comprometer las fases posteriores.

El rubro 1 puede tener ticket significativo, pero el rubro 3 es el que sostiene la relación a largo plazo. Un partner que solo cobra por la migración y descuida el post-migración deja dinero en la mesa y pierde fidelización.

## Errores comunes que conviene evitar

- **Vender migración completa a cliente que necesita gradual.** El cliente acepta porque suena más limpio, el proyecto se complica, el cliente sufre, el partner queda mal. Vender lo que conviene al cliente, no lo que es más fácil de cotizar.
- **Subestimar la transferencia de datos.** Cada sistema origen tiene particularidades; sistemas viejos pueden tener datos sucios, configuraciones no documentadas, módulos custom. Auditoría rigurosa antes del proyecto, no improvisación durante.
- **Lanzar el sistema nuevo sin operación en paralelo.** Romper lo que funciona sin red de seguridad es irresponsable. Operación en paralelo durante 2-4 semanas mínimo en clientes medianos y grandes.
- **No capacitar al campeón interno del cliente.** La persona que va a defender el proyecto necesita más capacitación que nadie. Invertir tiempo con esa persona desde la fase de planeación.
- **Apagar el sistema viejo demasiado pronto.** Mantenerlo accesible en solo lectura por al menos 6 meses. Es seguridad barata.
- **Vender la migración como "actualización tecnológica" sin aprovecharla para capacidades nuevas.** El cliente paga el costo de migrar pero no captura el upside de las capacidades modernas. Vender el paquete completo: migración + capacidades nuevas que solo eran posibles después.
- **Subestimar la resistencia organizacional.** Especialmente en clientes medianos y grandes. La parte técnica es manejable; la parte humana es donde se pierden los proyectos.

## Documentos relacionados

- [Catálogo de soluciones — Migrar del escritorio a la nube sin romper la operación](https://docs.induxsoft.net/es/todos-los-productos-y-servicios/migracion-escritorio-nube.md) — la versión narrativa de este caso de uso.
- [Índice del catálogo de soluciones](https://docs.induxsoft.net/es/todos-los-productos-y-servicios/soluciones.md)
- [Todos los productos y servicios](https://docs.induxsoft.net/es/todos-los-productos-y-servicios/) — el catálogo técnico de referencia.
- [V12 — Visión general](https://es.induxsoft.net/v12/) — la plataforma de destino de la migración.