Migrarea bazei de date fără să pierzi date: lecții din proiecte reale

Strategii de backup, rollback și zero-downtime migration pentru aplicații business — lecții din proiecte reale despre migrarea bazei de date fără pierderi.

Migrarea unei baze de date este una dintre cele mai sensibile operațiuni dintr-un proiect software. Pentru utilizatorul final, totul pare simplu: aplicația trebuie să funcționeze la fel ca înainte, poate chiar mai bine. Pentru echipa tehnică, însă, migrarea înseamnă planificare, risc, testare, backup, sincronizare, validare și un plan clar de revenire dacă ceva nu merge bine.

O bază de date nu este doar un loc unde sunt stocate informații. Este memoria aplicației. Acolo se află utilizatorii, comenzile, facturile, contractele, documentele, plățile, istoricul activității, setările, rapoartele și multe alte date critice. Dacă o migrare este făcută superficial, consecințele pot fi serioase: date pierdute, aplicație indisponibilă, rapoarte greșite, clienți nemulțumiți și costuri mari de recuperare.

O migrare de bază de date nu trebuie tratată ca un simplu task tehnic. Este un proiect în sine.

De ce ajung companiile să migreze baza de date?

Migrarea apare din mai multe motive: aplicația a crescut și baza veche nu mai face față; compania schimbă infrastructura (local → cloud, furnizor → furnizor); modernizarea aplicației cu tabele neoptimizate, date duplicate și lipsă de documentație.

Alte motive frecvente:

• trecerea de la MySQL la PostgreSQL;
• migrarea de la o bază locală la cloud;
• separarea unei baze monolitice în mai multe servicii;
• unificarea datelor din mai multe sisteme;
• schimbarea structurii tabelelor;
• optimizarea performanței;
• introducerea multi-tenancy;
• pregătirea pentru scalare;
• cerințe noi de securitate sau audit.

Indiferent de motiv, obiectivul rămâne același: datele mutate corect, aplicația funcțională, businessul cât mai puțin afectat.

Lecția principală: migrarea nu începe cu exportul datelor

Una dintre cele mai mari greșeli este să tratezi migrarea ca pe o operațiune „export-import”. Se exportă baza veche, se importă în cea nouă și se verifică dacă aplicația pornește. În proiectele simple poate funcționa. În aplicații business reale, rareori.

O bază de date poate conține date incomplete, relații greșite, câmpuri folosite diferit, valori introduse manual, formate vechi de dată, duplicate, înregistrări orfane sau logică de business ascunsă în aplicație. Migrarea începe cu analiza — ce date există, ce înseamnă fiecare tabel, ce relații sunt importante, ce e activ vs. istoric, ce poate fi arhivat.

O migrare bună începe cu întrebări, nu cu comenzi în terminal.

Auditul bazei de date existente

Prima etapă serioasă este auditul: tabele, coloane, indexuri, constrângeri, relații, dimensiune, volum pe tabel, frecvența scrierilor, interogări importante, dependențe aplicație.

Auditul descoperă adesea probleme invizibile pentru business:

• clienți dublați;
• comenzi fără client asociat;
• facturi fără status clar;
• date în formate diferite;
• câmpuri folosite pentru mai multe scopuri;
• tabele vechi nefolosite;
• lipsă foreign keys sau indexuri;
• rapoarte bazate pe reguli neoficiale;
• date istorice fără valoare operațională.

Dacă sunt mutate fără curățare, noul sistem moștenește haosul celui vechi. O migrare este și o oportunitate de igienizare a datelor.

Maparea datelor: cum ajunge vechiul model în noul model

Maparea stabilește cum se transformă datele din structura veche în cea nouă. Exemplu: `client_type` cu valori „PF”, „pj”, „companie” → persoană fizică / juridică standardizate. Sau adresă într-un singur câmp text → țară, județ, oraș, stradă, număr, cod poștal.

Maparea răspunde la:

• ce câmpuri se mută direct vs. se transformă;
• ce date se normalizează, elimină sau arhivează;
• ce valori implicite se folosesc;
• cum tratăm datele lipsă și duplicatele;
• cum validăm rezultatul.

O mapare slabă produce erori greu de observat: aplicația pornește, dar rapoartele sunt greșite sau filtrele incomplete.

Backupul: asigurarea de viață a migrării

Nicio migrare nu ar trebui să înceapă fără backup. Dacă ceva merge prost, backupul permite revenirea la o stare sigură. Un backup bun trebuie să fie complet, verificat și accesibil — testat dacă poate fi restaurat.

• backup complet înainte de migrare;
• backup incremental dacă sistemul este activ;
• backup separat pentru fișiere externe;
• verificarea restaurării în mediu de test;
• păstrare în locație sigură;
• documentarea momentului exact al backupului.

Nu contează doar că ai backup. Contează cât de repede și sigur poți reveni la el.

Mediul de test: locul unde migrarea trebuie să eșueze prima dată

O migrare nu se testează direct pe producție. În staging, cât mai apropiat de producție, se rulează migrarea de mai multe ori, se măsoară durata, se ajustează scripturile.

În staging se verifică: import complet, relații corecte, aplicația pornește, rapoarte corecte, autentificare utilizatori, documente legate, performanță acceptabilă, scripturi repetabile cu loguri.

Validarea datelor după migrare

O migrare nu e completă doar pentru că scriptul s-a terminat fără eroare.

Validare tehnică: număr înregistrări înainte/după, chei primare și străine, valori nule, duplicate, sume totale, integritate relații, eșantioane, loguri erori.

Validare funcțională: autentificare client, comenzi corecte, facturi asociate, rapoarte, descărcare documente, statusuri, permisiuni, istoric activitate. Validarea trebuie făcută împreună cu oamenii din business — ei cunosc sensul datelor.

Rollback: planul pe care speri să nu-l folosești

Strategia de revenire dacă migrarea eșuează. Fără rollback, orice problemă majoră devine criză. Cu rollback: oprești procesul, revii la baza veche, restaurezi backupul sau redirecționezi aplicația.

Planul trebuie stabilit înainte, nu în timpul incidentului:

• În ce situații activăm rollbackul?
• Cine ia decizia?
• Cât timp avem?
• Ce pași executăm?
• Ce se întâmplă cu datele scrise în timpul migrării?
• Cum informăm utilizatorii?
• Cum verificăm că sistemul vechi funcționează din nou?

Strategii de migrare

Migrare cu downtime

Cea mai simplă: aplicația oprită temporar, backup, migrare, validare, repornire. Simplitate — nu există date noi în timpul procesului. Dezavantaj: indisponibilitate costisitoare pentru aplicații critice.

Zero-downtime migration

Fără oprire vizibilă pentru utilizatori. Pași: pregătire structură nouă, copiere date istorice, sincronizare modificări, adaptare aplicație, comutare trafic, monitorizare, fallback pe sistem vechi. Nu înseamnă lipsă de risc — înseamnă gestionare prin arhitectură, testare și monitorizare.

Expand and contract

Expand: adaugi coloane/tabele noi, aplicația veche funcționează. Contract: după stabilizare, elimini elementele vechi. Evită schimbările bruște într-o singură noapte.

Monitorizarea după migrare

Primele ore și zile sunt critice: erori, performanță, loguri, interogări lente, resurse, feedback utilizatori, valori business. Uneori problemele apar târziu — raport lunar greșit, flux rar cu eroare, rol special afectat. Pentru aplicații critice, sistemul vechi poate rămâne în standby până la încredere completă.

Lecții practice din migrări complexe

1. Datele reale sunt întotdeauna mai murdare decât par.
2. Backupul trebuie testat, nu doar făcut.
3. Oamenii din business trebuie implicați în validare.
4. Rollbackul se planifică înainte de migrare.
5. Zero-downtime nu se improvizează — arhitectură, sincronizare, testare.
6. Migrarea e moment bun pentru curățare, dar nu un proiect infinit — clar ce se curăță acum vs. ulterior.
7. O migrare reușită e aproape invizibilă pentru utilizatori — liniștea e rezultatul planificării.