Perspective

Asigurătorii în 2026 sunt prinși între două presiuni: reglementarea — IDD, DORA, EU AI Act — cere căi de modernizare demonstrabile, iar mainframe-urile COBOL și monoliții Java vechi de douăzeci de ani erodează marja prin costuri de mentenanță care cresc cu două cifre anual. Tentația de a mai aștepta „încă un an" nu a fost niciodată mai scumpă.

Acest articol este playbook-ul pe care îl aplicăm la Softescu pe fiecare angajament de modernizare în asigurări: de ce 2026 nu mai lasă loc de amânare, care sunt cele trei căi de modernizare care funcționează în practică, cum se face migrarea de date fără întreruperi operaționale, cum păstrezi underwriter-ul și clientul final în paralel, și cele patru anti-patterns pe care le vedem repetat în proiecte reale.

De ce asigurătorii nu mai pot aștepta

Trei factori forțează decizia în acest an:

• Reglementar — DORA este în vigoare din ianuarie 2025 și cere reziliență ICT demonstrabilă cu obligații de testare și raportare pe care sistemele legacy nu le pot îndeplini. EU AI Act aduce în 2026 primele clasificări de risc ridicat pentru underwriting în asigurări. Ambele cer interfețe API, observabilitate și audit trails pe care mainframe-urile nu le oferă.
• Economic — costurile de mentenanță pentru estate COBOL/RPG cresc cu 12–18 % pe an pentru că forța de muncă iese din piață. Asigurătorii cu care lucrăm raportează că 40–60 % din bugetul lor IT pleacă pe mentenanță pură.
• Dinspre client — clienții finali compară aplicațiile de asigurări cu aplicațiile bancare. O notificare de daună prin telefon și PDF pierde cotă de piață în fața insurtech-urilor cu intake bazat pe aplicație în 90 de secunde.

Consecința: modernizarea în 2026 nu mai este o opțiune tehnică. Este o decizie de business cu deadline reglementar și financiar dur.

Cele trei căi de modernizare — când se potrivește fiecare

În asigurări s-au consacrat trei pattern-uri de modernizare. Alegerea depinde de profilul de risc, complexitatea datelor și durata de viață rămasă a sistemului legacy.

Calea 1 — Strangler Fig. Pattern-ul lui Martin Fowler este răspunsul corect când sistemul legacy este folosit activ, business-ul nu poate sta și riscul trebuie distribuit. Construiești funcționalități noi într-o arhitectură modernă — tipic o platformă de servicii cu Drupal/Symfony sau .NET ca strat de frontend și microservicii pe domeniu — și rutezi treptat căile vechi peste cele noi. Se potrivește când sistemul legacy mai poate rula în paralel 12–24 luni, domeniul se descompune în 8–15 bounded contexts, iar scrierile paralele pot fi păstrate consistente.

Calea 2 — Rewrite. Un rewrite complet este alegerea corectă când legacy-ul este atât de îndatorat tehnic încât extinderile Strangler costă mai mult decât un greenfield, când domeniul se schimbă fundamental (Solvency II Review, linii noi de produs), sau când un downtime limitat este acceptabil (sisteme interne, zone de inovație). Anti-pattern: alegerea rewrite-ului ca default pentru că „în sfârșit trebuie făcut curat". Rewrite-urile sunt scumpe, riscante și eșuează frecvent în asigurări după 18–36 de luni din cauza derivei de cerințe.

Calea 3 — Coexistence. Sistemul legacy rămâne permanent ca system of record pentru date sensibile reglementar (polițe, daune, contabilitate). Funcționalitatea nouă rulează într-un stack modern care vorbește cu legacy-ul prin API. Frecvent pentru asigurători cu sisteme core ca SAP FS-CD, msg.PMQ sau COR&FJA, unde o mutare completă de date nu este fezabilă reglementar sau contractual. Anti-pattern: declararea coexistence-ului ca soluție permanentă fără plan de exit. Fără deadline, pattern-ul degenerează în două sisteme permanent sincronizate cu mentenanță dublă.

Migrarea de date cu rulare paralelă și rollback

Migrarea de date este punctul în care majoritatea proiectelor de asigurări se împotmolesc. Metodologia noastră:

1. Schema mapping cu ipoteze documentate — fiecare regulă de mapare are o tabelă sursă, o tabelă țintă, o funcție de transformare și un catalog explicit de edge cases (tratarea NULL, formate istorice de date, caractere speciale, câmpuri multi-tenant).
2. Faza de rulare paralelă (3–6 luni) — ambele sisteme scriu în paralel. Un consistency worker compară 100 % din scrieri în ambele sisteme și alertează la divergență. Path-ul de citire migrează doar când rata de divergență scade sub 0,01 %.
3. Plan de rollback cu snapshot de date — înainte de cutover, un snapshot complet al legacy-ului este înghețat. Dacă apar divergențe critice în primele 30 de zile post-cutover, se poate face switch back fără pierdere de date.
4. Cutover blended — switch-ul propriu-zis se întâmplă noaptea, cu o fereastră read-only de două ore pentru sincronizarea finală. Clienții finali văd „fereastră de mentenanță două ore"; underwriter-ii au mod read-only.

Am aplicat metoda asta la un asigurător regional al cărui sistem core conținea 14 milioane de polițe. Cutover fără întreruperi operaționale, rata de divergență la 0,003 % după 60 de zile de rulare paralelă.

Digital experience: underwriter și client final în paralel

Cea mai frecventă greșeală în modernizarea de asigurări este să prioritizezi aplicația pentru clienți și să tratezi interfața internă pentru underwriter ca „vine mai târziu". Rezultatul: o aplicație frumoasă pentru clienți, dar underwriter-ii continuă să lucreze în terminale green-screen din anii '90 și să comute manual între sisteme ca să verifice o poliță.

Secvența noastră:

1. Cockpit pentru underwriter, mai întâi — o interfață web modernă care agregă toate sursele de date relevante (poliță, daună, scor de risc, date externe) într-o singură vizualizare. Asta ridică vizibil atât timpul de procesare cât și calitatea datelor.
2. Aplicația pentru clienți pe același strat de servicii — API-urile folosite de cockpit-ul de underwriter sunt reutilizate pentru aplicația de client. Asta evită problema clasică a două stack-uri paralele cu modele de date diferite.
3. Tooling-ul de vânzări ca o consecință — odată ce underwriter-ii și clienții lucrează pe același model de date, tooling-ul de vânzări devine aproape trivial: aceleași API-uri, altă interfață.

Pe unul dintre angajamentele noastre de asigurări, secvența a rulat 14 luni cap-coadă: cockpit underwriter (lunile 1–6), aplicație client (lunile 7–11), portal vânzări (lunile 12–14). Stratul comun de servicii a redus timpul de dezvoltare pentru modulele ulterioare cu 40–50 %.

Patru anti-patterns din proiecte reale

1. „Lift and shift" fără refactoring. Legacy-ul este mutat unu-la-unu în cloud, fără modernizare. Rezultat: costuri mai mari decât înainte (cloud compute este mai scump decât on-prem bine folosit), nicio îmbunătățire arhitecturală, niciun business value. Lift and shift are sens doar ca treaptă intermediară înainte de un Strangler Fig, niciodată ca stare finală.

2. Cutover big-bang fără rulare paralelă. Sistemul nou intră live la o dată țintă, cel vechi se oprește. Când apar divergențe — și apar întotdeauna — nu există fallback. Am preluat proiecte în care cutover-ul big-bang a dus la săptămâni de operațiuni de criză.

3. Microservicii fără bounded contexts. Domeniul este spart în 80 de microservicii tehnice care lovesc toate aceleași baze de date. Rezultat: un monolit distribuit cu mai multă complexitate și același cuplaj ca înainte. Bounded contexts trebuie să vină înaintea serviciilor, nu după.

4. Modernizare fără implicarea underwriter-ilor. Departamentul IT decide roadmap-ul fără să discute cu underwriter-ii și operatorii de daune. Interfața nouă este curată tehnic dar inutilizabilă pentru munca de zi cu zi. Rezervăm cel puțin două săptămâni de discovery on-site cu utilizatorii reali în fiecare angajament de asigurări.

Cum abordăm asta la Softescu

În ultimul deceniu am lucrat la proiecte de modernizare în asigurări pe tot spectrul — de la raportare Solvency II driven de regulator, la modernizarea platformelor de daune, la migrarea de date din estate-uri mainframe vechi de 30 de ani. Firul comun: modernizarea în asigurări nu este un proiect tehnic, este un proiect de business cu pârghie IT. Întrebările reglementare, organizaționale și de date trebuie rezolvate înaintea deciziilor de arhitectură.

Dacă echipa ta planifică o modernizare de asigurări — discovery, review-uri de arhitectură, o echipă dedicată de livrare sau un angajament enterprise web complet — contactează-ne.