Operaciones ·
El verdadero coste de cambiar de herramienta
Cambiar de herramienta casi siempre cuesta más de lo que pensabas — no porque la nueva sea cara, sino porque la vieja llevaba años acumulando adaptaciones, integraciones y conocimiento que solo descubres cuando empiezas a migrar. El coste no es técnico: es el mes y medio que el equipo pasa en esto en vez de facturar, las cosas que se rompen justo después de cambiar, y el tiempo que tardas en volver a la misma velocidad que tenías antes. La pregunta no es si la herramienta nueva es mejor. Es si la mejora que aporta justifica paralizar parte del negocio durante semanas. En seis años he hecho tres migraciones grandes y he descartado una decena más: las que hicimos salieron bien porque el dolor de quedarnos era mayor que el de cambiar. Las que no hicimos nos ahorraron meses.
La estimación optimista
La conversación siempre empieza igual. Alguien trae una herramienta nueva que promete hacer mejor lo que ya hacemos. En la demo todo funciona, en el periodo de prueba también, y el precio es razonable. La estimación de migración es dos semanas. Parece una decisión obvia.
Luego empiezas y descubres que lo que usabas antes no era solo una herramienta: era la herramienta más tres integraciones hechas a mano, una exportación semanal que se ejecuta sola desde hace dos años, y un manual interno de cómo hacer las cosas que nadie ha escrito pero todo el mundo conoce. Eso no aparece en ninguna demo.
Cuando terminamos de migrar nuestro CRM —una decisión que sigo pensando que era correcta— habían pasado seis semanas en vez de dos, y durante ese tiempo hubo días en los que no sabíamos dónde estaba cierta información. No perdimos ningún cliente, pero costó. El trabajo no fue técnico: fue sincronizar a cinco personas para que siguieran trabajando mientras cambiábamos la herramienta debajo de ellas.
El conocimiento invisible
La parte más cara de una herramienta no es el precio de la licencia. Es lo que el equipo ha aprendido a hacer con ella. Atajos, configuraciones, pequeñas automatizaciones que alguien montó un viernes por la tarde y llevan tres años funcionando sin que nadie se acuerde de quién las hizo.
Eso no se migra: se pierde. Y después de cambiar, durante semanas, la gente pregunta cosas que antes sabía de memoria. Eso tiene un coste — no en dinero, en velocidad.
Un caso concreto: llevábamos años usando una herramienta de gestión de proyectos que, siendo honesto, era regular. Cuando probamos otra que era objetivamente mejor, descubrimos que habíamos adaptado nuestra forma de trabajar a las limitaciones de la vieja — no porque fuera ideal, sino porque llevábamos tanto tiempo con ella que ya no pensábamos en alternativas. Cambiar nos obligó a repensar procesos que dábamos por sentados, y eso es más largo de lo que parece.
Las tres que hicimos
En seis años hemos hecho tres migraciones grandes y las tres tenían algo en común: la herramienta vieja nos estaba frenando de forma medible.
Cambiamos de CRM porque el anterior no conectaba con nada y estábamos copiando datos a mano cada semana. Cambiamos de hosting porque el antiguo nos daba caídas cada mes y medio. Y construimos Timetry para sustituir una hoja de cálculo que ya no daba más de sí.
En los tres casos el dolor de quedarnos era mayor que el de cambiar. Esa es la única métrica que funciona.
Las que no hicimos
La parte más útil de este artículo probablemente sea esta: la lista de migraciones que no hicimos y por qué.
- La herramienta de diseño colaborativo que prometía ahorrar reuniones. El problema era la comunicación, no la herramienta. Cambiarla no habría resuelto nada.
- El software de contabilidad que era más moderno y tenía más funciones. El que usábamos funcionaba y lo conocía nuestra gestoría. No valía la pena.
- La plataforma de email marketing que costaba la mitad. Migrar tres años de historiales y automatizaciones habría llevado semanas por ahorrarnos ciento veinte euros al mes.
- La suite de productividad que todo el mundo usa. Ya teníamos una que funcionaba, y la nueva no resolvía ningún problema real.
Cada una de esas decisiones nos ahorró entre dos semanas y dos meses de trabajo que pudimos dedicar a otra cosa. Eso no sale en ninguna hoja de cálculo, pero es el activo más valioso que tiene un equipo pequeño: su tiempo.
Cuándo sí merece la pena
Hay migraciones que merecen la pena y son fáciles de reconocer. Se dan cuando la herramienta actual te obliga a hacer algo a mano que la nueva automatiza, cuando te impide escalar algo que estás haciendo cada vez más, o cuando el equipo pasa más tiempo luchando con ella que usándola.
La señal más clara es esta: si calculas cuánto tiempo al mes pierdes por las limitaciones de lo que tienes y sale más de una semana, probablemente es momento de cambiar. Pero si el problema es que la herramienta "no te gusta" o "parece anticuada", casi nunca vale la pena.
Cómo hacerlo cuando lo haces
Si decides migrar, hay tres cosas que minimizan el riesgo:
Primero, duplica durante al menos dos semanas. Usa las dos herramientas en paralelo aunque sea un dolor. Es la única forma de descubrir todas las cosas que la vieja hacía y que no estaban documentadas.
Segundo, no migres en un momento crítico del año. Parece obvio pero he visto gente planear migraciones en plena campaña de Black Friday. Hazlo en un valle, cuando puedas permitirte que algo falle.
Tercero, cuenta con el doble de tiempo del que te han dicho. Si el proveedor dice que la migración lleva una semana, reserva dos. Si tu equipo técnico dice que en tres días está, dale seis. No porque sean malos estimando: porque siempre hay algo que no estaba previsto.
La regla que no falla
Después de seis años y una docena de decisiones entre cambiar y quedarnos, tengo una regla que no me ha fallado nunca: si no puedes explicar en una frase concreta qué problema resuelve el cambio, no lo hagas. "Es mejor" no es un problema. "Nos pasa esto cada semana y nos cuesta tres horas" sí lo es.