Aging Internal System: Repair or Rebuild
As the decision between redesign and improvement is postponed, costs continue to rise. Here are five signals to identify when replacement is necessary, a method to compare the cost of maintenance versus replacement, and a procedure for executing a gradual migration instead of a complete redesign.
The situation businesses face today
Companies with internal systems that have been in service for over ten years often find themselves in the same situation. The system is still operational. There have been no major failures. However, even the simplest requests take two weeks, and only one person in the company is capable of handling them.
This situation is dangerous because the problem deteriorates gradually. A system that fails suddenly receives immediate budget approval. But a system that slows down slightly and requires a bit more work each year passes the annual review with the comment: 'This year, we managed to get by.' As these years accumulate, three deadlines occur simultaneously.
First, the employee who knows the system retires. The undocumented business rules disappear with them. Second, the security support for the foundational technologies ends. For a language or database version that is no longer maintained, no patches are released when a vulnerability is discovered. Third, it becomes impossible to add new requirements. Mobile support, integration of external services, or data analysis are continuously met with the response: 'This is not possible with the current system.'
When these three deadlines occur together, the only remaining option is a complete redesign. However, a complete redesign is the most expensive and riskiest option.
Five Signals That Indicate It's Time to Consider Replacement
If at least three of the following points apply to you, it is time to begin examining a replacement.
1. The cost of change is asymmetrical. Adding a field to a screen takes several days. When, from the user's perspective, the development time for a minor request and that for a major request differ little, the structure can no longer support change.
2. Maintenance relies on a single person. A system that only one person can touch makes their absence or departure a risk for the business. This is not a human resources issue but a structural problem.
3. Support for foundational technologies has ended. Check the official end-of-support dates for the execution engine of the language, the framework, and the database used. If they have already passed, a security incident is only a matter of time.
4. Data cannot be utilized. If obtaining the necessary figures for a management decision requires an employee to write a query themselves or to open multiple screens to manually add up numbers, it indicates that the system locks the data.
5. Workarounds are multiplying. If the scope that the business manages in spreadsheets rather than in the system is expanding, it means the system no longer reflects the actual work. This workaround is not documented anywhere, so the problem remains invisible as long as only the system is observed.
Calculate the Cost of Maintenance
If the debate about replacement is not progressing, it is usually due to one question: 'Why spend money when it still works?' To answer this, it is necessary to demonstrate with figures that maintenance also incurs costs. Add up the following four cost items.
| Cost Item | Calculation Method |
|---|---|
| Cost of Delays | Annual number of change requests × average number of days waiting × daily opportunity cost |
| Cost of Workarounds | Time spent on double management in spreadsheets or otherwise × 12 months × full hourly wage |
| Cost of Error Handling | Annual number of data errors × time to correct per case × full hourly wage |
| Cost of Risk | Number of components at end of support × estimated recovery cost in case of incident × probability of occurrence |
The first three items correspond to expenses already incurred but that do not appear on any account. The fourth corresponds to a cost that is not yet realized but accumulates in probability.
The following is a hypothetical example intended to illustrate the calculation method; actual values vary depending on the specific conditions of each company. With 30 change requests per year, an average wait of 10 days per request, and a daily opportunity cost of the wait set at 150,000 KRW, the cost of delays alone reaches 45,000,000 KRW per year. If, additionally, two departments each spend five hours per week on double management in spreadsheets, an additional 13,000,000 KRW per year is added based on a full hourly wage of 25,000 KRW.
If the total amounts to 58,000,000 KRW per year, it represents 170,000,000 KRW over three years. It is only at this point that a figure comparable to the cost of a replacement appears. Maintenance is not free: it is an expense for which no invoice arrives.
Why Complete Redesign is Risky
Once the decision to replace is made, the first method that comes to mind is a complete redesign: stop the old system, build the new one, and switch over all at once on a given day. This approach is intuitive, but it carries three risks.
The benefit remains zero until the end of the project. For a twelve-month redesign, the organization pays for eleven months without seeing any improvement. If the economic context changes during this period, the project faces pressure to halt.
Requirements age along the way. The requirements established at the launch differ from the needs expressed by the business a year later. Reflecting this gap shifts the timeline; failing to reflect it results in a system that is already outdated.
Risk concentrates at the time of the switch. With all functions changing at once, there is little means to revert if an incident occurs on the day of the switch. And an incident almost always occurs, as there invariably remain exceptional rules in the old system that no one remembers.
Gradual Migration as an Alternative
Rather than a complete replacement, there is an approach that involves transferring functions one by one while retaining the existing system. The order is as follows.
Step 1 — Define the Boundaries
Break down the current system into functional blocks. Segment by business unit — orders, inventory, billing, human resources — but draw the lines according to the data owner. If multiple blocks directly modify the same table, this point will later become the main obstacle.
To define these boundaries, follow the data flows rather than the organizational chart. If two distinct departments jointly modify the same data, they form a single block; and if, within the same department, the data is completely separated, segmentation is possible.
Step 2 — Separate the Read Functions First
The safest initial task concerns the consultation functions. Dashboards, statistics, reports: functions that merely read data can be built in the new system without affecting the existing one. In case of failure, the current screens remain, reverting is simple, and the business immediately perceives the improvement.
This step produces an additional side effect. By building the consultation functions, the defects in the existing data become apparent: duplicate customers, corrupted date formats, lines with empty code values. It is essential to uncover these defects before transferring the write functions.
Step 3 — Transfer the Write Functions
Once verification through consultation is complete, transfer the input and modification functions. With two systems manipulating the same data for a time, designate one side as the reference source. Allowing both sides to modify simultaneously creates inconsistencies that take more time to resolve than the migration itself.
For the transfer order, starting with less used and low-impact functions is safer. However, transferring functions that no one uses first does not allow for any verification: a function that is actually used but whose downtime of one day would be tolerable is the best starting point.
Step 4 — Reduce the Existing System
The transferred functions must be removed from the existing system. If they are left in place, some business units will continue to use the old screens, and the company will end up maintaining two systems indefinitely. Delaying this step is the most common cause of failure in a gradual migration.
If removal is difficult, at a minimum, restrict access and set the function to read-only. Then establish a date for its final removal. A cleanup plan without a date is never executed.
Which Option to Choose
| Situation | Appropriate Approach |
|---|---|
| Documented business rules and limited scope | Complete Redesign |
| Rules present only in the code | Gradual Migration |
| No service interruption tolerated | Gradual Migration |
| Support des technologies socles déjà terminé | Migrer en priorité le périmètre de sécurité |
| Métiers travaillant en contournement sous tableur | Migrer en priorité le périmètre contourné |
La refonte complète n'est pas toujours un mauvais choix. Si le périmètre est restreint, si les règles métier sont consignées dans des documents et si quelques heures d'interruption sont tolérables, changer en une fois est plus rapide et moins coûteux. Le critère de décision n'est pas l'âge du système mais l'endroit où les règles sont consignées.
Ce qui pose réellement problème lors de la migration des données
Les retards de calendrier tiennent le plus souvent aux données et non au développement des fonctions. Les systèmes anciens accumulent des situations telles que les suivantes.
- Un même client enregistré plusieurs fois sous des libellés différents
- Des formats de dates, de numéros de téléphone et de numéros d'entreprise variant selon les périodes
- Des lignes vides sur des champs pourtant obligatoires
- Des données faisant référence à des valeurs de code désormais supprimées
- Des lignes seulement marquées comme supprimées mais physiquement conservées
Découverts pendant la phase de migration, ces problèmes décalent immanquablement le calendrier. Enquêtez en amont, avant le lancement, et déterminez d'abord ce qui sera nettoyé et ce qui sera abandonné. Vouloir assainir parfaitement l'intégralité des données historiques empêche la migration d'aboutir. Nettoyer les seules dernières années et conserver le reste en consultation seule est souvent l'option réaliste.
L'occasion de reconcevoir la sécurité et les droits d'accès
Un remplacement constitue aussi une occasion rare de remettre en ordre le dispositif de sécurité. Les systèmes anciens présentent généralement une séparation des droits relâchée, la plupart des collaborateurs pouvant consulter davantage de données que nécessaire. Traitez les points suivants au cours de la migration.
La minimisation des droits d'accès. Faites en sorte que chaque rôle ne voie que les données qui lui sont nécessaires. Reprendre telle quelle la structure de droits du système existant revient à transférer aussi ses défauts.
Le lieu de stockage et la durée de conservation des données à caractère personnel. Établissez quelles données personnelles sont stockées, où, et à quel moment elles sont détruites. En cas de migration vers le nuage, le pays de stockage des données doit également être vérifié.
La conservation de l'historique des traitements. Consignez qui a modifié quoi et quand. Faute de cet enregistrement, de nombreux systèmes anciens ne permettent pas de remonter à la cause lorsqu'un incident survient.
Comment convaincre la direction
Le budget d'un remplacement passe rarement sur une argumentation technique. « La structure est vieillissante », « le support technique a pris fin » : ces explications ne se traduisent pas en urgence pour un décideur. Reformulez-les selon les trois axes suivants.
Le montant qui fuit aujourd'hui. C'est le total des coûts de retard, de contournement et d'erreur calculés plus haut. Le point essentiel est que cette dépense est déjà engagée, remplacement ou non.
Ce que l'on ne parvient pas à faire. Dressez la liste des demandes rejetées au cours de l'année écoulée au motif que « le système actuel ne le permet pas ». Placez en tête celles qui touchent au chiffre d'affaires ou à la perte de clients. Le manque à gagner est un argument plus puissant que le coût de maintien.
Le pire scénario. Estimez la durée et le coût du rétablissement si l'unique responsable venait à partir ou si un incident survenait sur un composant en fin de support. Même à faible probabilité, une ampleur élevée fait bouger la décision.
Après avoir exposé ces trois axes, ne demandez l'approbation que pour la première étape de la migration progressive. Réclamer l'intégralité du budget en une fois allonge la durée d'examen, et la situation se dégrade entre-temps.
Comment établir le calendrier et les ressources
Dans une migration progressive, c'est souvent le calendrier qui dérape. Intégrez trois éléments par avance.
Inscrivez le temps des métiers au calendrier. Dans un projet de migration, la ressource la plus rare n'est pas le développeur mais le collaborateur métier qui connaît les règles. Ces personnes participent en parallèle de leur activité principale : sans accord préalable sur le temps qu'elles peuvent y consacrer, chaque phase de vérification prend du retard.
Intégrez au calcul la période d'exploitation en parallèle. Après le transfert d'une fonction, les deux systèmes doivent coexister pendant un certain temps. Pendant cette période, la charge d'exploitation augmente au lieu de diminuer. Ne pas en tenir compte dans le calendrier et le budget conduit à un manque de ressources lors de la dernière étape.
Prévoyez une période distincte pour le nettoyage des données. Les questions d'intégrité des données évoquées plus loin peuvent être traitées en parallèle du développement, mais elles réclament un temps et des personnes dédiés. Noyées dans le calendrier de développement, elles prendront du retard à coup sûr.
Ce qu'il faut vérifier avec un prestataire externe
Il est fréquent qu'une migration ne puisse être menée avec les seules ressources internes. Si vous envisagez un prestataire externe, vérifiez les points suivants avant la signature.
Les livrables comprennent-ils de la documentation ? Ne recevoir que du code fait réapparaître le même problème quelques années plus tard. Le référentiel des règles métier, la description de la structure des données et les procédures d'exploitation doivent figurer parmi les livrables.
Les modalités de transfert de compétences après la migration sont-elles définies ? Une fois la mise en œuvre achevée, les équipes internes doivent pouvoir exploiter le système. Précisez au contrat la durée du transfert de compétences et le périmètre de la formation.
Le contrat peut-il être découpé par étapes ? Contracter l'ensemble en une fois rend difficile tout changement de cap en cours de route. Réaliser la première étape puis décider de la suite est une structure plus sûre pour les deux parties.
Les droits sur nos données sont-ils clairs ? Si des données réelles sont utilisées durant le développement, fixez par écrit quelles données se déplacent, vers où, et comment elles sont détruites à la fin.
Ce qu'il faut préparer avant le lancement
Quelle que soit l'approche retenue, assurez-vous des trois éléments suivants avant le lancement.
La documentation des règles métier en vigueur. Les règles qui n'existent que dans le code sont immanquablement perdues au cours de la migration. Sans viser une spécification parfaite, consignez au moins par écrit la gestion des exceptions et les conditions d'approbation.
Le contrôle de l'intégrité des données. Examinez l'état actuel au regard des points énumérés plus haut et déterminez le périmètre du nettoyage.
Un plan de retour en arrière. Pour chaque étape, définissez comment revenir en arrière en cas de problème. Une étape irréversible est en elle-même une étape trop grande : c'est le signe qu'il faut la découper plus finement.
Synthèse
Le coût d'un système vieillissant ne se manifeste pas sous forme de pannes mais sous forme de retards et de dépendance. C'est pourquoi il est perçu tardivement.
- Examinez les cinq points suivants : coût du changement, concentration des compétences, fin du support technique, accessibilité des données, contournements.
- Calculez le coût du maintien selon les quatre postes retards, contournements, erreurs et risque, afin d'obtenir un chiffre comparable au coût d'un remplacement.
- Si les règles n'existent que dans le code, la refonte complète est risquée.
- Transférez d'abord les fonctions de consultation, et supprimez impérativement du système existant les fonctions transférées.
- Examinez l'intégrité des données avant le lancement et fixez à l'avance le périmètre du nettoyage.
- Profitez de cette occasion pour reconcevoir les droits d'accès et la politique de conservation des données à caractère personnel.
Plus important que la décision de remplacer est le fait de ne pas la repousser. Si trois des cinq signaux vous concernent, engager l'examen dans l'année revient moins cher qu'une refonte complète l'année suivante.