Portalurile HubSpot conțin datele de bază (contacte, companii, dealuri, tichete de suport), dar și multe alte facilități care centralizează activitatea companiei. Problema apare când vrei să schimbi portalul HubSpot, să-l duplici pentru o nouă companie, sau pentru unirea activităților a două companii.
Cum migrezi facilitățile de la un portal HubSpot la altul? Pentru copierea datelor efective, există unelte de migrare (vezi mai jos). Dar nu există un buton unic care să mute un portal complet.
Din experiența OPTI, cele mai mari probleme nu apar la importul datelor, ci la dependențe: formulare embeduite în site-uri externe, workflows care folosesc emailuri/liste/useri vechi, aplicații private care trebuie reconectate, tracking code rămas în portalul vechi și rapoarte care nu pot fi recreate identic.
Acest ghid complet bazat pe experiența OPTI te trece prin cele trei componente ale unei migrări CRM. Cum migrez datele? Cum migrez funcționalitățile? Cum migrez operațiunile echipei?
1. Inventarul dinaintea migrării: CRM, formulare, workflows, domenii
Trebuie să faci inventarul, chiar dinainte de a rula orice instrument de copiere, ca să știi ce există în portalul vechi și ce contează pentru business. Clasifici în perioada de inventar ce se poate migra automat, ce trebuie recreat manual și ce poate fi arhivat (abandonat în vechiul portal).
1.1 Ordinea priorităților și planul de migrare HubSpot
- Contractul comercial cu HubSpot (utilizatori, seat-uri, permisiuni) care determină ce funcționalități vei folosi în noul portal
- Entitățile configurabile manual, unde instrumentul de copiere date va fi doar parțial de ajutor. Ex: domenii, rețele sociale, workflows (vezi mai jos)
- Datele efective unde instrumentul de copiere este esențial pentru rapidizarea transferului
- Funcționarea ideală post-migrare pentru fiecare funcționalitate
Un inventar bun este suficient de concret pentru a fi folosit ca plan de migrare:
| CRM | Contacte, companii, deal-uri, tichete, activități | |
| Proprietăți | Câmpuri custom, dropdown-uri, valori obligatorii | |
| Liste / segmente / campanii | Liste active, smart lists, liste pentru campanii, resurse campanii | |
| Formulare | Versiuni, câmpuri, pagină unde apare, submissions, portal ID | |
| Emailuri | Marketing emails, automated emails, template-uri | |
| Workflows | Triggere, acțiuni, emailuri, liste, useri, aplicații | |
| Landing pages | URL vechi, URL nou, formular, status | |
| Rapoarte | Dashboards, filtre, proprietăți, acces | |
| Aplicații și conexiuni | Social, ads, WordPress, private apps, marketplace apps | |
| Domenii | Content domain (CMS), email domains, tracking code | |
| Utilizatori | User vechi, user nou, permisiuni, seats, views, panels |
1.2. Există vreun blocker?
Identificați toate punctele care au șansă să blocheze migrarea și stabiliți cum le evitați. Recomandăm să implicați în discuții toate persoanele-cheie, tehnice și non-tehnice:
- Ce portal este sursă și ce portal este destinație și cu ce abonamente HubSpot?
- Ce diferențe sunt între procesele companiei pre-migrare și post-migrare?
- Ce funcționalități se migrează automat, ce se reconstruiește manual și ce se arhivează?
- Cine are acces la resursele externe (domenii, aplicații private, social media, ads, conturi email etc)?
- Când există un interval de timp suficient pentru migrare?
2. Metode de migrare portal
O migrare complexă combină mereu trei metode: export/import, unealtă de migrare (migrator) și reconstrucție manuală. Ca partener HubSpot, planificăm fiecare dintre ele în funcție de scop. De exemplu unirea a două companii impune alte proceduri ca migrarea unei singure companii modificate.
2.1 Export/import și asset copy HubSpot
Exportul de conținut disponibil în HubSpot pentru multe obiecte este obligatoriu ca backup și util pentru audit viitor.
Dacă este activă opțiunea de multi-account management, HubSpot permite copierea multor asset-uri între conturi, fără a face migrare completă. De exemplu, când copiezi un formular, se copiază structura formularului, nu și datele colectate prin el.
2.2 Migrator: Instrument specializat de migrare
Un tool specializat reduce mult efortul de import a milioane de rânduri. Poate migra toate obiectele disponibile prin HubSpot API (vezi documentația HubSpot).
Două soluții pe care le puteți evalua sunt:
Datawarehouse.io - HubSpot to HubSpot Migrator
Unealtă populară pentru migrare în bloc. Cităm limitările „Restricțiile API împiedică migrarea datelor de campanie, a datelor istorice despre traficul web, a CTA, landing pages, rapoartelor și dashboardurilor.". Toate acestea trebuie mutate manual sau, în cazul datelor istorice despre traficul web vor fi doar arhivate (nu se pot crea nici manual).
La data ghidului, prețul este pe trei pachete, de la $600 la $1000 per migrare, cu garanția returului în caz de eșec. Doar planul maximal Enterprise permite de exemplu migrarea custom objects din HubSpot. Verifică prețul actual pe site-ul oficial
SyncMatters - HubSpot to HubSpot Migration Services
Oferă o abordare consultativă, cu posibilitatea vizualizării corespondenței între obiecte vechi și obiecte noi, cu planificare opțională alături de un consultant. Cu siguranță, pentru varianta fără consultant se aplică aceleași limitări de API ca mai sus.
La data ghidului, prețul este pe trei pachete, din care cel fără consultant variază în funcție de numărul de obiecte transferate între $299 și $2999. Pachetele cu asistență pornesc de la un cost extra de $750 peste costul variabil de bază. Verifică prețul actual pe site-ul oficial
2.3. Ce se mută manual?
Puteți planifica reconstrucția manuală pentru obiectele care nu au API de citire și creare:
| Ce se mută manual | Recomandare | |
|---|---|---|
| Setările HubSpot, permisiuni, setări utilizatori | Setările se refac manual prin comparație, utilizatorii trebuie să-și redefinească view-urile și să-și conecteze aplicațiile (ex: calendar) | |
| Formulare: câmpuri, pagină unde apare, portal ID | Nu pot fi migrate automat complet. Trebuie înlocuite embed-urile în toate site-urile externe | |
| Workflows: trigger, acțiuni, emailuri, liste, useri, aplicații | Nu se migrează complet, pot avea dependențe care trebuie reamplasate | |
| Landing pages: URL vechi, URL nou, formular, status | Trebuie refăcute vizual sau refăcute în exterior (Ex: WordPress, e-commerce) | |
| Rapoarte și dashboards | Trebuie recreate sau validate manual. Cele bazate pe istoric de trafic vor fi arhivate. | |
| Aplicații, rețele sociale și conexiuni | Toate aplicațiile externe și dezvoltatorii lor trebuie să le reconecteze. Toate rețelele sociale și resursele externe care aduc date în HubSpot trebuie reconectate. | |
| Domenii: content domain, email domain, tracking | Trebuie modificat DNS și reconectate domeniile. Trebuie amplasat noul cod tracking în toate site-urile externe |
Metoda corectă în practică este hibridă:
3. Migrarea CRM
Datele CRM trebuie mutate într-o ordine logică, de la schemă, la date în masă, apoi la procedurile de rafinare a transferului: verificarea totalurilor, ownerilor, asocierilor și corectarea duplicatelor din datele transferate bulk.
Dacă ordinea nu este respectată (în special dacă faci schema după date sau nu rafinezi după transferul datelor), portalul nou va genera erori și vor exista probabil date lipsă, greu de adus ulterior când se lucrează în el deja.
3.1. Proprietăți custom și calculate
Proprietățile custom sunt esențiale: formularele le folosesc, listele filtrează pe baza lor, workflows le modifică, rapoartele le agregă între obiecte. Toate aceste fluxuri depind de proprietățile custom care trebuie să fie identice la migrare.
Verifică în special proprietățile:
- de tip dropdown/select sau multi-checkbox
- calculate, read-only sau definite de HubSpot
- folosite în formulare, workflows, rapoarte
- folosite ca identificatori unici sau de aplicații programate externe
Se întâmplă ca unele proprietăți calculate să nu poată fi transferate direct. Uneori ele se vor recalcula în portalul nou, alteori trebuie refăcut fluxul de business complet.
3.2. Contacte, companii, dealuri, tichete
La contacte, emailul este de obicei cheia principală. Contactele fără email trebuie tratate separat, pentru că pot produce duplicate. La companii, domeniul companiei este esențial pentru deduplicare și asociere corectă. Pentru activitățile de vânzare și suport, dealurile și tichetele HubSpot sunt de obicei esențiale.
Checklist pentru date CRM:
| Ce verific | Cum verific |
|---|---|
| Nr total contacte / companii / dealuri / tichete | compari numărul din portal vechi și nou |
| Owneri | verifici owner mapping pentru useri vechi/noi |
| Asocieri | verifici câte un caz contact-company, deal-company, ticket-contact etc |
| Duplicate | verifici email, domain, Record ID sau proprietăți unice |
| Contacte fără email, companii fără domeniu | decizi dacă se păstrează, se curăță sau se marchează |
| Marketing contacts | verifici impactul de cost al preluării lor |
3.3. Activități și istoric
CRM-ul conține și activitățile contactelor, companiilor și dealurilor: emailuri, calls, notițe, sarcini sau alte engagement-uri. Pentru echipele de sales și service, istoricul este la fel de important ca datele din proprietăți.
După migrare, verifică prin sondaj recorduri reale, ca mai sus: un contact cu istoric bogat, o companie cu mai multe persoane asociate, un ticket de suport cu conversații, un contact creat prin formular.
4. Zona de risc: Formulare, landing pages și site-uri externe
Formularele sunt un punct în care migrarea devine publică. Dacă un formular vechi rămâne embeduit într-un site extern, datele vor intra în portalul vechi. Sau formularul poate înceta să funcționeze dacă vechiul cont se dezactivează!
De aceea, formularele și landing pages trebuie tratate ca fluxuri de business, pas cu pas.
4.1. Migrarea formularelor HubSpot
Pentru fiecare formular activ, creează un tabel de migrare. Din experiența OPTI:
| Formular vechi | Formular nou | Punct de inserție real |
|---|---|---|
| Formular Webinar | Formular nou #ID1 | landing page, articol, email |
| Formular Newsletter | Formular nou #ID2 | footer, pop-up, pagină abonare |
| Formular Contact | Formular nou #ID3 | pagina Contact, ads |
| Formular Eveniment | Formular nou #ID4 | pagină campanie |
La fiecare formular testează:
- Câmpurile obligatorii și proprietățile custom
- Dropdown-urile și zonele dinamice
- Submit, consimțământ și GDPR
- Mesajul de confirmare, emailul sau redirect-ul
- Notificările, înscrierea în liste, apariția contactului cu sursa corectă
- Workflows declanșate
4.2. Landing pages și website pages
Landing pages trebuie să fie refăcute în HubSpot sau mutate într-o resursă externă ca WordPress sau site-ul e-commerce. Alegerea depinde de trafic, limitări de abonament și de ușurința de editare viitoare.
O metodă practică este împărțirea paginilor în trei categorii:
| Categorie | Tratament recomandat |
|---|---|
| Pagini active cu trafic/conversii | migrare/refacere completă și test vizual |
| Pagini recente, dar cu trafic mic | refacere ca draft și publicare după validare |
| Pagini vechi fără valoare | arhivare sau redirect spre pagini relevante |
Pentru paginile mutate în exterior, păstrează un tabel separat cu:
- URL vechi și URL nou, împreună cu realizarea redirectului 301 (de exemplu din HubSpot redirects)
- Formular vechi și formular nou (dacă e cazul)
- Elemente de design HubSpot vs medii ca Elementor în WordPress
- Rezultate teste vizuale (screenshots), reale și rezultate pe parcursul migrării
4.3. Embeduri și alte dependențe în/cu site-uri externe
Cum spuneam mai sus, cele mai mari riscuri nu sunt în HubSpot, ci în afara HubSpot: în e-commerce, microsite-uri, subdomenii, pagini vechi, pagini de eveniment, cataloage, aplicații interne. Trebuie căutate explicit:
- snippet-uri HubSpot în site-urile externe
- scripturi în pagini vechi HubSpot (direcția inversă)
- cod HubSpot în Google Tag Manager
- butoane din emailuri sau pagini (CTA) care duc spre portalul vechi
5. De verificat individual: Workflows, emailuri, rapoarte și aplicații conectate
După transferul etapizat al datelor și evitarea riscurilor legate de resursele externe, urmează cea mai sensibilă parte internă din HubSpot: automatizările.
Un workflow greșit poate trimite emailuri nepotrivite, poate modifica alte proprietăți decât trebuie sau poate apela o aplicație care nu mai este conectată. Procesele de business nu vor mai funcționa.
Deci, pentru automatizări și workflows, regula este simplă. Ele se migrează inactive, se verifică 100% și se pornesc una câte una.
5.1. Workflows
Pentru fiecare workflow activ, verifică cel puțin:
| Element | Verificare |
|---|---|
| Trigger | condiția de pornire este identică? |
| Formular | formularul nou este folosit în trigger? |
| Liste | listele există și au aceeași definiție? |
| Emailuri | emailurile sunt publicate sau sunt draft? |
| Notificări | userii există în portalul nou? |
| Proprietăți | toate câmpurile există și au aceleași valori? |
| Aplicații | acțiunile externe au aplicații reconectate? |
| Re-enrollment | criteriile au fost refăcute/verificate? |
| Testare | workflow a fost testat pe un contact de probă? |
Dacă verificați individual, nu veți ajunge ca workflow să dea fail din cauză că o secvență, segment sau aplicație nu există încă în noul portal.
5.2. Marketing emails
Emailurile migrate trebuie verificate ca piese de comunicare, nu doar ca asset-uri tehnice, pentru că ele puteau fi uitate în portalul vechi și în portalul nou să devină active din greșeală.
În special, verifică workflows care le folosesc. Dacă un email nu mai este necesar, arhivează-l.
5.3. Rapoarte și dashboards
În cazul rapoartelor, trebuie să vă asigurați că pot rămâne funcționale la migrare. De exemplu, dacă un raport crucial include date de trafic (care nu se importă via Excel, nici via API, nici nu pot fi recreate manual), rapoartele vechi vor trebui arhivate și munca în noul portal va începe de la 0.
Pentru fiecare raport:
- identifică beneficiarii rapoartelor și stabilește ce rapoarte sunt obligatorii
- verifică proprietățile, filtrele și grupările
- compară rezultatele vechi/nou pentru aceeași perioadă
- marchează rapoartele care nu pot fi recreate identic și trebuie arhivate
5.4. Aplicații conectate și private apps
Aplicațiile conectate, dacă sunt standard, pot fi recreate de administratorul de cont HubSpot. Dacă sunt custom, sunt deseori dependente de echipa tehnică care a dezvoltat resursa externă conectată. Creează un tabel de migrare, ca exemplu:
| Aplicație | Tip | Cine o reconectează |
|---|---|---|
| HubSpot for WordPress | plugin/site extern | admin WordPress |
| Facebook/Instagram | social | Dep. marketing |
| social | Dep. marketing | |
| Google Ads | ads | Dep. marketing |
| Typeform/Zoom/etc. | marketplace | Owner produs |
| Private app | API | Developer extern |
Aplicațiile private sunt cele mai sensibile: tokenurile trebuie regenerate, scopes verificate, iar logurile urmărite după go-live.
Și toate aceste integrări pot avea efecte în automatizări (ex: workflows):
6. Go-live și primele 72 de ore: de la DNS la point of no return
Marea lansare (go-live) trebuie tratată ca un runbook în care fiecare pas depinde de celălalt. De obicei stabilești un freeze operațional (când utilizatorii devin view-only ca date minime să intre), apoi execuți pașii efectivi de migrare, apoi faci testare rapidă (smoke tests) și testare extinsă cu corecturi continue.
6.1. Domenii și email
Pentru email marketing, trebuie configurate corect setările DNS recomandate de HubSpot (DKIM, SPF și DMARC). Dacă domeniul de trimitere nu este autentificat, vor apărea probleme de livrabilitate sau emailurile vor arăta suspect pentru destinatari.
Verifică:
| Zonă | Ce trebuie făcut |
|---|---|
| Content domain (CMS) | Conectare domeniu/subdomeniu în portalul nou |
| Email sending domains | Setări DNS |
| Tracking domain | Setări de tracking și link tracking |
| SSL | Certificate active pe domeniile folosite |
| Redirecturi | URL-urile vechi trimit spre paginile noi |
| From/Replyto | Adresele folosite în marketing emails sunt corecte |
6.2. Tracking code și Analytics
În site-urile externe (ex: Wordpress, e-commerce), tracking code-ul HubSpot din portalul nou trebuie instalat, pentru ca vizitele și acțiunile să se înregistreze corect.
Verifică în special orice resursă corelată companiei, ca WordPress, Google Tag Manager, cookie banner/consent, GA4/GTM, Meta Pixel, Google Ads.
6.3. Operațiuni la go-live și smoke tests
Am creat o diagramă cu zece pași pentru go-live controlat. Se remarcă faptul că multe acțiuni în portalul nou trebuie făcute manual după migrarea datelor (migrare și migrare delta pentru diferențe). În funcție de specificul migrării, pot exista pași suplimentari:
Punctul de no-return (fără întoarcere) este de obicei când ați executat smoke tests (testare preliminară globală) și activați automatizările. Din acel moment vor fi mai multe date noi în noul portal decât în vechiul portal, ceea ce crește continuu costul reîntoarcerii la vechiul portal.
Dacă ați aplicat cu atenție planul inițial (de la inventar), smoke tests vă pot confirma că totul merge bine. Iată din experiență câteva scenarii reale, ce trebuie rulate de la cap la coadă, chiar dacă prin sondaj:
| Smoke test | Ce verifici |
|---|---|
| Completare formular public | contact creat, proprietăți, sursă, notificări, email |
| Abonare newsletter | listă, consent, email automat |
| Formular eveniment | workflow, email, status, raport |
| Contact sales | owner, lifecycle stage, task |
| Email automat | from, reply-to, unsubscribe, links |
| Aplicație externă | sync, logs, webhook |
| Raport dashboard | comparație cu portalul vechi |
6.4. Verificări după migrare
Chiar dacă portalul nou este live, în primele 24-72 de ore apar cele mai multe probleme reale. Poate ați uitat un formular, poate cineva nu primește notificări, poate există duplicate pe care nu le-ați detectat. Trebuie să oferiți suport de nivel crescut în perioada imediat după lansare, când toți membrii echipei trebuie să testeze și să vă sesizeze.
Nu te speria dacă lucrurile par să se grăbească, odată ce toate datele intră în portalul nou. Câteva reguli de aur pe care le poți ține minte:
- Poți urma inventarul inițial pentru a afla ce lipsește după migrare
- Freeze-ul operațional te ajută să diagnostichezi ce nu ai migrat (dacă observi că intră date noi în portalul vechi)
- Verifică prioritar contactele fără email, companiile fără domeniu și alte obiecte fără date
- Verifică duplicatele de toate tipurile și compară orice listă cu cele din portalul vechi
- Un membru non-tehnic al echipei poate să găsească probleme tehnice adânci, dacă lucrează pe un flux de business pe care îl cunoaște bine.
Iată astfel un plan pe primele 72 de ore, care poate varia de la proiect la proiect. El se încheie cu handover-ul, când echipa normală se poate ocupa singură de proiect.
Obiectivul real: continuitatea operațională
O migrare completă răspunde „Da" la întrebarea: poate echipa să lucreze bine în noul portal? Dacă datele sunt mutate, formularele publice trimit în portalul nou, workflows sunt funcționale și nimeni nu se plânge nici peste trei luni, proiectul este un succes remarcabil.
Ce am prezentat mai sus este ideea simplă că orice migrare este un mini-proiect de arhitectură operațională. Începi cu inventarul și monitorizezi tot procesul de zeci de pași, inclusiv după go-live.
Acest nivel crescut de atenție este cheia succesului și este asigurat de echipa OPTI în migrările noastre.
