¿Qué ocurre después de migrar de Excel

Migrar de Excel a una solución a medida es solo el primer paso; el verdadero desafío comienza cuando el proyecto se firma y el software entra en producción. En este artículo verás qué ocurre después de la entrega, qué debes exigir por escrito y cómo garantizar que tu inversión siga generando valor sin sorpresas.

Lo que empieza el día de la entrega

Ese momento en que el equipo de desarrollo te entrega la URL, los usuarios comienzan a iniciar sesión y el proyecto pasa oficialmente a “en producción” suele celebrarse con un brindis. Lo que pocos comentan antes de firmar es que la entrega no implica el fin de la relación contractual, sino el inicio de una fase crítica donde se ponen a prueba los acuerdos de calidad, los tiempos de respuesta y la capacidad de adaptación del proveedor.

• Checklist de cierre: antes de aceptar la entrega, verifica que todos los módulos acordados estén operativos, que la integración con SUNAT y la facturación electrónica funcione sin errores y que los datos migrados desde Excel coincidan al 100 %.
• Capacitación final: la entrega incluye una sesión de entrenamiento de al menos 8 horas para usuarios clave y administradores. Si no está contemplada, exígela ahora; sin conocimiento interno el sistema se vuelve una caja negra.
• Plan de transición: debe quedar documentado cómo se realizará el traspaso de soporte del equipo de desarrollo a la mesa de ayuda. Un plazo típico es de 2 semanas de acompañamiento intensivo, con reportes diarios de incidencias.

Quién responde cuando algo falla

Una vez en producción, cualquier anomalía pasa a ser un incidente. Aquí es donde se definen las responsabilidades y los niveles de servicio (SLA) que deberás exigir por escrito.

• Responsable del desarrollo: Kovensa, como proveedor, se compromete a corregir defectos de código dentro de los plazos acordados. Un SLA razonable para incidencias críticas (pérdida de datos o interrupción total) es de 4 horas de respuesta y 24 horas de solución. Para incidencias de nivel medio (funcionalidad parcial) 12 horas de respuesta y 72 horas de solución.
• Responsable del cliente: tu empresa debe proveer accesos, credenciales y un entorno de pruebas que cumpla con los requisitos de seguridad de la SUNAT. Además, es responsable de reportar incidentes con la información necesaria para su diagnóstico.
• Exigir por escrito: incluye en el contrato una tabla de SLA, penalizaciones por incumplimiento (por ejemplo, crédito de horas de soporte) y la definición de “incidente crítico” vs “incidente menor”. También solicita un registro de cambios (changelog) que muestre cada corrección realizada.

Mantenimiento: qué es y qué no

El mantenimiento no es sinónimo de “mejoras” ni de “rehacer” el sistema. Se divide en tres categorías claramente diferenciadas:

• Mantenimiento correctivo: reparación de errores detectados en producción. No incluye cambios de funcionalidad.
• Mantenimiento evolutivo: incorporación de nuevas funcionalidades o adaptación a cambios regulatorios (por ejemplo, nuevas versiones de la facturación electrónica de SUNAT). Se negocia como proyecto adicional, con estimación de esfuerzo en semanas.
• Mantenimiento preventivo: actividades programadas para evitar fallos, como actualizaciones de seguridad, optimización de bases de datos y pruebas de carga. Normalmente se planifican cada 3 meses y consumen entre 5 % y 10 % del tiempo total de soporte.

Lo que no está incluido en el mantenimiento estándar:

• Rediseño de la arquitectura o migración a otra plataforma tecnológica.
• Cambios que impliquen ampliación del alcance original del proyecto (por ejemplo, agregar un módulo de gestión de inventario cuando solo se había pactado facturación y reporte).
• Soporte para hardware o infraestructura que no haya sido provisto por el proveedor.

Cómo evitar quedar atrapado

El mayor riesgo después de la entrega es perder el control sobre lo que se ha construido. Para evitar quedar dependiente de un solo proveedor, sigue estos pasos concretos:

• Accesos completos: exige que el proveedor entregue credenciales de administrador a nivel de servidor, base de datos y repositorio de código (Git). Sin estos accesos no podrás migrar a otro hosting ni realizar auditorías.
• Copias de seguridad: establece una política de backups diarios y semanales, con retención mínima de 30 días. El plan debe estar documentado y el cliente debe poder restaurar los datos sin intervención del proveedor.
• Documentación técnica: solicita manuales de arquitectura, diagramas de flujo, lista de dependencias y procedimientos de despliegue. Un buen punto de partida es un documento de 20‑30 páginas que cubra estos aspectos.
• Propiedad intelectual: el contrato debe dejar claro que el código fuente, la base de datos y cualquier elemento creado son propiedad de tu empresa. Si el proveedor retiene derechos de uso, negocia una licencia perpetua sin costos adicionales.
• Plan de salida: incluye una cláusula que detalle el proceso de transferencia total en caso de rescisión del contrato: entrega de código, bases de datos, documentación y asistencia para migrar a otro equipo durante al menos 4 semanas.

Conclusión

Después de la entrega, la clave está en formalizar responsabilidades, definir claramente los alcances del mantenimiento y garantizar la propiedad y acceso al código. Si cumples con estos puntos, la migración de Excel a tu propio sistema se transforma de una inversión puntual a una herramienta estratégica que seguirá generando valor a lo largo del tiempo.