Când se lansează un site nou, problemele de migrare nu apar în prima zi. Apar peste câteva săptămâni: un comunicat vechi dă 404, un link dintr-un document oficial nu mai duce nicăieri, traficul din Google scade fără o explicație evidentă.
Anul acesta am migrat platforma Camerei de Comerț și Industrie a României: 17.962 de intrări de conținut, 14.016 fișiere media, 419 adrese vechi care trebuiau să funcționeze în continuare. După lansare: zero legături rupte. Nu a fost noroc. Am tratat migrarea ca pe un proiect în sine, cu etapele lui. Le descriem mai jos, în ordinea în care contează.
Inventarul se face în baza de date, nu în interfața de administrare
Prima greșeală într-o migrare este să pornești de la site-ul nou. Trebuie să pornești de la cel vechi: ce conținut există, cât este și unde se află.
Un site instituțional cu zece-cincisprezece ani de activitate are conținut în locuri în care nu se mai uită nimeni: tipuri de articole rămase de la un plugin dezinstalat, pagini în stadiu de ciornă către care încă trimit linkuri externe, fișiere încărcate direct pe server, fără nicio înregistrare în baza de date.
De aceea inventarul l-am făcut printr-o interogare directă în baza de date de producție, nu dintr-o listă exportată din interfața de administrare. Interfața arată ce a fost configurată să arate. Baza de date arată ce există.
Din inventar rezultă două lucruri: cifra totală, cu care verifici la final că nu s-a pierdut nimic, și lista categoriilor de conținut, pe care o mapezi apoi pe structura nouă.
Fiecare URL vechi primește o destinație
Aici se hotărăște dacă migrarea reușește.
Tentația este să scrii o regulă generală: tot ce era la /comunicate/… se mută la /sala-de-presa/…. Regula acoperă 90% din cazuri și le strică pe celelalte: paginile al căror slug a fost modificat manual de cineva în 2018, adresele cu diacritice, cele mutate deja o dată printr-un redirect mai vechi.
Noi am construit harta explicit: fiecare adresă veche, cu destinația ei nouă, într-un singur loc. Pentru CCIR au rezultat 419 redirecturi 301 permanente — nu 419 reguli generale, ci 419 perechi de adrese.
Un detaliu care contează pe termen lung: redirecturile le ținem în baza de date, nu în .htaccess. Un fișier .htaccess se pierde la prima mutare de server sau la prima reinstalare a unui plugin de cache. O tabelă din baza de date pleacă odată cu site-ul, se exportă, se importă și se poate verifica automat, cu un script.
Importul trebuie să se poată relua
Nicio migrare nu reușește din prima. Descoperi un câmp pe care nu l-ai mapat, o categorie cu nume duplicat, un format de dată diferit la articolele dinainte de 2012. Trebuie să poți lua totul de la capăt fără să ștergi nimic manual.
Scripturile noastre de import sunt idempotente: rulate de două ori, dau același rezultat și nu dublează conținutul. Fiecare intrare importată păstrează identificatorul din sistemul vechi; la rularea următoare, scriptul o găsește, o actualizează și trece mai departe.
Așa am putut importa, verifica, corecta maparea și reimporta de câte ori a fost nevoie.
Capcana din numele fișierelor
O capcană merită povestită, pentru că explică de ce migrările „simple” eșuează: 863 de fișiere media au ajuns pe server cu numele codate în altă formă Unicode decât se aștepta browserul. Fișierele existau, aveau numele corect la vedere, dar dădeau 404.
Explicația: un caracter cu diacritice, de exemplu „ă”, poate fi scris în Unicode în două forme standard, compusă și descompusă. Sistemul de operare preferă una, serverul o salvează pe cealaltă, browserul o cere pe prima. Pentru un om sunt identice. Pentru server sunt două fișiere diferite.
Le-am detectat automat, cu un script, comparând fiecare adresă din conținut cu fișierele reale de pe disc, în ambele forme, și le-am normalizat pe toate în forma pe care o așteaptă browserul. Fără verificarea asta, 863 de imagini din comunicate istorice ar fi lipsit la lansare, iar cauza ar fi fost greu de găsit.
Concluzia, valabilă pentru orice migrare cu nume de fișiere în altă limbă decât engleza: verificarea se face la nivel de octeți, nu după cum arată numele în listă.
Verificarea de dinainte de lansare
Înainte de lansare am parcurs automat, cu un script toate cele 3.517 adrese din sitemap. Rezultat: 3.491 răspunsuri corecte, restul redirecturi intenționate — 8 stabilite de noi și 18 evenimente care trimit, așa cum au fost gândite, către calendarul ROMEXPO. Zero legături moarte.
Raportul l-am citit rând cu rând, nu ca pe un scor. Fiecare răspuns diferit de „200 OK” a avut o explicație scrisă înainte de lansare. Ce nu putea fi explicat a fost reparat.
Aceeași parcurgere am făcut-o și pe lista celor 419 adrese vechi, ca să confirmăm nu doar că redirectul există, ci că duce unde trebuie.
Ce urmărim după lansare
Migrarea nu se încheie în ziua lansării. În primele săptămâni urmărim trei lucruri:
- Raportul de acoperire din Google Search Console. Erorile 404 pe care le vede Google sunt adrese care nu erau în inventar — de obicei vin din linkuri externe pe care nu aveai cum să le știi.
- Jurnalele serverului, filtrate pe 404. Aceeași informație, dar în timp real și inclusiv pentru ce nu indexează Google.
- O reconciliere fișier cu fișier între server și arhiva noastră. Pe o platformă instituțională au acces mai multe persoane; comparăm periodic și raportăm orice diferență.
Pe scurt
- inventar din baza de date, nu din interfața de administrare;
- hartă de redirecturi URL cu URL, nu reguli generale;
- redirecturi în baza de date, nu în
.htaccess; - import idempotent, care se poate relua fără ștergeri manuale;
- nume de fișiere verificate în ambele forme Unicode;
- toate adresele parcurse automat, cu un script înainte de lansare, nu un eșantion;
- Search Console și jurnalele serverului în primele săptămâni.
Migrarea a fost o parte din reconstrucția platformei ccir.ro. Restul — arhitectura informațională, versiunea în engleză, cititorul de publicații — este în studiul de caz.
