Pillar page
Modernizare sisteme legacy
Refactorizare incrementală monolit la microservicii, migrare de la tehnologii învechite la stacks moderne, migrare în cloud — fără downtime de business, cu plan de rollback și audit trail complet.
Fiecare companie are un sistem legacy. Unele au câteva. O aplicație contabilă din 2008 care cumva încă funcționează. Un CRM scris de consultanți pe care nu îi mai ține minte nimeni. Un depozit care rulează în Access. Fiecare dintre ele va trebui înlocuit la un moment dat — întrebarea nu este dacă, ci când și cum.
Modernizarea sistemelor legacy este unul dintre cele mai dificile tipuri de proiecte IT. Necesită echilibrarea a trei forțe: continuitatea business-ului (sistemul trebuie să funcționeze tot timpul), introducerea tehnologiilor moderne (microservicii, cloud, AI) și controlul riscului (orice refactorizare poate strica ceva ce funcționează de ani de zile).
De ce nu este suficient să „rescrii de la zero"?
Din experiența noastră, 9 din 10 modernizări reușite sunt refactorizări incrementale, nu rescrieri. Rescrierile sunt conceptual tentante („vom porni de la zero"), dar în practică au trei probleme fundamentale:
- Logică de business invizibilă. Sistemul vechi conține ani de reguli de business — condiții speciale pentru cei mai mari clienți, scutiri fiscale pentru industrii specifice, soluții de ocolire pentru reglementări din 2015. Cea mai mare parte nu este documentată. O rescriere trebuie să o recreeze din memoria oamenilor sau din analiza codului.
- Muncă duplicată. În timp ce noul sistem este scris, business-ul cere în continuare modificări în cel vechi (reglementări, clienți noi, bug-uri mici). Echipa fie dublează munca (modificări în două locuri), fie îngheață sistemul vechi (risc de business).
- Deployment big bang. După un an de muncă, noul sistem este „aproape gata". Mutarea tuturor utilizatorilor într-o singură noapte generează un risc monumental. Orice problemă neașteptată înseamnă întoarcerea la sistemul vechi, pierderea moralului echipei și erodarea încrederii business-ului.
Refactorizarea incrementală (de obicei urmând pattern-ul Strangler Fig) rezolvă toate cele trei: logica de business este descoperită gradual, o singură sursă de adevăr pentru fiecare entitate, deployment în etape cu feature flags.
Șase pattern-uri de modernizare
Fiecare adresează un risc specific. În majoritatea proiectelor combinăm mai multe, alegând un pattern per modul.
Strangler Fig
Gradual „înfășurăm" sistemul vechi cu componente noi. Codul vechi încă rulează, dar fiecare funcționalitate nouă merge la un nou microserviciu, iar modulele existente sunt înlocuite unul câte unul. După 12-24 luni, monolitul vechi este oprit.
Anti-corruption layer
Un adaptor care protejează codul nou de ciudățeniile sistemului vechi (nume de câmpuri ilizibile, formate de dată stranii, tipuri inconsistente). Toată logica „urâtă" este izolată într-un singur loc — codul nou operează pe un model curat al domeniului.
Refactorizare bază de date
Pattern-uri din Refactoring Databases (Ambler/Sadalage): expand-and-contract pentru migrările de schemă, validarea datelor înainte de eliminarea coloanelor vechi, rularea ambelor scheme în paralel în timpul migrării aplicației.
Branch by abstraction
Introducerea unui strat de abstractizare în jurul componentei vechi, implementarea componentei noi în paralel, comutarea graduală a traficului de la 0% la 100% (feature flag). Fără deploy „big bang".
Shadow mode
Codul nou rulează în paralel cu cel vechi — ambele procesează aceleași cereri, dar doar rezultatele de la sistemul vechi ajung la utilizator. Rezultatele sunt comparate offline. După confirmarea compatibilității (tipic 2-4 săptămâni) comutăm traficul către codul nou.
Event sourcing pentru migrare
Înregistrăm fluxul de evenimente de business din sistemul vechi și îl redăm în cel nou. Permite validarea preliminară a noii arhitecturi fără risc în producție și abilitatea de a reveni la orice stare istorică.
Plan tipic de modernizare
Pentru un sistem mediu (un monolit de ~200 mii de linii de cod, 5-10 module de business):
- Luna 1: Discovery și documentație. Reverse engineering al arhitecturii, maparea dependențelor, identificarea fluxurilor de date, documentarea proceselor de business cu ajutorul stakeholderilor de business.
- Luna 2: Arhitectura țintă și pilot. Proiectarea noii arhitecturi, alegerea tehnologiei, pilot pe cel mai simplu modul (proof of concept). Prima validare a abordării.
- Lunile 3-4: Decuparea primului modul de producție. Pattern Strangler Fig, shadow mode pentru 2-3 săptămâni, comutare trafic, hypercare. Prima valoare reală de business.
- Lunile 5-12: Decuparea iterativă a modulelor ulterioare. Fiecare într-un ciclu de 4-6 săptămâni: refactorizare → teste → shadow → producție → hypercare. Îmbunătățire continuă a procesului, reducerea timpului per modul.
- Lunile 12-18: Migrare de date și dezafectare monolit. Odată ce toate modulele critice sunt decupate, finalizăm migrarea datelor istorice, oprim sistemul vechi, arhivăm. Sărbătorim.
Sistem vechi vs. modernizat
| Aspect | Sistem legacy (tipic) | După modernizare |
|---|---|---|
| Timp pentru lansarea unui feature nou | 4-8 săptămâni (risc ridicat de regresie) | 3-7 zile (teste automatizate minimizează riscul) |
| Acoperire cu teste | 5-15% (sau deloc) | >80%, în pipeline-ul CI/CD |
| Disponibilitate dezvoltatori | Scăzută (tehnologie învechită) | Ridicată (stacks populare, moderne) |
| Securitate | Biblioteci vechi cu CVE-uri nepatchate | Scanare OWASP, gitleaks, actualizări automate |
| Scalare | Verticală (mai multe resurse pentru monolit) | Orizontală (scalarea microserviciilor specifice) |
| Observabilitate | Loguri în fișiere, fără metrici | Prometheus + Grafana + Sentry + SIEM |
| Conformitate (GDPR, EU AI Act, ISO 27001) | Solicitantă, costisitor de demonstrat | Integrată în arhitectură, gata pentru audit |
Șase riscuri tipice — și cum le adresăm
Risc: Lipsa testelor în sistemul legacy
Mitigare: Mai întâi construim teste de caracterizare (capture tests) — înregistrând comportamentul curent al sistemului pe baza logurilor de producție și a capturilor de trafic. Abia apoi începem refactorizarea, cu testele ca plasă de siguranță.
Risc: Cunoștințe concentrate într-o singură persoană („truck factor 1")
Mitigare: Transferul de cunoștințe începe în prima săptămână a proiectului. Toate întâlnirile cu persoana care cunoaște sistemul sunt înregistrate și transcrise, procesele cheie documentate, deciziile arhitecturale justificate. După proiect, întreaga echipă înțelege sistemul.
Risc: Încetinire temporară a echipei
Mitigare: Pentru primele 2-3 luni echipa întreține sistemul vechi + construiește pe cel nou. O încetinire naturală a vitezei de modificări. O atenuăm: prioritizând modificările care merg doar la noul sistem, înghețând modificările de prioritate scăzută în codul vechi.
Risc: Migrare de date
Mitigare: Fiecare migrare de date are trei faze: dry-run (pe o copie de producție), staging (în mediul de test cu date la scară reală), producție (într-o fereastră de service sau incremental). Plan de rollback pregătit înainte de start.
Risc: Rezistență organizațională
Mitigare: Comunicare cu business-ul din prima zi: de ce modernizăm, ce se schimbă pentru utilizator, care este planul, cum măsurăm succesul. Prima iterație este aleasă pentru a arăta rapid o valoare tangibilă (de exemplu un UI nou sau un raport mai rapid).
Risc: Subestimarea costului
Mitigare: Discovery (1-2 săptămâni) înainte de prețul proiectului. Iterații de 2-3 săptămâni cu livrabile concrete — mai ușor să corectezi cursul decât într-un proiect lung „totul deodată". Buget cu rezervă de 20-30% pentru neprevăzut.
Întrebări frecvente
Ce este un sistem legacy?
De ce să modernizăm dacă sistemul funcționează?
Nu este mai ușor să rescriem totul de la zero?
Necesită modernizarea downtime de business?
Cât durează o modernizare tipică?
De la ce tehnologii migrăm cel mai des?
Ce facem cu integrările existente cu alte sisteme?
Cum reduceți riscul de business?
Ce facem cu documentația sistemului care nu există?
Cum se compară costul modernizării cu mentenanța sistemului vechi?
Să începem cu un audit
Audit tehnic de o săptămână: maparea stării curente, identificarea celor mai urgente zone de modernizare, un plan în faze cu rezultate concrete de business în prima iterație.