Migrację CRM do HubSpota da się poprowadzić na trzy sposoby: siłami wewnętrznymi, przez freelancera albo przez partnera, i każdy z nich wygrywa w innej sytuacji, głównie w zależności od tego, ile decyzji projektowych trzeba podjąć po drodze. Kluczowe pytanie nie brzmi "kto jest najlepszy", tylko "kto weźmie na siebie decyzje o duplikatach, właścicielach rekordów i modelu danych", bo to one, a nie samo przenoszenie, decydują o wyniku.
Nie znajdziecie tu rankingu firm. Rankingu wykonawców migracji nie da się zrobić uczciwie, bo wynik zależy od waszych danych, nie od cudzej strony internetowej. Da się natomiast opisać, po czym poznać wykonawcę, który robił to wcześniej.
Kto powinien prowadzić migrację CRM do HubSpota?
Ten, kto potrafi podjąć decyzje projektowe, a nie ten, kto najtaniej przerzuci rekordy. Przy prostej bazie bez historii i bez integracji wystarczą siły wewnętrzne. Przy jednym systemie źródłowym i czystych danych freelancer robi to sprawnie. Przy wieloletniej historii, kontraktach, integracjach i zespole, który musi w poniedziałek pracować, potrzebny jest ktoś, kto widział, co idzie nie tak, i ma za sobą więcej niż jedną migrację.
Sam producent stawia to podobnie: przy większym wdrożeniu robotą powinien zająć się ktoś, kto zna fundamenty i kwiatki platformy, bo to pozwala ustalić, czego naprawdę potrzebujecie, a czasem ważniejsze, czego nie.
Co realnie robi się przy migracji, czyli o co ten spór
Przenoszenie rekordów jest najtańszą częścią projektu. Kosztowne są decyzje, których nie da się zdelegować narzędziu, i to one rozstrzygają, czy dany model wykonawcy się sprawdzi.
- po czym rozpoznajemy duplikat i co robimy z niepewnymi przypadkami
- kto jest właścicielem rekordu w dniu startu
- które pola przenosimy, a które zostają w starym systemie
- co robimy z historią aktywności i treściami maili
- jak modelujemy rzeczy, które w starym systemie były obejściem
Ostatni punkt jest tym, na którym najczęściej wykłada się tania migracja. Kontrakty wieloletnie ze zmianami w trakcie nie mapują się jeden do jednego: w HubSpocie sensownie działa łańcuch osobnych deali spiętych etykietą powiązania plus property z numerem kontraktu, bo inaczej raport przychodu podliczy ten sam rok kilka razy. HubSpot ma na to osobną ścieżkę przenoszenia kontraktów, ale decyzję o strukturze i tak podejmuje człowiek, przed importem.
Podobnie z historycznymi lejkami. Firma, która latami eksperymentowała z procesem, ma ich kilkanaście, a sensowna migracja konsoliduje je do kilku głównych, zachowując znaczniki czasu potrzebne do raportowania źródeł leadów. Kalka jeden do jednego to decyzja, która wygląda bezpiecznie w dniu migracji i mści się po pół roku.
Zespół wewnętrzny: kiedy wygrywa
Wygrywa przy małej, czystej bazie z jednego systemu, bez integracji i bez wieloletniej historii, kiedy w firmie jest ktoś, kto zna zarówno dane, jak i proces sprzedaży. Przewaga jest realna: nikt nie zna waszych kwiatków w danych lepiej niż osoba, która je przez lata oglądała.
Granica też jest realna. Wewnętrzny administrator zna dokładnie jedno wdrożenie: własne. Kiedy trafi na przypadek, którego nie widział, sprawdza go w wyszukiwarce, a przy migracji ceną za sprawdzanie jest weekend cutoveru. Do tego migracja to projekt jednorazowy, czyli firma płaci za naukę, z której skorzysta raz.
Freelancer: kiedy wygrywa i gdzie ma granicę
Wygrywa przy jasno zamkniętym zakresie: jeden system źródłowy, uzgodnione mapowanie, brak integracji do przepięcia. Robi to sprawnie i taniej niż zespół, bo nie ma narzutu.
Granica pojawia się po cutoverze. Freelancer kończy projekt i znika, a najwięcej błędów wychodzi w pierwszym tygodniu pracy zespołu na nowych danych. To nie jest zarzut wobec modelu, tylko rzecz, którą trzeba policzyć zawczasu: kto u was odbierze te zgłoszenia.
Druga granica to odpowiedzialność za rzeczy zbudowane po drodze. Migracja zwykle ciągnie za sobą integrację albo dwie, a integracja pisana od zera mimo istniejącego natywnego konektora kończy się sypiącymi się klockami. Widziałem projekt, w którym zewnętrzny wykonawca zbudował integrację od podstaw, choć oficjalna istniała, i skończyło się incydentem z utratą danych, którego nie powinno być.
Partner albo agencja: kiedy to się kalkuluje
Kalkuluje się wtedy, kiedy decyzji projektowych jest dużo, dane mają historię, a zespół ma pracować od konkretnej daty. Wtedy płacicie nie za przerzucenie rekordów, tylko za to, że ktoś już wie, gdzie to pęka: gdzie duplikaty wjadą bez adresu, gdzie ownership trzeba backfillować i który system źródłowy odetnie dostęp na dobę za liczbę requestów.
Drugi argument to ciągłość. Partner, który zostaje po starcie na stałej obsłudze, obsługuje pierwszy tydzień, kalibruje scoring po kilku miesiącach realnych danych i pilnuje porządku w portalu. Migracja bez tego jest projektem zamkniętym w dniu, w którym problemy dopiero się zaczynają.
Uczciwie o drugiej stronie: to jest najdroższy z trzech modeli i przy prostej bazie po prostu się nie opłaca. Jeżeli macie kilkaset kontaktów z jednego narzędzia i nikt nie potrzebuje historii, nie kupujcie projektu, tylko przenieście dane sami.
Porównanie trzech modeli
Tabela nie rozstrzyga, kogo wybrać, tylko pokazuje, gdzie każdy model ma naturalną granicę.
| Kryterium | Zespół wewnętrzny | Freelancer | Partner |
|---|---|---|---|
| Znajomość waszych danych | najlepsza | zerowa na starcie | zerowa na starcie |
| Doświadczenie z wielu migracji | brak | zależy od osoby | zwykle tak |
| Kto podejmuje decyzje projektowe | wy | zwykle wy | wspólnie, z rekomendacją |
| Wsparcie w pierwszym tygodniu po starcie | wewnętrzne | zwykle brak | w zakresie umowy |
| Odpowiedzialność za integracje | wasza | do końca projektu | ciągła |
| Sens przy prostej bazie | wysoki | wysoki | niski |
| Sens przy historii i integracjach | niski | średni | wysoki |
Czerwone flagi niezależnie od modelu
Trzy zdania, po których wiadomo, że rozmawiacie z kimś, kto migracji nie robił. Pierwsze: "wyeksportujemy do pliku i zaimportujemy". Import plikami bez identyfikatorów rekordów ze źródła zakłada nowe rekordy zamiast aktualizować istniejące, czyli powiela bazę zamiast ją przenieść.
Drugie: "przeniesiemy wszystko jeden do jednego". Zakres migracji to decyzja biznesowa per pole, a nie hasło. Trzecie: "zrobimy okres przejściowy na dwóch systemach". Zespół zawsze wraca tam, gdzie ma swoje dane, więc równoległe utrzymywanie dwóch narzędzi kończy się tym, że nowe stoi puste.
Do tego jedna rzecz, o którą warto zapytać wprost: co się stanie z datami zmian statusów. Po odpowiedzi na to jedno pytanie poznacie, czy ktoś to robił, czy będzie się uczył na waszych danych.
Jak sprawdzić wykonawcę migracji na jednej rozmowie
Poproście o opis procesu, a nie o listę narzędzi. Wykonawca z doświadczeniem sam wspomni o próbnym imporcie na osobnym środowisku, o sign-offie na arkuszu mapowania i o tym, że część decyzji musi podjąć klient. HubSpot rozbija tę samą robotę na etapy: zrozumienie wymagań, projekt architektury, harmonogram, kod przetestowany na środowisku testowym, obserwowalność i stopniowe przenoszenie danych.
Drugie pytanie: czego nie zrobicie. Uczciwa odpowiedź istnieje zawsze. My na przykład nie bierzemy projektów, w których dane siedzą w dwóch systemach sklejonych własnym konektorem, a klient chce raportów w CRM. To nie jest projekt "zrób raporty", tylko projekt "zintegruj dwa systemy", i lepiej powiedzieć to przed umową niż po.
Jak wygląda u nas sama robota, opisaliśmy na stronie migracji CRM: mapowanie pól, deduplikacja, sandbox i zweryfikowany import.
