Modernizarea aplicațiilor legacy fără a opri afacerea

Aproape orice afacere care funcționează de câțiva ani buni are cel puțin o aplicație „care merge, dar de care nimeni nu se atinge”. Codul e vechi, documentația lipsește, iar oamenii care l-au scris au plecat de mult. Sistemul încă aduce venituri, așa că e tentant să-l lași în pace — până în ziua în care un mic bug blochează facturarea sau o cerință nouă devine imposibil de implementat.

Vestea bună este că modernizarea nu înseamnă neapărat să oprești totul și să rescrii de la zero. În acest articol îți arătăm cum abordăm noi, la CraftWork, un proiect de modernizare legacy: incremental, cu riscuri controlate și cu afacerea funcționând în tot acest timp.

De ce un sistem legacy devine, în timp, o răspundere

„Legacy” nu înseamnă doar „vechi”. Înseamnă cod pe care e din ce în ce mai greu și mai scump să-l schimbi în siguranță. Semnalele apar treptat:

• Costul schimbărilor crește: o modificare care ar fi durat o zi cere acum două săptămâni și teste manuale interminabile.
• Riscul de securitate se acumulează: framework-uri și biblioteci care nu mai primesc actualizări devin poartă de intrare pentru atacuri.
• Angajarea devine grea: puțini dezvoltatori vor să lucreze cu tehnologii moarte, iar cei care știu sistemul devin un punct unic de eșec.
• Integrarea cu unelte noi (plăți, AI, servicii cloud) este blocată de o arhitectură care nu a fost gândită pentru așa ceva.

Capcana rescrierii „big-bang”

Reacția instinctivă este seducătoare: „hai să rescriem totul curat, modern, o dată pentru totdeauna”. În practică, rescrierea de la zero e una dintre cele mai riscante decizii tehnice pe care le poți lua. Cât timp echipa construiește noul sistem în paralel, cel vechi continuă să evolueze — apar bug-uri de reparat, cereri de la clienți, reguli de business nescrise nicăieri, dar codificate în cod. Noua versiune vânează mereu o țintă în mișcare și, de multe ori, e livrată cu luni sau ani întârziere, exact când bugetul și răbdarea s-au epuizat.

Strangler-fig: înlocuire, bucată cu bucată

Alternativa pe care o preferăm se numește „strangler-fig”, după planta care crește în jurul unui copac și îl înlocuiește treptat. Ideea: pui o barieră (un router, un proxy, un API gateway) în fața sistemului vechi și începi să redirecționezi, funcție cu funcție, traficul către module noi. Sistemul legacy rămâne în producție și continuă să deservească tot ce nu ai migrat încă, iar clientul nu observă nicio întrerupere.

Ca să alegi ce modernizezi mai întâi, caută modulele aflate la intersecția dintre valoare mare pentru afacere și durere mare la mentenanță. Un exercițiu simplu de prioritizare:

• Începe cu o felie mică, dar reală — un flux complet, nu o funcție izolată — ca să validezi abordarea end-to-end.
• Prioritizează zonele care se schimbă des sau care blochează cereri noi de business; aici modernizarea aduce câștig imediat.
• Lasă pentru mai târziu modulele stabile, care „merg” și nu se ating de luni de zile — nu ard timpul acolo.
• Măsoară progresul concret: procentul de trafic servit de codul nou, timpul mediu de livrare a unei schimbări, numărul de incidente.

Regula noastră: nicio etapă de modernizare nu ar trebui să dureze mai mult de câteva săptămâni până la o versiune livrabilă în producție. Dacă un pas devine un proiect de sine stătător, l-ai împărțit greșit.

Protejează datele și implică echipa

Datele sunt partea cea mai delicată a oricărei migrări — codul îl poți relansa, datele pierdute nu se mai întorc. Rulează sistemul vechi și cel nou în paralel o perioadă, sincronizează-le și compară rezultatele înainte de a comuta definitiv. Fă backup-uri verificate (nu doar existente), migrează în loturi mici și reversibile și păstrează o cale clară de revenire la fiecare pas. La fel de important este oamenii: implică echipa care cunoaște regulile de business nescrise, documentează pe măsură ce descoperi și transformă modernizarea într-o ocazie de a împărtăși cunoașterea, nu de a o concentra din nou într-o singură persoană.

Când o rescriere completă chiar merită

Modernizarea incrementală nu e un dogmatism. Uneori, refactorizarea treptată e răspunsul corect; alteori, o rescriere țintită se justifică — de exemplu când tehnologia de bază nu mai are suport ori talent disponibil, când modelul de date fundamental nu mai poate susține direcția afacerii, sau când sistemul e mic și izolat, iar rescrierea lui e o chestiune de zile, nu de ani. Cheia e să decizi conștient, pe baza costului și a riscului, nu din entuziasm pentru tehnologii noi. De cele mai multe ori, un mix — refactor unde se poate, înlocuire unde trebuie — bate ambele extreme.

Concluzie

Modernizarea legacy nu trebuie să fie un salt în gol. Cu tiparul strangler-fig, priorități clare și grijă față de date, îți poți aduce sistemul în prezent fără să oprești afacerea nicio zi. Dacă ai o aplicație de care „nimeni nu se mai atinge”, scrie-ne — facem împreună o evaluare rapidă și îți arătăm de unde poți începe cu cel mai mic risc și cel mai mare câștig.