Migrar de Excel a una aplicación a medida: cuándo, cómo y qué evitar

La conversación se repite cada pocas semanas. Llega un correo o una llamada, y el patrón es casi idéntico: tenemos un Excel central que controla todo el negocio y ya nadie se atreve a tocar. A veces es el presupuesto anual. A veces el control de stock. A veces el planning de instalaciones del próximo trimestre. La sintomatología siempre es la misma: el archivo pesa más de 80 MB, hay 14 pestañas con fórmulas que solo entiende una persona, y la última vez que alguien lo copió a otra carpeta se rompieron tres cálculos que nadie detectó hasta dos semanas después.

Excel es una herramienta brillante. Lo decimos en serio. Lo usamos a diario para tareas que no justificarían una aplicación a medida. Pero hay un punto donde deja de ser una hoja de cálculo y se convierte en una aplicación encubierta, con lógica de negocio, permisos informales e integraciones improvisadas. A partir de ahí, mantenerlo cuesta más de lo que cuesta reemplazarlo. Este post va de eso: cómo detectar el momento, qué evitar en la transición, y cómo planteamos una migración seria cuando un cliente nos pide salir del Excel sin perder lo que el Excel sí le estaba aportando.

Las 7 señales de que tu Excel se ha quedado pequeño

Cada vez que entramos a auditar un proceso apoyado en Excel, buscamos estas señales. Tres o más juntas suelen significar que el coste mensual del Excel ya supera al de la migración. Las cinco primeras son técnicas. Las dos últimas son organizativas y, por experiencia, las que más duelen cuando explotan.

1. Una sola persona entiende las fórmulas. El clásico bus factor. La hoja arrancó hace siete años, ha pasado por tres versiones de Office, y la persona que la diseñó hoy trabaja contigo a tiempo parcial. Cuando alguien pregunta cómo se calcula un campo, la respuesta es “lo sabe Marisa”. Si Marisa se va, el Excel se vuelve una caja negra de la que dependen decisiones operativas.

2. Hay tres versiones del archivo y nadie sabe cuál es la buena. El maestro está en el servidor, pero hay copias en escritorios, en buzones de correo y en una carpeta de Dropbox que alguien compartió con un comercial externo en 2023. Cada cierto tiempo aparecen discrepancias entre versiones y la única forma de resolverlas es por antigüedad de archivo o porque “la última que cambió Marisa fue el martes”.

3. Bloqueos constantes por edición concurrente. Dos personas necesitan tocar el archivo a la vez y una de ellas tiene que esperar. O peor: Excel les avisa que “el archivo está siendo editado” y deciden trabajar en una copia local, prometiéndose que después se consolida. Spoiler: no se consolida bien.

4. Errores de copiar y pegar que se descubren tarde. Una fila desplazada, una fórmula que apuntaba a otra hoja y ahora referencia un valor estático, una columna que se ordenó alfabéticamente sin extender la selección a las columnas adyacentes. Cuando se detecta el error, ya hay tres informes mensuales con datos incorrectos circulando.

5. Es imposible auditar quién cambió qué. Excel guarda quién abrió el archivo por última vez, no quién modificó cada celda. Cuando una cifra crítica baila entre el lunes y el martes, no hay forma de saber si fue un error humano, un cambio aprobado o un recálculo automático tras una actualización de cotizaciones.

6. El Excel manda decisiones operativas, pero no se conecta con nada. El stock real vive en el Excel. Las facturas se generan desde el ERP. Los pedidos entran por la web. Cada mañana, alguien dedica 40 minutos a actualizar manualmente el Excel con datos extraídos del ERP y de la web. Ese trabajo invisible es el primer indicador real de que el proceso ya no escala.

7. Tarda en abrirse, y eso lo hemos normalizado. Cuando el archivo ronda los 70-100 MB, abrirlo lleva 30-50 segundos. Filtrar, otros 10. Cualquier cambio recalcula medio libro. La gente lo asume como parte del trabajo, pero estás pagando cada día varios minutos por persona por la fricción.

Si reconoces tres o más en tu caso, no estás obligado a migrar. Pero el coste de no hacerlo es bastante mayor de lo que parece a primera vista.

Cuando Excel sigue siendo la respuesta correcta

A veces el dolor que sentimos al ver un proceso apoyado en Excel es desproporcionado al problema real. Estos son los escenarios donde no migramos, y se lo decimos al cliente aunque venga a contratarnos:

• Procesos puntuales o de baja frecuencia. Si el archivo se toca una vez al mes y lo lleva una sola persona, está bien donde está. La fricción es mínima.
• Análisis ad-hoc. Excel es la mejor herramienta del mercado para explorar datos en libertad antes de saber qué pregunta quieres responder. Cualquier aplicación a medida te limita a lo que la aplicación prevé.
• Prototipado de un proceso nuevo. Si todavía estás definiendo cómo se va a hacer algo, no construyas una aplicación. Itera en Excel hasta que el proceso esté estable. Solo entonces tiene sentido invertir en sistematizarlo.
• Equipos de menos de 5 personas con un único analista que domina el archivo. Aquí el bus factor existe, pero el coste de migrar suele ser mayor que el riesgo durante varios años.
• Reporting periódico que se conecta a una fuente de datos única y estable. Si el Excel es un mirador de datos que vienen de otro sitio, y el formato no cambia mucho, no necesita ser una aplicación.

Migrar por modernidad, por estética o porque “los Excel son cosa del pasado” es una mala razón. Migrar porque el coste mensual del Excel ya pesa, esa es la buena razón.

Las 3 trampas al migrar (y cómo las evitamos)

Cuando una migración fracasa, casi siempre falla por una de estas tres razones. No por la tecnología elegida.

1. Querer replicar el Excel 1:1 en la aplicación nueva

La tentación es enorme: como el Excel “ya funciona”, se pide al equipo de desarrollo que reproduzca exactamente lo que hace, pero en una pantalla web bonita. El resultado es un Excel disfrazado de aplicación, con todas las limitaciones del original y ninguna ventaja real. Los flujos que tenían sentido en una hoja de cálculo (rellenar 40 columnas en una sola fila, por ejemplo) son antiergonómicos en una interfaz web.

Lo que hacemos en su lugar: rediseñar el proceso aprovechando que cambiamos de herramienta. Si el Excel necesitaba 40 columnas porque no se podía partir en entidades relacionadas, ahora sí se puede. Si la lista de validaciones era una pestaña aparte que se actualizaba a mano, ahora es una tabla maestra editable por permisos. Migrar es la única ocasión en años para repensar el flujo, no la oportunidad de fosilizarlo.

2. Mover todo de golpe (big bang)

La otra tentación: como hemos decidido migrar, vamos a migrarlo todo a la vez y apagar el Excel un viernes a las 18:00. Esto fracasa por varias razones. La primera es que nadie acaba de fiarse del sistema nuevo en el día 1, y mantienen el Excel en paralelo “por si acaso”. La segunda es que los flujos secundarios (los que nadie documentó porque eran obvios para quien usaba el Excel) aparecen en producción como bugs urgentes. La tercera es que el equipo se quema durante 9 meses sin entregar nada que pueda usarse de verdad.

Lo que hacemos en su lugar: migrar por módulos, con entregas cada 2-3 semanas. Empezar por el módulo que más duele, ponerlo en producción, dejarlo conviviendo con el Excel un periodo, validar que funciona, y solo entonces pasar al siguiente. La parte del Excel que aún no se ha migrado sigue operativa hasta que le toca. Cubrimos esto con más detalle en Modernizar un ERP legacy: cuándo conviene migrar y cuándo no, porque el patrón es el mismo: estrangulación progresiva, no recambio total.

3. No involucrar a quien usa el Excel cada día

El error político, no técnico, y el más caro de todos. Si la persona que lleva años manteniendo el Excel se entera de la migración por un email, el proyecto está condenado. Lo perciben (con razón) como un voto de no confianza a su trabajo. Y como conocen los recovecos del proceso mejor que nadie, sus reservas tendrán argumentos sólidos.

Lo que hacemos en su lugar: convertir a esa persona en parte del equipo de discovery desde la semana 1. Su conocimiento del proceso real (no del proceso documentado) es el mayor activo del proyecto. Suelen acabar siendo referentes internos del nuevo sistema, formando al resto del equipo. Y, sobre todo, son quienes detectan los casos límite antes de que lleguen a producción.

Cómo planteamos una migración seria

El patrón que aplicamos cuando un cliente nos pide ayuda con un proceso apoyado en Excel es siempre el mismo, ajustando duración a la complejidad del caso.

Auditoría del Excel real (2-3 semanas). Antes de hablar de tecnología, queremos saber qué hace el archivo en realidad. No lo que dice la documentación interna. No lo que cree el equipo. Lo que hace. Eso implica revisar fórmulas, macros, hojas ocultas, validaciones, conexiones externas, y entrevistar a quien lo usa. Salimos con un mapa de procesos, una lista de campos críticos y una clasificación entre lo que es lógica de negocio y lo que es ergonomía de Excel (filtros, ordenaciones, agrupaciones).

Discovery con usuarios reales (1-2 semanas). Sesiones cortas con quien usa el Excel cada día. No con responsables que lo supervisan desde lejos. Aquí salen los flujos no documentados, los casos límite y las decisiones tácitas que el Excel “permite” pero la documentación no recoge.

Roadmap por módulos. Partimos el proceso en módulos independientes y los priorizamos por dolor actual y riesgo de migración. El módulo más doloroso suele ser el que más motivación genera en el equipo cuando se entrega. El módulo más arriesgado, lo dejamos para cuando ya hay confianza con el sistema nuevo.

MVP del primer módulo (4-6 semanas). Versión mínima del módulo que más duele, en producción real, con datos reales. Conviviendo con el Excel durante al menos un ciclo operativo completo (un mes, un trimestre, según el caso) para detectar inconsistencias.

Iteración por módulos (variable). Cada 2-3 semanas, un módulo nuevo o una mejora del anterior con retroalimentación del uso real. Sin grandes paréntesis silenciosos. Sin “vuelvo en seis meses con esto entregado”.

Apagado del Excel (cuando proceda). Solo cuando todos los flujos críticos llevan al menos un trimestre en producción sin incidentes, el Excel pasa a modo consulta. Se mantiene como histórico para auditoría, pero deja de ser fuente de verdad.

Cuánto cuesta esto de verdad

Hablar de coste es lo que más cuesta de hablar honestamente, así que vamos al grano. Para una PYME española con un proceso operativo razonablemente acotado (5-20 usuarios, 1.000-3.000 registros activos, integración con 1-2 sistemas existentes), el rango habitual de inversión total es:

Tamaño del proceso	Inversión total	Plazo de entrega	Cuándo amortiza
Pequeño (1 módulo, hasta 5 usuarios)	15.000-25.000 €	2-3 meses	8-14 meses
Medio (3-4 módulos, 10-20 usuarios)	30.000-60.000 €	4-6 meses	14-22 meses
Grande (5+ módulos, integración ERP/CRM)	70.000-150.000 €	6-9 meses	20-30 meses

El plazo de amortización lo calculamos contra el coste real del Excel actual: horas dedicadas a consolidaciones manuales, errores corregidos a posteriori, decisiones tomadas con datos desactualizados, y, sobre todo, el coste de oportunidad de no poder atacar líneas de negocio nuevas porque el proceso no escala.

Antes de invertir en una aplicación a medida conviene revisar si un SaaS específico cubre el caso. A veces sí, a veces no. La decisión la cubrimos en Software a medida vs SaaS: cuándo elegir cada uno. El resumen: si tu proceso es estándar de tu sector y no es tu diferencial, busca SaaS antes que custom. Si tu forma de hacer ese proceso es parte de lo que te diferencia, custom paga.

Un ejemplo concreto: Power Time

Power Time es nuestro propio caso de migración desde Excel. Antes de construirlo, varios de los clientes con los que trabajábamos llevaban el control horario en Excel: una hoja por mes, fichajes a mano cada mañana, fórmulas para calcular horas extras, una columna oculta con vacaciones pendientes. Funcionaba mientras la plantilla era pequeña. A partir de 15-20 trabajadores, el coste de mantener el Excel ya superaba al de cualquier solución dedicada, y además había riesgo regulatorio claro: el RD-Ley 8/2019 exige inmutabilidad de los registros, algo que Excel no garantiza por defecto.

Lo construimos como producto porque el problema era estándar (todas las empresas con plantilla por cuenta ajena tienen exactamente la misma obligación). Si hubiera sido un proceso diferencial de una empresa, lo habríamos hecho a medida. La línea entre ambas decisiones, otra vez, es lo estándar que sea tu proceso.

Si estás en este punto

Si reconoces tres o más señales en tu Excel y has empezado a hacer cuentas de cuánto te cuesta no migrar, hablamos sin compromiso. Media hora basta para saber si tu caso justifica una migración seria o si todavía no es el momento. Lo segundo lo decimos también, sin marearte con una propuesta que no te va a pagar.

Recursos

• Software a medida vs SaaS: cuándo elegir cada uno: la decisión paralela que conviene tomar antes de empezar.
• Modernizar un ERP legacy: cuándo conviene migrar y cuándo no: el patrón aplica también a sistemas heredados, no solo a Excel.
• Servicios de VisibleSoft: qué tipo de proyectos de migración asumimos.
• Reserva un diagnóstico gratuito