Obsolete internal systems: repair or rebuild?
As the decision between rebuilding and improving is postponed, costs continue to rise. It outlines five signs that indicate when to replace, the method for comparing the cost of maintenance versus replacement, and the execution procedure for incremental migration as an alternative to complete reconstruction.
The situation companies face today
Companies that have been using the same internal system for over ten years often find themselves in a similar situation. The system continues to function. There are no serious incidents. Simply put, a minor request takes two weeks, and there is only one person in the entire company who can handle it.
This situation is dangerous because the problem worsens gradually. A system that stops suddenly receives immediate budget allocation. In contrast, a system that becomes slightly slower and more expensive to maintain each year is dismissed with a ‘we’ve managed this year too.’ When several years accumulate like this, three circumstances arise simultaneously.
First: the person who knows the system retires or leaves the company, taking with them the business rules that were never documented. Second: support for the underlying technology ends; unsupported versions of the language or database do not receive patches even if vulnerabilities are discovered. Third: it becomes impossible to incorporate new requirements; requests such as mobile access, integration with external services, or data analysis are repeatedly rejected with a ‘that cannot be done with the current system.’
When all three circumstances coincide, the only option left is complete reconstruction. And complete reconstruction is the most expensive and riskiest option.
Five signs that it’s time to consider replacement
If three or more of the following points apply, it is time to begin the replacement study.
1. The cost of change is asymmetrical. Adding a single field to a screen takes several days. If the development timeline for a request perceived as trivial hardly differs from that of an important request, the structure can no longer accommodate changes.
2. There is only one maintenance person. A system that only one specific person can touch makes their vacation and potential departure a risk for the business. This is not a human resources issue, but a structural problem.
3. Support for the underlying technology has ended. Check the official end-of-support dates for the runtime environment of the language, the framework, and the database you are using. If those dates have passed, a security incident is only a matter of time.
4. Data cannot be extracted. If someone has to manually write queries or open multiple screens and sum manually to obtain the necessary figures for decision-making, the system is retaining the data.
5. Parallel processes are increasing. If the business area is managing an increasingly broad scope in spreadsheets instead of within the system, it means the system does not reflect the actual work. Since these alternative solutions are not recorded anywhere, the problem is not apparent when only looking at the system.
Calculate the cost of maintenance
The reason the debate about replacement does not progress is often the argument of ‘if it works, why spend money.’ To answer that question, it must be demonstrated with figures that maintenance also incurs costs. Add the following four cost items.
| Cost item | Calculation method |
|---|---|
| Cost of delay | Annual number of change requests × average waiting days × daily opportunity cost |
| Cost of parallel processes | Hours of double management in spreadsheets and similar × 12 months × total labor cost per hour |
| Cost of error handling | Annual number of data errors × hours of remediation per case × total labor cost per hour |
| Cost of risk | Number of unsupported components × estimated recovery cost per incident × probability of occurrence |
The first three items are costs that are already being incurred but do not appear in any accounts. The fourth is a cost that has not yet occurred but accumulates in probabilistic terms.
What follows is a hypothetical example intended to illustrate the calculation method; actual values vary depending on each company’s conditions. If 30 change requests are received per year, with an average wait of 10 days per request, and the daily opportunity cost of that wait is estimated at 150,000 KRW, the cost of delay alone amounts to 45,000,000 KRW annually. If it is added that two departments each spend five hours a week on double management in spreadsheets, with a total labor cost per hour of 25,000 KRW, an additional 13,000,000 KRW per year is added.
If the total is 58,000,000 KRW annually, in three years it amounts to 170,000,000 KRW. It is at this point that a figure comparable to the cost of replacement first appears. Maintenance is not free: it is an expense for which no invoice arrives.
Why complete reconstruction is risky
Once the decision to replace is made, the first method that comes to mind is complete reconstruction: stopping the old, building the new, and changing everything at once on a specific day. It is intuitive, but it carries three risks.
The benefit is zero until the project is completed. In a twelve-month reconstruction, for eleven months the organization only incurs costs and sees no improvements. If the business environment changes during that period, the project is under pressure for cancellation.
Requirements age along the way. The requirements defined at the beginning do not match the needs of the business area a year later. If that difference is incorporated, the schedule is delayed; if it is not incorporated, what is delivered is an already obsolete system.
The risk concentrates at the moment of change. As all functionalities change at once, if a problem arises on the transition day, there is no easy way to roll back. And problems almost always arise because there are undoubtedly exception rules in the old system that no one remembers.
Incremental migration as an alternative
Instead of complete replacement, there is the possibility of maintaining the existing system and migrating functionalities one by one. The order is as follows.
Phase 1 — Define the boundaries
Divide the current system into functional blocks. Separate them by business units — orders, inventory, billing, human resources — but draw the line based on who owns the data. If multiple blocks directly modify the same table, that point will later become the biggest obstacle.
When defining the boundaries, follow the flow of data and not the organizational chart. Even if departments are separate, if they jointly modify the same data, they form a single block; and even if it is a single department, if the data is completely separate, it can be divided.
Phase 2 — Separate reading first
The safest first initiative is the query functionalities. Dashboards, statistics, and reports, which only read data, can be built in the new system without affecting the existing one. Even if they fail, the old screen remains available, making rollback simple, and the business area perceives the improvement immediately.
This phase also brings a side effect. By building the query functionalities, existing data problems come to light: duplicate customers, broken date formats, rows with empty code values. It is important to know these issues before migrating the writing functionalities.
Phase 3 — Migrate Writing Functionalities
Once the verification through the query is complete, the functionalities for creation and modification are transferred. Since both systems will handle the same data for a period, designate one of them as the source. Allowing modifications from both sides will lead to discrepancies, and locating these discrepancies takes more time than the migration itself.
In terms of order, it is prudent to start with functionalities that are infrequently used and have a limited scope. However, if you begin with functionalities that no one uses, verification will not be possible, so the best starting point is a functionality that is actually used but can be paused for a day.
Phase 4 — Reduce the Existing System
The functionalities that have already been migrated must be removed from the existing system. If they are left in place, part of the business area will continue to use the old screens, resulting in both systems being maintained indefinitely. Delaying this phase is the most common cause of failure in an incremental migration.
If removal proves difficult, at least block access and leave them in read-only mode. Set a specific date for their final removal. A cleanup plan without a date will not be executed.
Which of the Two Options to Choose
| Situation | Appropriate Method |
|---|---|
| Business rules are documented and the scope is limited | Complete reconstruction |
| Rules only exist in the code | Incremental migration |
| Service interruption is not allowed | Incremental migration |
| The support for the underlying technology has already ended | Prioritize migrating the security domain |
| The business area works in parallel with spreadsheets | Prioritize migrating the parallel process domain |
Complete reconstruction is not always a mistake. If the scope is limited, business rules are documented, and a few hours of interruption are acceptable, changing everything at once can be faster and more cost-effective. The criterion is not the age of the system, but where the rules are recorded.
Lo que realmente causa problemas en la migración de datos
La causa de los retrasos en el calendario no suele ser el desarrollo de funcionalidades, sino los datos. En los sistemas antiguos se acumulan estados como los siguientes.
- Un mismo cliente registrado varias veces con grafías distintas
- Formatos de fecha, de teléfono y de número de identificación fiscal que difieren según la época
- Filas con campos obligatorios vacíos
- Datos que siguen referenciando valores de código ya suprimidos
- Filas marcadas como eliminadas que en realidad permanecen mezcladas con el resto
Si estos problemas se descubren durante la fase de migración, el calendario se retrasa sin remedio. Investíguelos de antemano, antes de empezar, y determine primero qué ámbito se depura y cuál se descarta. Si se pretende depurar a la perfección todos los datos históricos, la migración no terminará nunca. En muchos casos resulta más realista depurar únicamente los últimos años y conservar el resto en modo de solo consulta.
Una oportunidad para rediseñar la seguridad y los permisos de acceso
La sustitución es también una ocasión poco frecuente para ordenar el sistema de seguridad. Los sistemas antiguos suelen tener una separación laxa de permisos y funcionan con la mayoría del personal en disposición de ver más datos de los necesarios. Defina los siguientes puntos durante el proceso de migración.
Minimización de los permisos de acceso. Diferencie los accesos de modo que cada rol vea únicamente los datos que necesita. Si se traslada tal cual la estructura de permisos del sistema existente, con ella se trasladan también sus defectos.
Ubicación de almacenamiento y plazo de conservación de los datos personales. Determine qué datos personales se almacenan, dónde y cuándo se destruyen. En caso de migrar a la nube, hay que verificar además en qué país quedan almacenados los datos.
Conservación del registro de operaciones. Deje constancia de quién modificó qué y cuándo. Es frecuente que los sistemas antiguos carezcan de este registro y que, ante un problema, no sea posible rastrear su origen.
Cómo convencer a la dirección
El presupuesto de sustitución no suele aprobarse con argumentos técnicos. Explicaciones como «la estructura está obsoleta» o «el soporte técnico ha finalizado» no transmiten urgencia a quien firma. Preséntelas transformadas en los tres puntos siguientes.
El importe que se está perdiendo ahora. Es la suma de los costes de retraso, de procesos paralelos y de errores calculados anteriormente. Lo esencial es que ya se están desembolsando aunque no se sustituya nada.
Lo que no se está pudiendo hacer. Elabore la lista de las peticiones rechazadas durante el último año con el argumento de que «no es posible con el sistema actual». Si alguna de ellas está vinculada a la facturación o a la pérdida de clientes, colóquela en primer lugar. El lucro cesante es un argumento más potente que el coste de mantenimiento.
El peor escenario. Calcule el plazo y el coste de recuperación en caso de que la única persona responsable deje la empresa o de que se produzca un incidente en un componente sin soporte. Aunque la probabilidad sea baja, una magnitud elevada mueve la decisión.
Tras presentar los tres puntos, solicite la aprobación únicamente de la primera fase de la migración incremental. Si se pide todo el presupuesto de una vez, el periodo de estudio se alarga y, entretanto, la situación empeora.
Cómo planificar el calendario y los recursos
En la migración incremental, lo que más a menudo se desvía es el calendario. Incorpore de antemano tres consideraciones.
Incluya en el calendario el tiempo del área de negocio. En un proyecto de migración, el recurso más escaso no son los desarrolladores, sino las personas del área de negocio que conocen las reglas. Como participan sin dejar sus tareas habituales, si no se acuerda previamente el tiempo disponible, el calendario se retrasará en cada fase de verificación.
Incluya en el cálculo el periodo de operación en paralelo. Incluso después de trasladar una funcionalidad hay que operar ambos sistemas conjuntamente durante un tiempo. En ese periodo la carga operativa aumenta en lugar de disminuir. Si no se refleja en el calendario y el presupuesto, en la última fase faltará personal.
Reserve un periodo específico para la depuración de datos. Los problemas de integridad de los datos que se tratan más adelante pueden abordarse en paralelo al desarrollo, pero requieren tiempo y personas propias. Si se ocultan dentro del calendario de desarrollo, el retraso es seguro.
Qué verificar al trabajar con un proveedor externo
En muchos casos resulta difícil llevar a cabo la migración únicamente con recursos internos. Si valora recurrir a un proveedor externo, verifique lo siguiente antes de firmar.
¿Los entregables incluyen documentación? Si solo se recibe el código, el mismo problema se repetirá al cabo de unos años. Los entregables deben incluir la definición de las reglas de negocio, la descripción de la estructura de datos y el manual de procedimientos operativos.
¿Está definida la forma de traspaso posterior a la migración? Una vez finalizada la implantación, el personal interno debe poder operar el sistema. Especifique en el contrato el periodo de traspaso y el alcance de la formación.
¿Es posible contratar por fases? Si se contrata todo de una vez, resulta difícil cambiar de rumbo a mitad de camino. Un esquema en el que se ejecuta la primera fase y después se decide sobre las siguientes es más seguro para ambas partes.
¿Están claros los derechos sobre nuestros datos? Si durante el desarrollo se utilizan datos reales, establezca por escrito qué datos se desplazan, adónde y cómo se destruyen una vez finalizado el trabajo.
Qué preparar antes de empezar
Con independencia del método elegido, asegure estos tres puntos antes de empezar.
Documentación de las reglas de negocio vigentes. Las reglas que solo existen en el código se pierden sin falta durante la migración. No hace falta una especificación perfecta, pero deje por escrito al menos la gestión de excepciones y las condiciones de aprobación.
Revisión de la integridad de los datos. Examine el estado actual conforme a los puntos recogidos anteriormente y determine el ámbito de depuración.
Plan de reversión. Establezca para cada fase cómo se da marcha atrás si surge un problema. Una fase que no se puede revertir es, por eso mismo, una fase demasiado grande, y constituye la señal de que hay que dividirla en partes más pequeñas.
Resumen
El coste de un sistema obsoleto no se manifiesta en forma de averías, sino en forma de retraso y dependencia. Por eso se percibe tarde.
- Revise las cinco señales: coste del cambio, concentración del conocimiento en una persona, fin del soporte técnico, accesibilidad de los datos y procesos paralelos.
- Calcule el coste de mantener con las cuatro partidas —retraso, procesos paralelos, errores y riesgo— y conviértalo en una cifra comparable con el coste de la sustitución.
- Si las reglas solo existen en el código, la reconstrucción completa es arriesgada.
- Empiece migrando las funcionalidades de consulta y elimine sin falta del sistema existente todo lo ya migrado.
- Investigue la integridad de los datos antes de empezar y fije de antemano el ámbito de depuración.
- Aproveche la ocasión para rediseñar a la vez los permisos de acceso y la política de conservación de datos personales.
Más importante que decidir si sustituir o no es no aplazar la decisión. Si concurren tres de las cinco señales, iniciar el estudio dentro de este año sale más barato que acometer una reconstrucción completa el año que viene.