Los primeros 90 días tras una M&A son los más caros de la historia tecnológica de la empresa adquirente. El nuevo responsable técnico tiene que entender, auditar y empezar a decidir sobre un stack que no construyó, con personas que no contrató y bajo presión de un comité directivo que no espera.
Lo primero: no tocar nada las primeras dos semanas
El impulso natural es demostrar valor rápido: identificar un problema obvio y arreglarlo. Es exactamente lo que no hay que hacer. En una operación heredada, las cosas que parecen mal hechas suelen tener una razón histórica que no se ve hasta que se entiende el contexto.
Las primeras dos semanas tienen un único objetivo: mapear. No decidir, no arreglar, no juzgar.
El mapa mínimo viable
Capa 1 — Inventario de sistemas operativos: qué sistemas corren, dónde, quién es el propietario operativo y qué procesos dependen de cada uno. Un sistema sin propietario operativo es un cementerio en formación.
Capa 2 — Cuentas y accesos: qué cuentas cloud existen, quién paga la factura, quién tiene credenciales administrativas, qué certificados SSL caducan en 6 meses.
Capa 3 — Dependencias críticas: qué APIs externas usa cada sistema, qué librerías corren en producción, qué dependencias están abandonadas o sin soporte.
Capa 4 — Conocimiento: quién sabe operar cada sistema. Si el conocimiento crítico vive en una sola persona y esa persona puede irse, tienes una bomba de tiempo.
Las 5 preguntas que abrirán el armario
- ¿Cuándo se restauró el último backup completo? Si nunca, los backups probablemente no funcionan.
- ¿Quién tiene acceso a producción y qué pasaría si se cae enfermo mañana?
- ¿Qué pasa cuando un cliente reporta un problema con el sistema X?
- ¿Cuándo se actualizaron las dependencias del sistema? Más de 12 meses = deuda técnica.
- ¿Qué decisión técnica importante está pendiente desde antes de la M&A?
Tres tipos de sistemas heredados, tres estrategias
Sistemas vivos y bien mantenidos: mantener sin tocar. Si la integración con la matriz es deseable, planificarla como proyecto separado.
Sistemas zombi (corriendo pero no mantenidos): decidir explícitamente: rescatar, refactorizar o sustituir.
Sistemas claramente obsoletos: plan de sustitución urgente antes de que falle solo. No es opcional.
El error más caro: integrar todo a la matriz a la fuerza
Una trampa frecuente: el comité directivo presiona para unificar el stack en pocos meses. Forzar integración antes de mapear genera disrupciones operativas que cuestan más que las eficiencias buscadas.
Secuencia correcta: mapear (90 días) → estabilizar lo crítico (3-6 meses) → decidir qué se integra y qué se sustituye (a partir del mes 9).
Cuándo pedir ayuda externa
Cuando el equipo heredado ya no está completo, cuando hay tecnologías especializadas (IA, ERP a medida) que la matriz no maneja, o cuando el comité necesita un diagnóstico independiente antes de decidir conservar, sustituir o vender la operación heredada.
Conclusión
Si acabas de heredar tecnología y necesitas un diagnóstico independiente, lee la guía completa de rescate de proyectos o cuéntanos tu caso. El primer paso siempre es el NDA.
— Gabriel Sandoval, del equipo de Nexus
Sigue leyendo
- Migración Inacabada de ERP/CRM: Cómo Retomarla Sin Romper el Negocio Mientras Opera
- Por qué fracasan los proyectos de IA en empresas españolas (y cómo rescatarlos)
- El Proveedor Anterior Abandonó el Proyecto — Las Decisiones que Hay que Tomar en las Primeras 72 Horas
- Guía de rescate de proyectos
- Rescate de proyectos parados
- Software a medida con IA