Pillar page
Modernització de sistemes llegats
Refactorització incremental d'un monòlit cap a microserveis, migració de tecnologies obsoletes a stacks moderns, trasllat al núvol — sense aturades de negoci, amb pla de rollback i rastre d'auditoria complet.
Tota empresa té algun sistema llegat. Algunes en tenen diversos. L'aplicació de comptabilitat del 2008 que «d'alguna manera» funciona. El CRM escrit per consultors que ja ningú recorda. El magatzem en Access. Tots, tard o d'hora, caldrà substituir-los — la pregunta no és si, sinó quan i com.
La modernització de sistemes llegats és un dels tipus de projecte de TI més difícils. Cal equilibrar tres forces: mantenir la continuïtat de negoci (el sistema ha de funcionar en tot moment), introduir tecnologies modernes (microserveis, núvol, IA) i controlar el risc (cada refactorització pot trencar alguna cosa que feia anys que funcionava).
Per què no n'hi ha prou amb «reescriure-ho tot de zero»?
La nostra experiència mostra que 9 de cada 10 modernitzacions reeixides són refactorització incremental, no rewrite. Els rewrites són atractius per la seva senzillesa conceptual («comencem amb una pissarra en blanc»), però a la pràctica tenen tres problemes fonamentals:
- Lògica de negoci invisible. El sistema antic conté anys de regles de negoci — condicions especials per als clients més grans, exempcions fiscals per a sectors concrets, solucions provisionals per a regulacions del 2015. La majoria no estan documentades. El rewrite ha de reproduir-les totes a partir de la memòria de les persones o de l'anàlisi del codi.
- Duplicació de feina. Mentre s'escriu el sistema nou, el negoci continua exigint canvis a l'antic (regulacions, nous clients, errors menors). L'equip o bé duplica la feina (canvi a dos llocs), o bé congela el sistema antic (risc de negoci).
- Desplegament big bang. Després d'un any de feina, el sistema nou és «gairebé llest». Canviar tots els usuaris en una sola nit genera un risc monumental. Qualsevol problema imprevist obliga a tornar al sistema antic, mata la moral de l'equip i mina la confiança del negoci.
La refactorització incremental (sovint segons el patró Strangler Fig) resol totes tres: la lògica de negoci es va descobrint progressivament, hi ha una sola font de veritat per a cada entitat i el desplegament és per etapes amb feature flags.
Sis patrons de modernització
Cadascun resol un risc concret. En la majoria de projectes en combinem diversos, escollint el patró adequat per a cada mòdul.
Strangler Fig
«Embolicar» gradualment el sistema antic amb components nous. El codi antic segueix funcionant, però cada nova funcionalitat va al microservei nou i els mòduls existents es van substituint un per un. Després de 12-24 mesos, el monòlit antic es desactiva.
Anti-corruption layer
Adaptador que protegeix el codi nou de les rareses del sistema antic (noms de camps il·legibles, formats de data estranys, tipus incoherents). Tota la lògica «lletja» queda aïllada en un sol lloc — el codi nou opera sobre un model de domini net.
Database refactoring
Patrons del llibre Refactoring Databases (Ambler/Sadalage): expand-and-contract per a la migració d'esquemes, validació de dades abans d'eliminar columnes antigues i suport paral·lel dels dos esquemes durant la migració de l'aplicació.
Branch by abstraction
Introducció d'una capa d'abstracció al voltant del component antic, implementació paral·lela del component nou i commutació gradual del 0% al 100% del trànsit (feature flag). Sense desplegament «big bang».
Shadow mode
El codi nou s'executa en paral·lel amb l'antic — tots dos processen les mateixes peticions, però només els resultats de l'antic arriben a l'usuari. Els resultats es comparen offline. Després de confirmar la coincidència (típicament 2-4 setmanes) es commuta el trànsit al codi nou.
Event sourcing per a la migració
Gravem un flux d'esdeveniments de negoci del sistema antic i el reproduïm al nou. Permet validar l'arquitectura nova sense risc en producció i tornar a qualsevol estat històric.
Cronograma típic d'una modernització
Per a un sistema mitjà (monòlit de ~200 mil línies de codi, 5-10 mòduls de negoci):
- Mes 1: Discovery i documentació. Reverse engineering de l'arquitectura, mapeig de dependències, identificació de fluxos de dades, documentació dels processos de negoci amb l'ajuda de les persones de negoci.
- Mes 2: Arquitectura objectiu i pilot. Disseny de la nova arquitectura, tria de tecnologies i pilot sobre el mòdul més senzill (proof of concept). Primera validació de l'enfocament.
- Mesos 3-4: Extracció del primer mòdul de producció. Patró Strangler Fig, shadow mode durant 2-3 setmanes, commutació de trànsit, hypercare. Primer valor de negoci real.
- Mesos 5-12: Extracció iterativa de la resta de mòduls. Cada mòdul en un cicle de 4-6 setmanes: refactorització → proves → shadow → producció → hypercare. Millora contínua del procés, reducció de temps per als mòduls següents.
- Mesos 12-18: Migració de dades i retirada del monòlit. Quan tots els mòduls crítics ja estan extrets, finalitzem la migració de dades històriques, apaguem el sistema antic i l'arxivem. A celebrar.
Sistema antic vs. modernitzat
| Aspecte | Sistema llegat (típicament) | Després de la modernització |
|---|---|---|
| Temps d'implementació d'una funcionalitat nova | 4-8 setmanes (risc alt de regressió) | 3-7 dies (les proves automàtiques redueixen el risc) |
| Cobertura de proves | 5-15% (o cap) | >80%, dins del pipeline CI/CD |
| Disponibilitat de desenvolupadors | Baixa (tecnologia obsoleta) | Alta (stacks moderns i populars) |
| Seguretat | Llibreries antigues amb vulnerabilitats CVE | Escaneig OWASP, gitleaks i actualitzacions automàtiques |
| Escalat | Vertical (més recursos per al monòlit) | Horitzontal (escalat de microserveis concrets) |
| Observabilitat | Logs en fitxers, sense mètriques | Prometheus + Grafana + Sentry + SIEM |
| Compliance (RGPD, EU AI Act, ISO 27001) | Exigent, costós de demostrar | Integrat a l'arquitectura, llest per a auditoria |
Sis riscos típics — i com els abordem
Risc: manca de proves al sistema llegat
Mitigació: Primer construïm proves de caracterització (capture tests) — gravem el comportament actual del sistema a partir de logs de producció i gravacions de trànsit. Només llavors iniciem la refactorització, amb les proves com a xarxa de seguretat.
Risc: coneixement concentrat en una sola persona («truck factor 1»)
Mitigació: El traspàs de coneixement comença la primera setmana del projecte. Totes les reunions amb la persona que coneix el sistema es graven i es transcriuen, els processos clau es documenten i les decisions arquitectòniques es justifiquen. Després del projecte, tot l'equip entén el sistema.
Risc: alentiment temporal de l'equip
Mitigació: Durant els primers 2-3 mesos, l'equip manté el sistema antic + construeix el nou. És natural que el ritme de canvis es redueixi. Ho mitiguem: prioritat als canvis que vagin només al sistema nou i freeze dels canvis de baixa prioritat al codi antic.
Risc: migració de dades
Mitigació: Cada migració de dades té tres fases: dry-run (sobre una còpia de producció), staging (en entorn de test amb escala real de dades) i producció (en finestra de manteniment o incrementalment). Pla de rollback llest abans d'iniciar.
Risc: resistència organitzativa
Mitigació: Comunicació amb el negoci des del primer dia: per què la modernització, què canvia per a l'usuari, quin és el calendari i com es mesura l'èxit. La primera iteració s'escull per demostrar valor tangible aviat (per exemple, una UI nova o un informe més ràpid).
Risc: subestimació del cost
Mitigació: Discovery (1-2 setmanes) abans del pressupost del projecte. Iteracions de 2-3 setmanes amb resultats concrets — més fàcil corregir el rumb que en un projecte llarg «tot d'un cop». Pressupost amb marge del 20-30% per a imprevistos.
Preguntes freqüents
Què és un sistema llegat?
Per què val la pena modernitzar si el sistema funciona?
No és més fàcil reescriure-ho tot de nou?
La modernització implica una aturada de negoci?
Quant dura una modernització típica?
Des de quines tecnologies migrem amb més freqüència?
Què passa amb les integracions existents amb altres sistemes?
Com limiteu el risc de negoci?
Què passa amb la documentació del sistema, si no n'hi ha?
Quins són els costos de la modernització comparats amb mantenir el sistema antic?
Comencem amb una auditoria
Auditoria tècnica d'una setmana: mapeig de l'estat actual, identificació de les àrees més urgents de modernització i pla per etapes amb resultats de negoci concrets a la primera iteració.