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 es una conversación de 20 minutos, sin documentos; después, el NDA.
— Gabriel Sandoval, del equipo de Nexus
Preguntas frecuentes
¿Qué debe hacer un responsable técnico en las primeras dos semanas tras una M&A?
Solo mapear: no decidir, no arreglar y no juzgar. Lo que parece mal hecho en un sistema heredado suele tener una razón histórica que no se ve hasta entender el contexto. El mapa mínimo cubre cuatro capas: inventario de sistemas, cuentas y accesos, dependencias críticas y conocimiento, es decir, quién sabe operar cada sistema.
¿Qué preguntas ayudan a detectar problemas en un stack técnico heredado?
Este análisis propone cinco: cuándo se restauró el último backup completo, quién tiene acceso a producción, qué ocurre cuando un cliente reporta un problema, cuándo se actualizaron las dependencias y qué decisión técnica está pendiente desde antes de la operación. Si las dependencias llevan más de 12 meses sin actualizarse, se considera deuda técnica.
¿Cómo se clasifican los sistemas heredados y qué hacer con cada tipo?
Hay tres tipos. Los sistemas vivos y bien mantenidos se mantienen sin tocar, y su integración con la matriz se planifica aparte. Los sistemas zombi, que corren sin mantenimiento, exigen decidir explícitamente entre rescatar, refactorizar o sustituir. Los claramente obsoletos requieren un plan de sustitución urgente antes de que fallen solos.
¿Es buena idea integrar todo el stack heredado en la matriz cuanto antes?
No. Forzar la integración antes de mapear genera disrupciones operativas que cuestan más que las eficiencias buscadas. La secuencia correcta es mapear durante 90 días, estabilizar lo crítico en un plazo de 3 a 6 meses y decidir qué se integra y qué se sustituye a partir del mes 9.
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