Migracja z Salesforce do HubSpot rozbija się nie na technice, tylko na dziewięciu decyzjach, które trzeba podjąć przed pierwszym importem: co przenosisz, po czym rozpoznajesz rekord i kto jest jego właścicielem. Import, który przechodzi na zielono, potrafi po cichu powielić bazę albo zgubić historię, więc kolejność tych decyzji jest ważniejsza niż samo narzędzie do przenoszenia danych.
Poniżej lista, którą przechodzę przed każdym projektem migracyjnym. Kolejność nie jest przypadkowa: odpowiada temu, w jakiej kolejności te rzeczy wybuchają, jeżeli ich nie domkniesz.
Jakie decyzje podejmujesz przed migracją z Salesforce do HubSpot?
Dziewięć, i wszystkie przed pierwszym importem. Trzy dotyczą przygotowania (instancja testowa, identyfikatory rekordów, data graniczna), trzy zakresu (co przenosisz per pole, duplikaty, właściciele), trzy bezpieczników (uprawnienia, limity po stronie źródła, weryfikacja po imporcie). Żadnej z nich nie da się dorobić po fakcie taniej, niż kosztowałaby wcześniej.
- Gdzie robisz próbę przed produkcją
- Czy w eksporcie masz identyfikatory rekordów ze źródła
- Jaka jest data graniczna, po której nikt nie wraca do starego systemu
- Które pola realnie przenosisz, a które zostają w archiwum
- Co robisz z historią aktywności i treściami maili
- Jak rozstrzygasz duplikaty
- Kto jest właścicielem rekordu w dniu startu
- Jaki jest standard uprawnień
- Po czym poznasz, że migracja się udała
Od czego zacząć: instancja testowa, identyfikatory, data graniczna
Zacznij od tymczasowej instancji deweloperskiej w obrębie konta docelowego, wstępnie podłączonej do Salesforce. Nie po to, żeby przenieść dane, tylko żeby zobaczyć pełną listę pól po obu stronach. Decyzję o mapowaniu podejmuje się na widocznej liście, nie z pamięci, i to jest różnica między spotkaniem, które trwa godzinę, a serią mailowych domysłów przez dwa tygodnie.
Druga rzecz to identyfikatory rekordów ze źródła. Jedna kolumna z ID w każdym eksporcie decyduje, czy ponowny import jest aktualizacją, czy powielaniem bazy. Bez niej HubSpot nie ma po czym rozpoznać, że ten deal już u niego jest, więc zakłada nowy. Widziałem, jak z tego powstaje kilkaset duplikatów deali w jeden wieczór, sprzątanych potem tymczasowym pipeline'em na testówce.
Trzecia to data graniczna. Okres przejściowy, w którym zespół pracuje na dwóch systemach, brzmi bezpiecznie i jest najdroższą opcją z możliwych: handlowiec wchodzi tam, gdzie ma swoje dane, czyli do starego CRM, a nowy stoi pusty. Clean cut z konkretną datą załatwia temat. Salesforce zostaje jako bank danych historycznych w trybie do odczytu, ale sprzedaż od poniedziałku pracuje w jednym miejscu.
Co przenosisz z Salesforce, a co zostaje w archiwum
Zakres migracji to decyzja biznesowa per pole, nie hasło "przenosimy wszystko". Kontakty, firmy, deale i produkty idą automatem i to jest tania część. Historia aktywności, notatki i treści maili to osobna robota, którą trzeba świadomie kupić albo świadomie odpuścić, bo wyciąga się je po identyfikatorach rekordów i podpina do właściwych kart.
Praktyka, która działa: pokazujesz klientowi pełną listę pól ze źródła i prosisz o zaznaczenie tego, czego zespół faktycznie używa. Zwykle wychodzi z tego dwadzieścia kilka pól zamiast dwustu, a z leadów sprzed lat zostają tylko aktywne. Reszta zostaje w starym systemie, do którego i tak nikt nie zajrzy, natomiast gdyby zajrzał, dane tam są.
Osobno warto zaplanować, czego nie odwzorowujesz jeden do jednego. Kalka starego modelu ma sens w dniu migracji i przestaje mieć po pół roku, kiedy okazuje się, że custom object z Salesforce istniał wyłącznie dlatego, że tamten system nie umiał czegoś inaczej trzymać. Migracja to jedyny tani moment na poprawienie modelu danych, bo później zmiana struktury oznacza drugie przenoszenie.
Typowy przykład z kontraktami wieloletnimi: w źródle siedzą jako jeden rekord z aneksami, a w HubSpocie sensownie działa łańcuch osobnych deali spiętych etykietą powiązania plus property z numerem kontraktu. Zrobione inaczej, raport przychodu podliczy ten sam rok kilka razy. HubSpot ma osobną ścieżkę przenoszenia kontraktów, ale decyzję o strukturze i tak podejmujesz ty, przed importem.
Duplikaty i właściciele rekordów: dwie rzeczy, które psują pierwszy tydzień
Duplikaty rozstrzygasz przed importem, nie po. Systemy różnią się tolerancją: jeżeli źródło pozwalało na kilka rekordów z tym samym adresem e-mail, a cel nie pozwala, zduplikowane kontakty wjadą bez adresu i zostaną w bazie jako rekordy, których nikt nie znajdzie wyszukiwarką. Kontakty rozstrzygamy po mailu, firmy po NIP jako polu unikalnym.
Do tego jedna rzecz, o której łatwo zapomnieć: merge łączy rekordy łatwo, ale praktycznie się nie cofa. Właściciela sprzed połączenia nie odzyskasz z API, więc łączymy tylko pewniaki, a przypadki wątpliwe zostawiamy jako osobne rekordy z tagiem do przeglądu.
Właściciele to drugi klasyk. Rekordy nie zmapują się na ludzi, jeżeli konta użytkowników nie istnieją w HubSpocie w momencie importu. Backfill po fakcie oznacza tydzień albo dwa, w których handlowiec loguje się, filtruje po sobie i widzi pustkę. To jest moment, w którym zespół przestaje wierzyć w nowy system, i odrobienie tego kosztuje więcej niż założenie kont dzień wcześniej.
Uprawnienia, limity i bezpieczniki przed masową operacją
Standard uprawnień to decyzja po stronie klienta i realnie blokuje projekt. Bez wypełnionej karty "kto widzi czyje deale" nie ma czego konfigurować, a czekanie na nią potrafi trwać dłużej niż sama migracja. Wysyłam ją zawsze w pierwszym tygodniu, razem z listą pól, bo obie odpowiedzi muszą przyjść od biznesu, nie od wykonawcy.
Limity zwykle nie są tam, gdzie się ich spodziewasz. API HubSpota jest pojemne i przy typowej migracji SMB nie jest wąskim gardłem. Wąskim gardłem bywa źródło: Salesforce przy dużych kontach potrafi odciąć dostęp na dobę za liczbę requestów, a treści maili i tak trzeba wyciągnąć osobno. Czyli harmonogram układasz pod limity systemu, z którego wychodzisz.
Przed każdą masową operacją idzie ten sam zestaw bezpieczników:
- snapshot i backup stanu obu systemów
- record ID w każdym eksporcie
- screeny ustawień, które będziesz zmieniać
- wyłączone workflowy, które mogłyby się odpalić przy imporcie
- sign-off klienta na arkuszu mapowania
- migracja przez API zamiast plików
- cutover w weekend, kiedy nikt nie pracuje na danych
Ostatni punkt nie jest o wygodzie. W tygodniu ten sam limit dzielisz z integracjami klienta, które chodzą w tle, i debugujesz dwa problemy naraz.
Po czym poznasz, że migracja z Salesforce się udała
Po trzech rzeczach, robionych w tej kolejności: zestawienie źródło kontra cel kolumna w kolumnę, cross-check z danymi finansów i weryfikacja próbką. Nikt nie przejdzie ośmiu tysięcy wierszy linijka po linijce, ale kilkanaście przypadków wybranych ręcznie, w tym te najdziwniejsze, wyłapuje błąd mapowania lepiej niż zielony status importu.
Przy okazji: liczby po imporcie warto sprowadzić do proporcji, zanim ktokolwiek wpadnie w panikę. Lista błędów wygląda groźnie, dopóki nie policzysz, że to 277 rekordów na 8000 wierszy. Wtedy wiadomo, że źle nie jest wszędzie, tylko w jednym miejscu, i to miejsce da się wskazać palcem.
Ile trwa migracja i kto powinien ją prowadzić
Uczciwa odpowiedź brzmi: migracja bazowa jest przewidywalna, a reszta wychodzi po pierwszym imporcie. Dlatego nie podaję daty go-live przed zobaczeniem danych, tylko datę pierwszego importu na instancji testowej. Edge case'y w historii, renegocjowane kontrakty, właściciele, którzy odeszli z firmy, produkty o nazwach sprzed lat: to wszystko zabiera czas, którego nie da się rzetelnie oszacować z brzucha.
Sam producent stawia to podobnie: przy większym wdrożeniu potrzebny jest ktoś, kto zna fundamenty i kwiatki platformy, a robotę dzieli się na etapy: zrozumienie wymagań, projekt architektury, harmonogram, kod przetestowany na środowisku testowym, obserwowalność i stopniowe przenoszenie. To jest ta sama lista co wyżej, napisana od strony inżynierskiej.
Jeżeli zostajecie przy równoległym działaniu obu systemów przez dłuższy czas, to nie jest już migracja, tylko integracja, i wtedy patrzy się na natywne połączenie HubSpot z Salesforce zamiast na jednorazowy przerzut. Jedno i drugie ma sens, ale w innych sytuacjach i za inne pieniądze.
Czego ta lista nie załatwia
Nie załatwia tego, że zespół musi zacząć pracować w nowym narzędziu. Dane przeniesione co do rekordu nie sprawią, że handlowiec, który przez lata trzymał notatki u siebie, nagle zacznie je zapisywać w CRM. Na to potrzebne są sesje z zespołem i kilka tygodni nacisku ze strony zarządu, a nie kolejna kolumna w arkuszu mapowania.
Nie załatwia też decyzji, czy w ogóle przechodzić. Jeżeli jesteście na tym etapie, sensowniej zacząć od porównania HubSpot i Salesforce pod kątem dopasowania, a nie od planu przenoszenia danych. Migracja jest odpowiedzią na decyzję, nie sposobem jej podjęcia.
Jak wygląda u nas sama robota, opisaliśmy na stronie migracji CRM: mapowanie pól, deduplikacja, sandbox i zweryfikowany import.
