Es Solo una Reescritura Simple — Una Historia de Estimaciones, Egos y Éxito Eventual

Cuando “Solo Necesitamos Traducirlo” Se Encuentra con la Realidad

La Empresa Que el Tiempo Construyó

Hartmann & Söhne comenzó en 1998 como una clásica Systemhaus alemana — una empresa de software especializada en un sector industrial específico. Su nicho: configuración y gestión de pedidos para maquinaria industrial especializada. Cuando un fabricante necesitaba cotizar una máquina personalizada compleja con cientos de opciones configurables, reglas de precios y restricciones de ingeniería, el software de Hartmann lo manejaba.

La aplicación, llamada MaschinenKonfigurator, se convirtió en el estándar de su mercado. Construida en Borland Delphi con una base de datos SQL Server local, se ejecutaba en las instalaciones del cliente. El software acumuló dos décadas de experiencia en el dominio: algoritmos de precios complejos, reglas de cumplimiento regulatorio para diferentes mercados de exportación, integración con sistemas CAD, y la lógica peculiar de la configuración de maquinaria industrial.

Klaus Hartmann, el hijo del fundador y ahora director general, enfrentaba una realidad incómoda en 2024. El ecosistema Delphi se había contraído. Encontrar desarrolladores que entendieran Object Pascal era cada vez más difícil. Su mejor desarrolladora, que había estado con la empresa desde 2003, se acercaba a la jubilación. Los clientes preguntaban por acceso en la nube, despliegue en múltiples ubicaciones e integración con sistemas ERP modernos.

La decisión parecía obvia: reconstruir como una aplicación SaaS moderna. Lo que siguió resultó mucho más complicado de lo que nadie imaginó.

El Entusiasmo Inicial

El equipo directivo se reunió para lo que Klaus llamó un “kickoff de transformación”. Ya habían tomado decisiones tecnológicas clave: Java con Spring Boot para el backend, un framework JavaScript moderno para el frontend, PostgreSQL para la base de datos, Kubernetes en AWS para el alojamiento.

“Sabemos exactamente lo que el software tiene que hacer”, dijo Klaus. “Tenemos veinte años de código funcionando. Basta con traducirlo a tecnología moderna.”

Thomas, el jefe de desarrollo, asintió con cautela. “Toda la lógica de negocio está ahí. La documentamos en su mayoría a lo largo de los años.”

María, la gerente de producto que se había unido desde una empresa de software más grande tres meses antes, levantó la mano. “¿Cuánto tiempo tomó construir el sistema original?”

Thomas calculó. “La primera versión se entregó después de dieciocho meses. Pero hemos estado agregando funcionalidades continuamente durante veinte años.”

“Entonces no estamos realmente reconstruyendo dieciocho meses de trabajo”, observó María. “Estamos reconstruyendo veinte años de capacidad acumulada.”

La sala quedó en silencio. Klaus miró a Thomas, quien evitó su mirada. En la esquina, Heike — la desarrolladora senior de Delphi que llevaba en la empresa desde 2003 — cruzó los brazos y no dijo nada. Había visto propuestas de reescritura antes. Ninguna había llegado a nada. Esta vez se sentía diferente — y no para bien.

La Trampa de las Estimaciones

Las primeras sesiones de planificación revelaron un patrón familiar. El equipo de desarrollo, ahora reforzado con contratistas expertos en Java y Spring Boot, empezó a estimar la reescritura.

“Autenticación y autorización de usuarios — dos semanas.”

“Motor de configuración básico — tres meses.”

“Reglas de precios — seis semanas.”

“Integración con CAD — cuatro semanas.”

Las estimaciones se fueron sumando hasta formar un cronograma cómodo de dieciocho meses. Klaus aprobó el presupuesto. El equipo empezó a trabajar con confianza.

Tres meses después, el sistema de autenticación estaba completo. El motor de configuración básico existía pero no podía manejar los casos especiales que hacían valioso a MaschinenKonfigurator. Las reglas de precios, supuestamente un esfuerzo de seis semanas, habían consumido dos meses y cubrían quizás el treinta por ciento de la complejidad real.

Thomas convocó una reunión de emergencia. “No estamos traduciendo código. Estamos redescubriendo por qué el código fue escrito de esa manera en primer lugar.”

Martin, uno de los contratistas de Java, contraatacó. “Si los desarrolladores originales hubieran documentado su trabajo como corresponde, no estaríamos adivinando.”

El ambiente se tensó. Heike, que había estado revisando tranquilamente un documento impreso, levantó la vista. “Documentamos todo lo que parecía importante en su momento. Veinte años de decisiones son mucha documentación. ¿Quieres que te muestre dónde está, o prefieres seguir quejándote?”

Klaus intervino antes de que la situación escalara más. Pero el daño era visible. Los nuevos desarrolladores veían al equipo legado como obstáculos. El equipo legado veía a los nuevos desarrolladores como recién llegados arrogantes que no entendían lo que estaban desmantelando.

El Problema del Conocimiento

El código Delphi contenía veinte años de decisiones. Algunas estaban documentadas. La mayoría solo existían en el código mismo — o en la memoria de desarrolladores que ya no estaban.

Heike se convirtió en el recurso más valioso del proyecto — aunque tomó semanas para que el nuevo equipo lo reconociera. Podía mirar un bloque de Object Pascal y explicar: “Esto maneja el caso cuando un cliente configura una máquina para el mercado japonés pero quiere certificaciones de seguridad alemanas para re-exportación. Lo agregamos en 2011 después de perder un pedido importante.”

Los nuevos desarrolladores Java implementaban una funcionalidad, se la demostraban a Heike, y la veían negar con la cabeza. “Eso funciona para configuraciones estándar. Pero ¿qué pasa con las restricciones de combinación? ¿Qué pasa con los acuerdos de precios heredados? ¿Qué pasa con las máquinas configuradas antes de que cambiáramos el esquema de numeración de componentes en 2015?”

Cada funcionalidad “simple” tenía ramificaciones hacia casos especiales que solo se volvían visibles cuando alguien intentaba usar el sistema como lo hacían los clientes reales.

El Pivote: Ejecutar en Paralelo

Seis meses después del inicio del proyecto, Klaus se encontró ante una decisión difícil. El nuevo sistema había consumido la mitad del presupuesto pero entregado apenas el veinte por ciento de la funcionalidad necesaria. Continuar con el mismo enfoque significaba aumentar drásticamente el presupuesto o entregar un sistema incapaz de reemplazar al original.

María propuso una estrategia diferente. “¿Qué tal si no intentamos reemplazar MaschinenKonfigurator de una sola vez? ¿Qué tal si ejecutamos ambos sistemas en paralelo y migramos capacidad por capacidad?”

El enfoque tenía sus compromisos. Ejecutar dos sistemas aumentaba la complejidad operativa. Los clientes necesitarían trabajar con ambos durante la transición. Pero ofrecía algo que el plan original no tenía: la capacidad de aprender y ajustar sin apostar todo a un solo resultado.

El equipo reestructuró el proyecto alrededor de tres principios:

Migración de capacidades, no traducción de código. En lugar de traducir módulos de Delphi a Java, identificaron capacidades discretas que los clientes realmente usaban. Cada capacidad se convirtió en una pieza autónoma del nuevo sistema.

Validación en producción en cada paso. Cada capacidad iba a producción tan pronto como estaba lista, ejecutándose junto al sistema legado. Los clientes podían elegir qué sistema usar para esa función.

Ciclos de aprendizaje continuo. Cada despliegue de capacidad incluía telemetría. Los patrones de uso, errores y métricas de rendimiento guiaban la priorización.

La Primera Victoria Real

El equipo eligió los cálculos de precios como su primer objetivo. Los precios eran complejos pero relativamente autónomos — consumían datos de configuración y producían cotizaciones sin integración profunda con otras partes del sistema.

Construir el motor de precios tomó tres meses, no seis semanas. Pero esta vez, el equipo tenía a Heike revisando cada algoritmo, comparando resultados con el sistema Delphi, e identificando casos especiales antes de que los descubrieran los clientes.

El nuevo motor de precios se lanzó como una funcionalidad opcional. Los clientes podían generar cotizaciones usando cualquiera de los dos sistemas. La telemetría rastreaba la precisión — ¿producía el nuevo motor los mismos resultados que el antiguo?

La primera semana reveló tres casos especiales que el equipo había pasado por alto. Para la segunda semana, estaban corregidos. Para la cuarta semana, la mayoría de los clientes habían cambiado al nuevo motor permanentemente. Era más rápido, accesible desde cualquier navegador, y producía resultados idénticos.

Más importante aún, el equipo había aprendido algo: el nuevo sistema no necesitaba replicar cada funcionalidad del antiguo. Necesitaba replicar las capacidades que los clientes realmente usaban.

El Desafío del Motor de Configuración

Los precios fueron el calentamiento. El motor de configuración — el corazón de MaschinenKonfigurator — presentaba un desafío de diferente magnitud.

El motor de configuración Delphi codificaba reglas que habían evolucionado durante veinte años. Qué componentes eran compatibles con qué bases. Qué requisitos regulatorios aplicaban en diferentes mercados. Cómo los acuerdos de precios específicos de clientes modificaban las reglas estándar. Las dependencias formaban una red que ninguna persona entendía completamente.

Thomas propuso un enfoque no convencional: “No vamos a reconstruir el motor de configuración. Vamos a construir uno nuevo que aprenda del antiguo.”

El equipo construyó el nuevo motor de configuración con definiciones de reglas explícitas — claras, verificables, documentadas. Pero cada configuración que el nuevo motor producía también se ejecutaba a través del sistema Delphi legado. Las discrepancias provocaban investigaciones.

Este enfoque de “modo sombra” servía para múltiples propósitos. Validaba la corrección. Exponía reglas no documentadas cuando los sistemas discrepaban. Y construía confianza entre el equipo de que el nuevo sistema realmente funcionaba.

El motor de configuración tomó ocho meses en lugar de los tres originalmente estimados. Pero cuando se lanzó, se lanzó con confianza.

La Dimensión Humana

Los desafíos técnicos no fueron los únicos obstáculos. La transformación tensionó a la organización de maneras que Klaus no había anticipado — y casi la rompe.

La primera crisis mayor llegó tres meses después del giro hacia la ejecución en paralelo. Jürgen, un desarrollador Delphi que llevaba doce años en la empresa, pidió una reunión privada con Klaus.

“Ya no puedo más”, dijo Jürgen. Su voz era firme, pero Klaus notó que le temblaban las manos. “Cada día vengo y veo a contratistas destrozar código que pasé años construyendo. No preguntan por qué las cosas funcionan como funcionan. Simplemente lo reescriben y después nos culpan cuando se rompe.”

“Te necesitamos, Jürgen. Conoces el módulo de precios mejor que nadie.”

“Ese es el problema.” La compostura de Jürgen se resquebrajó levemente. “No soy un recurso del que sacar provecho. Soy una persona. Y estoy harto de que me traten como una reliquia de museo que todos tienen que consultar antes de poder hacer su trabajo de verdad.”

Klaus prometió cambios. Jürgen aceptó quedarse — por ahora.

Dos semanas después, Martin, uno de los contratistas de Java, se pasó de la raya. En una reunión de equipo, se burló abiertamente de una sección de código Delphi mostrada en pantalla. “¿Quién escribió este espagueti? Por esto los sistemas legados tienen que morir.”

Jürgen había escrito ese código. Se levantó lentamente, con el rostro pálido. “Lo escribí yo. En 2014. Cuando teníamos tres días para arreglar un bug crítico para nuestro cliente más grande. No es elegante, pero ha funcionado diez años sin un solo fallo.” Se le quebró la voz en las últimas palabras. Salió de la sala.

El silencio que siguió fue devastador. Lisa, una desarrolladora junior que había estado tomando notas, empezó a llorar. No sabía bien por qué — la tensión acumulada simplemente había sido demasiada.

Klaus encontró a Jürgen en el estacionamiento, sentado en su coche. No iba a volver a entrar.

“Se acabó”, dijo Jürgen. “Cumpliré mi período de preaviso, pero no pienso asistir a más reuniones con esa gente.”

Nada de lo que Klaus dijo lo hizo cambiar de opinión. Jürgen se fue cuatro semanas después, llevándose consigo conocimiento irremplazable sobre los algoritmos más complejos del motor de precios. El equipo pasó los dos meses siguientes haciendo ingeniería inversa de código que él habría podido explicar en una tarde.

En cuanto a Martin — Klaus lo despidió al día siguiente.

“No puedes despedirme por tener una opinión”, protestó Martin.

“Te despido por crear un ambiente hostil que nos costó un empleado de doce años”, respondió Klaus. “Tu opinión destruyó más valor en cinco segundos del que tú creaste en cinco meses. Recoge tus cosas.”

Martin amenazó con acciones legales. No pasó nada. Pero la noticia se difundió rápidamente entre los contratistas restantes: las reglas habían cambiado.

Mientras tanto, Heike había dejado de asistir a las reuniones de integración. Cuando Klaus le preguntó por qué, fue directa: “Cada vez que explico algo, alguien pone los ojos en blanco. Llevo veinte años protegiendo este sistema. Si no quieren mi ayuda, esperaré a que la pidan.”

Klaus vio un problema de personas. Y como muchos ejecutivos ante problemas de personas, recurrió a una solución conocida: ayuda externa.

Los Consultores

La firma de consultoría de gestión venía muy recomendada. Se especializaban en “transformación organizacional” y “gestión del cambio”. Su consultor principal, el Dr. Berger, llegó con un equipo de tres analistas junior y una metodología llamada “Marco de Transición Adaptativa”.

“Los proyectos técnicos fracasan por las personas, no por la tecnología”, explicó el Dr. Berger en su presentación inicial. “Alinearemos a las partes interesadas, estableceremos protocolos de comunicación claros y crearemos estructuras de responsabilidad que generen resultados.”

Thomas era escéptico. “¿Alguno de su equipo ha construido software alguna vez?”

El Dr. Berger sonrió pacientemente. “No necesitamos entender los detalles técnicos. Las dinámicas humanas son universales. La resistencia al cambio sigue patrones predecibles independientemente de la industria.”

Durante seis semanas, el equipo de consultoría realizó entrevistas, facilitó talleres y produjo un informe de 47 páginas. Identificaron “brechas de comunicación”, “definiciones de roles poco claras” e “insuficiente preparación para el cambio”. Sus recomendaciones incluían una nueva estructura de gobernanza, reuniones semanales de alineación y un rol de “campeón de la transformación”.

Las reuniones semanales de alineación agregaron tres horas a la agenda de todos. La estructura de gobernanza creó cuellos de botella de aprobación que ralentizaron las decisiones. El campeón de la transformación — un gerente junior de ventas — no entendía nada de lo que los desarrolladores hablaban y discretamente dejó de asistir después de dos semanas.

Heike asistió a una de las “sesiones de integración de actores del sistema legado” del Dr. Berger. Se salió a los veinte minutos. Cuando Klaus le preguntó qué había pasado, dijo: “Me pidió que describiera mi ‘relación emocional’ con el código. Le contesté que mi relación con el código es que yo sé cómo funciona y ellos no. Me dijo que estaba exhibiendo ‘posturas defensivas típicas de personalidades resistentes al cambio’.”

Esa noche, Heike envió a Klaus un correo con su carta de renuncia adjunta. “He dado veinte años a esta empresa”, escribía. “No voy a pasarme los últimos años de mi carrera siendo psicoanalizada por gente que no sabría compilar un Hola Mundo.”

Klaus la llamó inmediatamente. Le tomó cuarenta y cinco minutos convencerla de postergar la presentación de la renuncia. “Dame una semana”, dijo. “Si nada cambia, la acepto sin discutir.”

Thomas fue más directo en la siguiente reunión de liderazgo. “Klaus, estos consultores están quemando €15.000 a la semana y empeorando todo. Los desarrolladores que estaban empezando a trabajar juntos ahora están sentados en reuniones dibujando mapas de partes interesadas. Mientras tanto, no se está escribiendo código. Y anoche casi perdemos a Heike — la única persona que realmente puede terminar este proyecto.”

El Dr. Berger defendió su enfoque. “La transformación es incómoda. La resistencia indica que estamos llegando al fondo de los problemas.”

“La resistencia indica que a la gente que construye software no le gusta que la psicoanalice gente que nunca ha construido software”, replicó Thomas.

El punto de quiebre llegó cuando los consultores recomendaron “rotación temporal de roles” para construir empatía — sugiriendo que Heike pasara dos semanas trabajando con el equipo Java mientras un desarrollador Java “seguía” su trabajo en Delphi.

La respuesta de Heike fue gélida. “¿Quieren que alguien que no sabe Object Pascal observe veinte años de trabajo que no puede leer? ¿Y que yo escriba Java, un lenguaje que nunca he usado, mientras el proyecto se desmorona? Esto no es un ejercicio de team building. Esta es una empresa a punto de perder su único producto.”

Klaus finalmente vio lo que Thomas y Heike le venían diciendo durante semanas. Los consultores entendían dinámicas organizacionales genéricas, pero no tenían ni idea de lo que el desarrollo de software realmente requería. Sus marcos trataban toda resistencia como emocional — sin plantearse jamás que alguna resistencia pudiera ser desacuerdo racional de personas que entendían el problema mejor que los propios consultores.

Dio por terminado el compromiso. €90.000 gastados, seis semanas perdidas, y el equipo más dividido que antes.

Klaus se dio cuenta de que había estado buscando una solución externa a un problema interno. El conflicto no era sobre “preparación para el cambio” ni “alineación de partes interesadas”. Era sobre respeto — y el respeto no se fabrica en un taller.

Convocó una reunión — no sobre código, sino sobre cultura. Sin consultores. Sin metodologías. Solo honestidad. “Heike no está aquí para transferir conocimiento y marcharse. Está aquí para ayudarnos a construir algo mejor que lo que teníamos. Cuando el nuevo sistema esté terminado, ella lo habrá moldeado. El que no pueda trabajar con eso, que me lo diga ahora.”

La sala se quedó en silencio.

“Y Heike — te necesito en cada reunión de integración. No como alguien a quien interrogar, sino como la autoridad técnica sobre lo que este sistema realmente hace. Si alguien pone los ojos en blanco, quiero saberlo.”

Heike asintió lentamente. Era la primera vez que Klaus reconocía abiertamente su rol como esencial y no como transitorio.

El equipo se reestructuró. Heike pasó a ser asesora técnica, revisando los diseños antes de la implementación. Los desarrolladores del sistema legado se emparejaron con los nuevos, cada grupo enseñando al otro. Dos contratistas más se fueron — querían proyectos que partieran de cero, no expediciones arqueológicas. Pero los que se quedaron empezaron a entender: el objetivo no era “reemplazar el viejo sistema”, sino “construir la siguiente generación de lo que empezamos”.

El Desafío Multi-inquilino

Ejecutar en las instalaciones del cliente significaba que MaschinenKonfigurator nunca necesitó verdadero multi-tenancy. Cada instalación estaba aislada. Los datos de los clientes no podían filtrarse entre instalaciones porque no había nada hacia donde filtrarse.

SaaS lo cambiaba todo. Múltiples clientes compartirían infraestructura. Sus configuraciones, precios y reglas de negocio necesitaban aislamiento total mientras se ejecutaban en sistemas compartidos.

“Esto no es una funcionalidad”, observó María. “Es una decisión arquitectónica fundamental que afecta todo.”

El equipo ya había construido varias capacidades asumiendo operación de un solo inquilino. Adaptar el multi-tenancy requeriría un retrabajo significativo.

Thomas decidió: “Paramos el desarrollo de funcionalidades por seis semanas. Reconstruimos la base para multi-tenancy antes de seguir adelante.”

Klaus se resistió fuertemente. “¿Seis semanas sin progreso visible? La junta ya está haciendo preguntas. Les dije que estamos en camino.”

“Entonces diles que no estamos en camino”, respondió Thomas. “Porque si seguimos construyendo sobre esta base, estaremos explicando en doce meses por qué necesitamos empezar de nuevo. Otra vez.”

La discusión continuó por una hora. María finalmente rompió el punto muerto: “Klaus, ¿qué conversación quieres tener con la junta — ‘pausamos ocho semanas para arreglar la arquitectura’ o ‘pasamos dieciocho meses construyendo algo que tenemos que tirar’?”

Klaus autorizó la pausa. Fue la decisión más difícil que había tomado desde que empezó el proyecto.

La adaptación de multi-tenancy tomó ocho semanas, no seis. Tocó cada capacidad ya construida.

El retrabajo casi destruyó lo que quedaba de la moral del equipo. Andreas, un desarrollador Java senior que se había unido a tiempo completo después del éxodo de contratistas, confrontó a Thomas en el pasillo. “¿Me estás diciendo que los últimos cuatro meses de mi trabajo se tiran a la basura?”

“Refactorizado, no tirado a la basura.”

“Eso es jerga corporativa para tirado a la basura.” Andreas temblaba visiblemente. “Mudé a mi familia aquí por este trabajo. Dejé una posición estable en Múnich. ¿Y ahora me dices que mi trabajo no cuenta?”

Thomas pasó una hora calmando a Andreas. Otros dos desarrolladores tuvieron reacciones similares — uno amenazó con renunciar en el acto, el otro dejó de hablarle a Thomas por completo durante una semana. La tensión era tan severa que María empezó a hacer reuniones privadas uno a uno solo para dejar que la gente se desahogara sin miedo a ser escuchada.

Thomas pasó horas en esas semanas explicando que el diseño original no estaba mal, solo incompleto para requisitos que se habían vuelto claros después. Algunos desarrolladores aceptaron esto. Otros nunca volvieron a confiar plenamente en la dirección.

Cuando la adaptación estuvo terminada, el sistema podía escalar a cientos de inquilinos sin cambios arquitectónicos. Más importante aún, el equipo había sobrevivido una crisis genuina juntos. Pero las cicatrices quedaron. La confianza, una vez rota, se reconstruye lentamente, si acaso.

Encontrando el Ritmo de Despliegue Correcto

Al principio del proyecto, los despliegues eran eventos importantes. El equipo acumulaba cambios durante semanas, luego desplegaba en una liberación cuidadosamente orquestada. Cada despliegue era estresante — tanto había cambiado que los fallos eran impredecibles.

El equipo de infraestructura, liderado por un ingeniero DevOps llamado Felix, invirtió fuertemente en automatización de despliegues. Orquestación de Kubernetes. Pipelines de pruebas automatizadas. Feature toggles que permitían desplegar código sin activarlo.

Gradualmente, la frecuencia de despliegue aumentó. Semanal se convirtió en diario. Diario se convirtió en múltiples veces al día. Cada despliegue era más pequeño, menor riesgo, más fácil de diagnosticar si algo salía mal.

El cambio psicológico fue profundo. Los desarrolladores dejaron de pensar en términos de liberaciones y empezaron a pensar en términos de mejora continua. Una corrección de error podía llegar a producción en horas. Una nueva capacidad podía lanzarse incrementalmente, habilitada para algunos clientes antes de desplegarse ampliamente.

La Conversación del Ocaso

Dieciocho meses después de que el proyecto comenzara — el cronograma original para el reemplazo completo — aproximadamente el sesenta por ciento de la capacidad de MaschinenKonfigurator existía en la nueva plataforma SaaS. Pero ese sesenta por ciento cubría quizás el noventa por ciento del uso diario de los clientes.

Klaus tenía que decidir: seguir ejecutando ambos sistemas indefinidamente, o empezar a retirar la aplicación legada.

“Algunos clientes se resistirán”, advirtió el director de ventas, Stefan. “Müller Maschinenbau ha estado con nosotros por quince años. Ya se han quejado de la nueva interfaz tres veces.”

“Algunas capacidades que nunca reconstruimos desaparecerán”, advirtió Thomas. “Hay funcionalidades en el sistema Delphi que usan dos clientes. ¿Mantenemos todo el sistema legado ejecutándose para dos clientes?”

Heike habló — algo que hacía más a menudo ahora. “Esos dos clientes nos pagan €180.000 al año combinados. Uno de ellos es el cliente de referencia que usamos en cada presentación de ventas. Si les decimos que su flujo de trabajo se retira, podríamos perderlos.”

La sala se dividió. Ventas quería mantener contentos a todos los clientes. Desarrollo quería dejar de dar soporte a dos sistemas. Finanzas señaló que ejecutar infraestructura paralela costaba €8.000 al mes.

El equipo analizó extensamente la telemetría de uso. Identificaron capacidades que genuinamente importaban versus aquellas que existían solo porque nadie las había eliminado. Hablaron con cada cliente sobre sus necesidades reales versus sus preferencias teóricas.

Klaus tomó la decisión. “Reconstruimos el flujo de trabajo para Müller Maschinenbau. Son tres semanas de trabajo, y mantenemos a nuestro mejor cliente de referencia. Las otras funcionalidades legadas obtienen alternativas documentadas y doce meses de aviso.”

Stefan de ventas no estaba satisfecho. “¿Qué le digo a los clientes que se quejen?”

“Diles la verdad”, dijo Klaus. “Estamos construyendo algo mejor. Algunas cosas no harán la transición. Les ayudaremos a adaptarse.”

El plan de retiro dio a los clientes doce meses de operación paralela. Tres clientes eligieron no migrar y eventualmente se fueron. Dos de ellos habían estado pagando tarifas mínimas y consumiendo recursos de soporte desproporcionados. El tercero, un fabricante mediano, se mudó a un competidor — una pérdida que dolió pero validó que la empresa no podía ser todo para todos.

El Estado Final

Dos años y medio después de que la transformación comenzara, Hartmann & Söhne había completado su viaje. La nueva plataforma — renombrada MachineConfigure para señalar la transición — servía a todos los clientes existentes más nuevos que nunca habrían considerado la aplicación de escritorio legada.

Los resultados superaron las expectativas en algunas áreas y se quedaron cortos en otras:

Rendimiento: El nuevo sistema procesaba configuraciones complejas en segundos en lugar de minutos. Los clientes mencionaban esto constantemente como la mejora más visible.

Accesibilidad: Los equipos en múltiples ubicaciones ahora podían colaborar en configuraciones. El acceso móvil permitía a los representantes de ventas crear cotizaciones en el sitio con los clientes.

Integración: APIs modernas habilitaban conexiones a sistemas ERP, plataformas CAD y canales de comercio electrónico que eran imposibles con la arquitectura legada.

Paridad de funcionalidades: Aproximadamente el ochenta y cinco por ciento de las funcionalidades legadas hicieron la transición. El quince por ciento restante fue reconstruido con enfoques diferentes o retirado completamente.

Cronograma: Dos años y medio en lugar de dieciocho meses. El proyecto tomó más tiempo que la estimación original optimista pero significativamente menos tiempo de lo que habría requerido un enfoque de desarrollo paralelo completo.

Costo: Aproximadamente el doble del presupuesto original — incluyendo €90.000 en consultores de gestión que empeoraron las cosas, meses de productividad perdida por el vacío de conocimiento cuando Jürgen se fue, y el costo de despedir a Martin antes de que Klaus aceptara que el respeto no se puede crear en un taller y la toxicidad no puede tolerarse. Caro, pero la alternativa — continuar manteniendo un sistema legado cada vez más insostenible — habría costado más con el tiempo.

Lecciones del Viaje

Klaus, reflexionando sobre la transformación un año después de completarse, identificó principios que podrían ayudar a otras organizaciones enfrentando desafíos similares:

El conocimiento está en las personas, no en el código. Retener y respetar a los desarrolladores que construyeron el sistema legado resultó más valioso que cualquier documentación. Heike detectó problemas que ninguna prueba automatizada podía encontrar — pero solo después de que el equipo aprendió a escucharla. Los contratistas que despreciaron el conocimiento del equipo legado fueron los primeros en irse. Los que se quedaron aprendieron humildad.

La consultoría de gestión genérica rara vez ayuda en transformaciones técnicas. Los consultores que recomendaron “talleres de alineación de stakeholders” y “evaluaciones de preparación para el cambio” nunca habían entregado software. Trataban el desacuerdo técnico racional como resistencia emocional. Los €90.000 gastados en marcos y estructuras de gobernanza fueron €90.000 no gastados en resolver problemas reales. Cuando tus expertos te dicen que algo no funcionará, considera que podrían tener razón.

La ejecución en paralelo reduce el riesgo dramáticamente. Ejecutar ambos sistemas simultáneamente permitió aprendizaje y ajuste. La capacidad de comparar resultados construyó confianza de que el nuevo sistema realmente funcionaba correctamente.

Los despliegues pequeños y frecuentes lo cambian todo. Pasar de liberaciones big-bang a despliegue continuo transformó la relación del equipo con el riesgo. Los cambios pequeños eran más fáciles de validar y más fáciles de revertir.

El multi-tenancy no es una funcionalidad — es una base. Intentar adaptar el multi-tenancy después de construir capacidades de un solo inquilino desperdició meses. Las decisiones arquitectónicas necesitan tomarse temprano, incluso cuando las funcionalidades parecen más urgentes.

No toda funcionalidad merece sobrevivir. Los sistemas legados acumulan capacidades que sobreviven a su utilidad. La transformación es una oportunidad para podar, no solo para portar.

El cronograma original siempre está equivocado. No porque el equipo no sepa estimar, sino porque no puede saber lo que no sabe. Incorporar contingencia sustancial no es pesimismo — es realismo.

La Historia Continúa

La transformación de Hartmann & Söhne no fue un final. Fue una transición a una nueva forma de operar. El modelo SaaS trajo nuevos desafíos: monitorear el tiempo de actividad entre múltiples clientes, gestionar facturación de suscripciones, manejar requisitos de residencia de datos para clientes internacionales.

Pero la organización también había desarrollado nuevas capacidades. Ahora podían desplegar mejoras a diario en lugar de una vez al año. Podían observar cómo los clientes realmente usaban el sistema, no solo cómo describían su uso. Podían experimentar con funcionalidades antes de comprometerse del todo con ellas.

El mercado de maquinaria especializada seguía necesitando herramientas de configuración sofisticadas. Hartmann & Söhne seguía proporcionándolas. La tecnología había cambiado por completo. La propuesta de valor permanecía intacta.

Heike se jubiló seis meses después del lanzamiento de la nueva plataforma — en sus propios términos, habiendo dado forma al sistema que llevaría su trabajo adelante. En su fiesta de despedida, le dijo a Klaus: “Estuve a punto de renunciar cuando Martin dijo que mi documentación no servía para nada. Me alegro de haberme quedado.”

“Yo también”, respondió Klaus. “No lo habríamos logrado sin ti.”

“No”, coincidió ella. “No habrían podido. Acuérdate de eso la próxima vez que alguien te diga que una reescritura es simple.”

---

Este es un relato ficticio. Cualquier parecido con empresas, eventos o personas reales es pura coincidencia. Ahora bien, si reconociste a tu propia organización en esta historia, eso probablemente no sea coincidencia — es un patrón.