Migrarea unui magazin Magento activ la Hyvä: procesul, downtime-ul și ce se strică

Mutarea unui magazin Magento activ la Hyvä nu este o înlocuire totală. Făcută corect, este un schimb controlat al stratului de frontend, în timp ce catalogul, comenzile și clienții rămân exact unde sunt. Făcută prost, scoate magazinul din funcțiune un weekend întreg și îți dă peste cap pozițiile în Google. Iată cum arată procesul cu adevărat, ce se strică, cât durează și ce înseamnă de fapt cifrele de performanță.

Ce înseamnă de fapt migrarea la Hyvä

Hyvä înlocuiește tema, partea din Magento care randează fiecare pagină. Knockout, RequireJS, jQuery și LESS ies. Alpine.js și Tailwind intră. Backend-ul Magento, datele tale, integrările și panoul de administrare rămân pe loc.

Exact de aceea mutarea e mai sigură decât o replatformare completă. Nu schimbi unde rulează afacerea, ci doar cât de repede se desenează pagina. Istoricul comenzilor nu se mută. Conectorul de ERP nu se sinchisește. Clienții își păstrează conturile și parolele.

Un lucru schimbat recent și care merită știut înainte să faci bugetul: din noiembrie 2025 tema Hyvä în sine e gratuită și open source, sub licențele OSL-3.0 și AFL-3.0. O linie de licență care apărea în orice ofertă a dispărut. Hyvä Checkout, Hyvä UI și nivelurile Commerce și Enterprise rămân comerciale, iar Checkout merită în mod special o linie separată în buget.

Secvența care pornește de la staging

O migrare curată nu se face niciodată direct pe magazinul live. Construim storefront-ul Hyvä pe o copie de staging, lăsăm tema veche să servească clienții tot timpul și facem trecerea o singură dată. În practică, munca are șapte etape.

• Descoperire și audit. Inventariezi fiecare modul, separi backend-ul de frontend, numeri șabloanele personalizate și verifici ambele trackere Hyvä. De aici iese scopul. Sărirea acestei etape e motivul pentru care proiectele își dublează durata.
• Mediu și pipeline de build. Node pe mașinile de build, o etapă de compilare Tailwind în deployment, minificarea și gruparea proprie de JavaScript și CSS din Magento oprite și captcha-ul Magento vechi dezactivat. Mărunt, nespectaculos și blocant dacă îl lași târziu.
• Construcția temei. Cea mai lungă etapă. Șabloanele și blocurile personalizate sunt portate secțiune cu secțiune pe baza Tailwind, nu copiate.
• Compatibilitatea extensiilor. Instalezi modulele de compatibilitate care există, le portezi pe cele care nu există și decizi la ce renunți.
• Migrarea conținutului. Pagini CMS, blocuri, widget-uri și conținut Page Builder. Subestimat în mod constant, vezi mai jos.
• QA și validarea performanței. Funcție cu funcție față de magazinul live, apoi măsurători reale, nu un singur scor.
• Trecerea. Downtime-ul văzut de client se măsoară în minute, într-o fereastră cu trafic mic, nu într-un weekend.

Cât durează cu adevărat

Poziția publicată chiar de Hyvä e că proiectele durează de la șase săptămâni până la opt luni. E un interval larg și e onest, dar singur nu ajută la planificare.

Indexul lor public de studii de caz spune mai mult. Din aproximativ 130 de studii de caz, doar unsprezece indică vreo durată. Cele care o fac se grupează strâns: opt săptămâni pentru o mutare de la Luma la Hyvä fără downtime, două luni pentru un retailer cu un singur brand, două luni și jumătate până la trei luni pentru magazine europene mai mari, trei luni pentru un proiect B2B multi-brand și multilingv, patru luni pentru un lanț de parfumerii. Cea mai lungă durată indicată pe tot indexul e de douăzeci de săptămâni, iar acel proiect a avut patru store view-uri internaționale plus un rebranding complet.

Singura cifră de efort auditată publicată undeva e chiar a Hyvä: 277 de ore pe un proiect de douăsprezece săptămâni, din care 242 de dezvoltare, iar 193 dintre acelea de la un singur dezvoltator de frontend. Tratează asta ca pe forma unui proiect curat, nu ca pe o ofertă.

Ce mișcă de fapt cifra, în ordinea în care de obicei mușcă:

• Numărul de extensii de frontend. Cel mai des citat factor. Extensiile doar de backend nu costă nimic. Cele care ating magazinul au nevoie fiecare de un modul de compatibilitate găsit, instalat sau scris.
• Volumul de cod Luma personalizat. Fiecare șablon suprascris, fiecare modul RequireJS, fiecare componentă Knockout înseamnă o oră sau câteva. Asta e linia care separă un proiect de șase săptămâni de unul de șaisprezece.
• B2B. Conturile de companie, listele de rechiziție, ofertele și prețurile negociabile sunt grele pe frontend și cer în general dezvoltare reală, nu schimbat un modul.
• Store view-uri și limbi. Rar cuantificat de cineva și constant subestimat. Cel mai lung proiect publicat pe indexul Hyvä e unul cu patru store view-uri.
• Checkout-ul. Un proiect separat, cu licență separată. Estimează-l separat, altfel îți mănâncă termenul.
• O actualizare de versiune Magento. Dacă ești pe 2.3.x, faci două proiecte, și fiecare sursă publicată adaugă două până la patru săptămâni pentru asta.

O lipsă onestă: nimeni nu publică o cifră credibilă pentru efortul de migrare a conținutului Page Builder. Am căutat. Dacă o ofertă tratează un catalog mare de Page Builder ca pe o rotunjire, merită pusă întrebarea, pentru că reconstrucția conținutului e etapa care depășește termenul cel mai des.

Ce se strică și cum rezolvăm

Codul de temă personalizat. Trebuie reconstruit pe baza Tailwind a Hyvä, nu copiat. Nu există scurtătură și nu există convertor.

Extensiile care injectează markup în frontend. Au nevoie de o versiune compatibilă cu Hyvä sau de un modul de compatibilitate. Merită verificat înainte să te angajezi, iar noi detaliem în ghidul despre compatibilitatea extensiilor cu Hyvä.

Checkout-ul. Extensiile terțe de one-page checkout nu se portează. Sunt rescrieri în Knockout ale checkout-ului Magento, iar Hyvä Checkout e un checkout complet diferit. Procesatorii de plată supraviețuiesc, pentru că integrarea e server-side, dar fiecare formular de plată, iframe și redirect trebuie reintegrat.

Tot ce era codat direct în tema veche. Scripturi de tracking, widget-uri terțe, fragmente de teste A/B, bannere de consimțământ. Trebuie readăugate deliberat, altfel dispar în tăcere și nu observă nimeni până când un raport lunar arată ciudat.

Clasele CSS generate dinamic. Tailwind scanează fișierele sursă după nume de clase și nu poate evalua PHP. O clasă asamblată la rulare nu produce niciun CSS, iar eșecul e silențios: pagina se randează, doar stilul lipsește. Aceeași problemă apare la clasele Tailwind scrise în conținut CMS, motiv pentru care Hyvä livrează un compilator în browser pentru cazul acela.

Extensiile care caută Hyvä în vechiul mod. Unele module terțe detectează Hyvä urcând pe lanțul de teme după un prefix Hyva. Versiunile noi de Hyvä generează altfel resetările de layout, deci verificarea aceea eșuează în tăcere. Acele module trebuie să folosească serviciul propriu de teme al Hyvä. E un mod de eșec obscur și chiar greu de depanat.

Migrarea parțială pe care nu ți-o propune nimeni

Hyvä publică un modul de fallback de temă care lasă anumite rute să ruleze mai departe pe Luma. Asta face posibilă o migrare etapizată și e o strategie legitimă. Un studiu de caz publicat a mutat pe Hyvä doar paginile de categorie și de produs și a lăsat restul, urcând pagina de categorie de la 85 la 99 pe PageSpeed.

Compromisul e documentat chiar de Hyvä. Pe o rută de fallback, tema Hyvä nu e activă deloc. Nu se încarcă nici Tailwind, nici Alpine, se încarcă RequireJS și tot lanțul de dependențe Luma, iar stilizarea acelor pagini trebuie făcută în modul vechi. Ții pagina funcțională, pierzi câștigul de viteză pe ruta aceea și întreții două frontend-uri până termini.

Folosit deliberat pe câteva rute, cu o dată la care dispar, e inginerie bună. Folosit ca să eviți auditul extensiilor, așa ajunge un magazin Hyvä să nu fie rapid.

Cum îți protejăm pozițiile în timpul mutării

O reconstrucție e momentul în care magazinele pierd discret din SEO. URL-urile, titlurile, descrierile meta, datele structurate și linkurile interne trebuie să treacă neschimbate, iar fiecare redirect trebuie testat înainte de trecere, nu după.

Datele structurate merită atenție specială pentru că sunt invizibile până dispar. Marcajul de produs, breadcrumb-urile, marcajul de recenzii și evaluări, marcajul de politici de livrare și retur: toate stau în șabloane, iar șabloanele sunt exact ce se rescrie. Un magazin care își pierde marcajul de produs într-o migrare pierde rezultate îmbogățite în Search și poate pierde în același timp actualizările automate din Merchant Center, pentru că acelea citesc același marcaj din pagină.

Dacă faci asta corect, Google vede o versiune mai rapidă a aceluiași magazin, lucru pe care îl răsplătește. Dacă greșești, petreci trei luni recuperând poziții. Tratăm harta de URL-uri și metadate ca pe un punct din checklist-ul de lansare, nu ca pe o idee de final.

Adevărul incomod despre cifre

Hyvä e o rezolvare de frontend. Nu poate repara un backend lent, iar dovezile publicate sunt mai clare pe acest subiect decât marketingul multor agenții.

Într-un articol de pe site-ul chiar al Hyvä, un specialist în monitorizare de utilizatori reali spune că aproximativ jumătate dintre site-urile care folosesc Hyvä încă se chinuie cu Core Web Vitals. Unul dintre studiile de caz ale Hyvä descrie o migrare de opt săptămâni de la Luma la Hyvä care a urcat PageSpeed pe mobil de la 12 la 53. Nu la 100. E un proiect real, publicat de Hyvä, și e cea mai utilă cifră de pe tot indexul tocmai pentru că nu impresionează.

Salvarea Vitacom de către noi susține aceeași idee, dar din direcția opusă. Vitacom a venit la noi deja pe Magento 2 cu Hyvä și tot avea un scor PageSpeed de 12, cu răspunsul serverului urcând spre 16 secunde. Același catalog, același Magento, același Hyvä. Ce s-a schimbat a fost munca de dedesubt: aproximativ 180 de module eliminate, codul custom reconstruit, serverul redimensionat. PageSpeed a urcat de la 12 la 100, răspunsul serverului a coborât de la 15.814ms la 12ms, iar hardware-ul de la 64 de nuclee și 256GB RAM la 8 nuclee și 32GB. Citește studiul de caz Vitacom.

Deci dacă timpul de răspuns al serverului tău se măsoară în secunde, migrarea temei va face magazinul să arate mai bine și nu îl va face rapid. Află ce problemă ai înainte să cumperi rezolvarea greșită. Iar dacă grija e că Hyvä îți va aplatiza brandul, aceea e o întrebare separată, cu un răspuns mai bun decât te-ai aștepta: am scris separat despre libertatea de design pe Hyvä.

Programează un apel gratuit de strategie

Dacă te gândești la o mutare la Hyvä, îți cartografiem procesul pentru magazinul tău: ce trece mai departe, ce trebuie reconstruit, dacă blocajul tău e chiar frontend-ul și un termen realist. Programează un apel gratuit de strategie și îți explicăm pas cu pas.