Dacă organizația ta încă rulează pe Drupal 7, întrebarea nu mai e dacă să migrezi. Întrebarea e cum să migrezi fără să strici tocmai părțile site-ului pe care se bazează deja publicul tău și echipa ta.
De obicei e vorba despre mai mult decât conținut. E vorba despre URL-uri care încă apar bine în căutări, fluxuri editoriale de care oamenii depind, integrări care țin afacerea în funcțiune din umbră și ani de obiceiuri acumulate pe care nimeni nu vrea să le piardă pe drum.
O migrare Drupal 7 făcută bine le protejează pe toate și, în același timp, mută platforma pe o bază mai sigură, mai ușor de întreținut și mai ușor de îmbunătățit.
Ce protejează de fapt o migrare Drupal 7 făcută bine
Înainte să ne gândim la cod, încercăm să înțelegem ce face site-ul actual suficient de bine încât să merite să supraviețuiască mutării.
URL-urile și poziția în căutări. Căile existente, conținutul indexat, linkurile care duc spre site și referințele vechi, toate au valoare. Dacă dispar din neatenție, migrarea produce pagube înainte să aducă vreo îmbunătățire.
Continuitatea editorială. Editorii n-ar trebui să simtă că au fost mutați într-o altă firmă doar pentru că s-a schimbat platforma. Noul site poate fi mai curat și mai modern, dar tot trebuie să respecte munca reală pe care oamenii o fac în fiecare zi.
Integrările critice. CRM-urile, sistemele de plată, configurările de analitică, instrumentele de e-mail, API-urile vechi, serviciile interne și orice altceva stă lipit de Drupal trebuie identificate din timp. De multe ori, o migrare eșuează mai întâi operațional și abia apoi vizual.
Ocazia de a simplifica. Nu tot ce există merită să supraviețuiască. Site-urile Drupal 7 cară adesea ani de module abandonate, structuri de conținut duplicate, date de test, câmpuri uitate și funcționalități făcute pentru o singură ocazie. O migrare e cel mai bun moment să decizi, în cunoștință de cauză, ce cureți și ce nu mai copiezi mai departe.
Cum abordăm mutarea
Tratăm o migrare ca pe un proces în etape, verificat la fiecare pas, nu ca pe un singur salt mare. În practică, are de obicei patru pași.
Primul pas, un audit. Inventariem tipurile de conținut, structurile de câmpuri, view-urile, modulele personalizate, URL-urile, integrările și zonele problematice cunoscute. Scopul e o imagine clară: ce trebuie migrat, ce poate fi regândit și ce poate fi lăsat în urmă cu bună știință.
Al doilea, arhitectura țintă. Folosim framework-ul de migrare inclus în versiunile moderne de Drupal pentru conținutul structurat și scriem logică de migrare personalizată pentru părțile cu adevărat complexe. De obicei, acolo e munca adevărată:
- Maparea câmpurilor cu valori multiple, inclusiv transformările de date de care au nevoie
- Migrarea fișierelor media (fișiere, imagini și videoclipuri încorporate)
- Păstrarea redirecționărilor URL, astfel încât poziția în căutări și linkurile primite să supraviețuiască mutării
- Migrarea conturilor de utilizator, cu rolurile lor mapate pe noul site
- Gestionarea datelor din widget-uri de câmp personalizate care n-au un echivalent direct de cealaltă parte
Al treilea, o lansare cu risc scăzut și trecerea pe noul site. Pentru majoritatea organizațiilor, editorii pot continua să lucreze în Drupal 7 cât timp se construiește noul site. Aproape de lansare rulăm un ultim pas de sincronizare, astfel încât noul site să intre live cu cea mai recentă versiune a conținutului, nu cu o copie învechită. Așa, trecerea propriu-zisă rămâne scurtă, iar noi o planificăm astfel încât vizitatorii să nu simtă nicio întrerupere.
Al patrulea, instruirea și predarea. O migrare nu e gata când codul e lansat. E gata când echipa ta editorială se simte stăpână pe noua platformă și se descurcă singură. Oferim instruire practică, construită în jurul fluxurilor tale reale de conținut, nu tutoriale generice despre Drupal.
Unde se împotmolesc de obicei migrările
Cele mai mari greșeli dintr-o migrare sunt rareori imposibilități tehnice. Sunt lucruri scăpate din vedere.
Să tratezi mutarea, înainte de orice, ca pe un redesign. Dacă stratul vizual acaparează discuția prea devreme, deciziile structurale importante se iau prea târziu.
Să sari peste planificarea URL-urilor și a redirecționărilor. Performanța în căutări și încrederea utilizatorilor se pierd adesea din neglijență, nu din schimbări inevitabile.
Să reconstruiești integrările prea târziu. O migrare poate părea gata la suprafață și totuși să fie incompletă operațional pe dedesubt.
Să cari prea mult balast mai departe. O migrare n-ar trebui să fie o copie oarbă a tot ce s-a depus pe platformă în cincisprezece ani.
Ce găsești în Drupal 11, la capătul drumului
Când munca e făcută bine, rezultatul nu e doar vechiul site pe o versiune mai nouă. E o platformă mai sigură, mai ușor de întreținut și mai ușor de îmbunătățit.
Drupal 11 îți oferă o bază susținută oficial, o experiență de administrare mai modernă, performanțe mai bune și un punct de plecare mai curat pentru munca viitoare.
Îți oferă și șansa de a-ți moderniza frontendul cum trebuie. În cazul nostru, asta înseamnă de obicei o abordare Drupal modernă, cuplată, prin SDX: framework-uri de frontend moderne, randate chiar în Drupal, fără să separi CMS-ul de platformă și fără să-ți asumi costurile unei arhitecturi headless complete.
Cum judeci termenele și riscul
Amploarea unei migrări depinde mai puțin de numărul de pagini în sine și mai mult de structura conținutului, de complexitatea integrărilor și de câtă curățenie e nevoie pe platformă pe parcurs.
Unele site-uri se pot muta în câteva săptămâni. Altele au nevoie de un drum mai lung și mai atent. Important e să nu ne prefacem că e vorba de același proiect.
Dacă încă ești pe Drupal 7, cel mai bun pas următor e de obicei o evaluare clară a migrării. Ea îți arată ce trebuie păstrat, ce poate fi îmbunătățit, care sunt riscurile probabile și cum arată un drum realist mai departe, toate astea înainte să înceapă munca.
De obicei, claritatea asta e cea care transformă migrarea dintr-o problemă care îți atârnă deasupra capului într-un proiect despre care echipa chiar poate lua decizii.