Migracja z Dynamics 365 do Salesforce: playbook architekta

Większość migracji z Dynamics 365 do Salesforce sprzedaje się jako proste przekopiowanie danych. Przenieś Accounty, przenieś Kontakty, przemapuj picklisty — i gotowe. I właśnie na tym założeniu projekty się wykładają: obie platformy zupełnie inaczej rozumieją, jak powinien wyglądać CRM, a przekopiowanie tabel tylko odtwarza model, z którego już wyrosłeś.

Ten playbook podchodzi do przejścia jak do przebudowy Twojego modelu na nowej platformie: stare dane są surowcem wejściowym, nie specyfikacją. Wskazujemy, które encje mapują się bez problemu, które trzy będą się bronić i które decyzje trudno cofnąć, gdy rekordy trafią już na miejsce.

Dlaczego zespoły zmieniają platformę — szczerze

Dynamics 365 Sales to solidny CRM. Zespoły rzadko z niego odchodzą, bo przestał działać. Odchodzą, bo reszta firmy pracuje już gdzie indziej: marketing jeździ na Salesforce Marketing Cloud, obsługa klienta chce Service Cloud, a roadmapa Agentforce wymaga, żeby wszystko trzymać na jednej platformie i w jednym modelu danych.

Czasem powodem są licencje i polityka konsolidacji wokół Microsoftu, a nie cechy produktu. To w pełni uzasadniony powód — nie musisz wymyślać technicznych usterek, żeby przejście obronić. Warto jednak być szczerym co do „dlaczego”, bo to wyznacza zakres. Przejście dla standaryzacji platformy to okazja, żeby naprawić model. Przejście czysto kosztowe kusi, żeby zrobić lift and shift — a wtedy za cenę całego projektu przenosisz na nową platformę każdy stary problem.

Tak czy inaczej migracja to jednorazowa okazja, żeby przestawić własność, aktywności i dane referencyjne na nowe tory. Zmarnujesz ją — i za osiemnaście miesięcy prowadzisz projekt porządkowy.

Jak przeprowadzić migrację z Dynamics 365 do Salesforce?

Pracuj w pięciu fazach: zmapuj encje Dynamics na obiekty Salesforce, zdecyduj, jakich danych nie przenosisz, zbuduj i przetestuj docelowy org, puść oba systemy równolegle i uzgodnij rekordy, a na końcu przełącz integracje i użytkowników. To ma być przebudowa Twojego modelu, nie lift and shift tabel.

Każda faza kończy się bramką. Zanim ruszysz z budową, mapa obiektów musi być uzgodniona, a lista „tego nie przenosimy” podpisana — obie decyzje zmieniają docelowy schemat. Zanim przełączysz użytkowników, parallel run musi pokazać, że liczby rekordów, własność i otwarty pipeline zgadzają się w obu systemach. Pominięcie bramek to najczęstszy powód, dla którego migracja z tygodni rozciąga się na kwartały.

Co mapuje się czysto, a co stawia opór

Standardowe encje sprzedażowe mają bliskie odpowiedniki w Salesforce. Problemy siedzą w trzech miejscach: aktywnościach, modelu własności i option setach. Dynamics trzyma aktywności jako jedną polimorficzną encję powiązaną polem „regarding”. Salesforce rozbija je na Task i Event z WhatId i WhoId — każdy typ aktywności z Dynamics trzeba więc przy ładowaniu skierować do właściwego obiektu.

Druga pułapka to własność. Dynamics traktuje owner teams i access teams jako pełnoprawnych właścicieli. W Salesforce właścicielem rekordu może być tylko pojedynczy User albo Queue — wszystko inne załatwia się przez sharing model. Własności zespołowej nie da się po prostu przekopiować: trzeba ją przeprojektować na role, sharing rules i kolejki.

Trzecia to option sety. Dynamics trzyma wartości picklist jako liczby całkowite ukryte pod etykietą. W Salesforce kluczem picklisty jest API name. Mapuj po wartości liczbowej i etykiecie, nie po wyświetlanym tekście — inaczej rekordy historyczne wylądują na złych wartościach.

Encja Dynamics 365	Obiekt Salesforce	Uwaga migracyjna
Account	Account	Czysto. Uważaj na różnice w polach hierarchii kont.
Contact	Contact	Dynamics dopuszcza kontakty bez rodzica; zdecyduj domyślny Account.
Lead	Lead	Czysto. Przemapuj option sety statusu i oceny leada.
Opportunity	Opportunity	Model etapów się różni; Business Process Flows nie mają bezpośredniego odpowiednika.
Quote / Quote Product	Quote / Quote Line Item	Wymaga najpierw konfiguracji Price Book i Product.
Product / Price List	Product2 / Pricebook2 + PricebookEntry	Model pozycji cennika nie układa się jeden do jednego.
Order / Invoice	Order / (brak standardowej Invoice)	Fakturowanie wymaga Revenue Cloud albo dedykowanego obiektu.
Activity (Task, Phone Call, Appointment, Email)	Task / Event / EmailMessage	Polimorficzne „regarding” rozpada się na WhatId / WhoId. Gryzie.
Owner team / Access team	OwnerId (User albo Queue) + sharing	Brak bezpośredniego odpowiednika; przeprojektuj jako role, sharing rules, kolejki. Gryzie.
Option Sets (globalne / lokalne)	Picklisty / Global Value Sets	Mapuj po wartości liczbowej i etykiecie, nie po wyświetlanym tekście. Gryzie.
Connection / Connection Role	Account Contact Relationship albo obiekt junction	Brak bezpośredniego odpowiednika; zamodeluj relacje, których faktycznie używasz.
Note (annotation) + Attachment	ContentDocument (Files) / Notes	Annotations przechowują załączniki inline; rozdziel je przy ładowaniu.
Case	Case	Czysto, jeśli przenosisz też Customer Service.

Strategia migracji danych: czego nie migrować

Najcenniejsza decyzja w całym projekcie dotyczy tego, czego z Dynamics nie przenosisz. Każdy zmigrowany zamknięty rekord to dane, które do końca świata będziesz w Salesforce przechowywać, indeksować i backupować. A większości z nich nikt już nigdy nie odczyta.

Ustal twardą regułę dla każdego obiektu i broń jej. Sprawdzony punkt wyjścia: przenosisz wszystkie otwarte rekordy, niezależnie od wieku; z zamkniętych — te z ustalonego okna wstecznego; resztę archiwizujesz do data lake albo eksportu tylko do odczytu. Przykładowo: przenieś otwarte Opportunity i wszystkie zamknięte z ostatnich 24 miesięcy, a starszy zamknięty pipeline wyeksportuj zamiast ładować.

Potraktuj przejście jako bramkę porządkową, a nie masowe kopiowanie. Deduplikuj przed ładowaniem, nie po. Uporządkuj dane referencyjne (kraje, branże, waluty) jeszcze na etapie mapowania, żeby nowy org od pierwszego dnia miał spójne dane. Przyda się tu też porządny przegląd jakości danych: Data Quality Sense skanuje wsadowo zmigrowany zbiór i raportuje kompletność, duplikaty i błędy formatowania, więc walidujesz ładowanie na dowodach, a nie na przypadkowych próbkach. Narzędzie tylko raportuje, niczego nie naprawia automatycznie — co poprawić przed cutoverem, decyduje architekt.

Przepięcie integracji

CRM nigdy nie działa w próżni. Przed cutoverem spisz wszystkie systemy, które czytają z Dynamics albo do niego zapisują: ERP, platformę marketingową, telefonię, generowanie dokumentów, BI. Każdy z nich to osobne zadanie do przepięcia, z własnym terminem i własnym właścicielem.

Nie przyjmuj jednego wzorca dla wszystkich — dobierz go do każdej integracji z osobna. Przepięcie punkt-punkt wystarczy dla jednego czy dwóch feedów o małym ruchu. Gdy odbiorców jest kilku albo ruch jest duży, wstaw warstwę integracyjną między CRM a resztę świata — wtedy każdą przyszłą zmianę robisz w jednym miejscu. Jeśli SAP albo Oracle zostaje system of record, kwestia właściciela danych master jest ważniejsza niż sam transport: ustal, który system jest właścicielem klienta, produktu i cen, zanim napiszesz choć jedno mapowanie.

Integracje Dynamics zostaw włączone na czas parallel runu. Oba systemy mają dostawać dane, dopóki nie zaufasz nowemu — nic za nimi nie może zgasnąć w trakcie przełączania.

Parallel run i cutover

Parallel run oznacza, że przez ograniczony czas oba systemy pracują na danych produkcyjnych, a Ty je ze sobą uzgadniasz. To nie jest miękki start. Metryki uzgadniania ustal z góry: liczby rekordów dla każdego obiektu, wartość otwartego pipeline’u, wolumen aktywności na właściciela, liczby komunikatów z integracji. Kiedy te liczby zgadzają się w obu systemach przez uzgodniony okres, cutover masz wypracowany.

Jeśli org na to pozwala, przełączaj funkcja po funkcji, a nie wszystko naraz. Sprzedaż może się już przenieść, a stary feed raportowy jeszcze przez miesiąc czytać z Dynamics. W ogłoszonym wcześniej momencie zamrażasz zapisy w Dynamics, robisz końcowe ładowanie delty, po raz ostatni weryfikujesz metryki — i przełączasz integracje oraz odbierasz dostęp do zapisu w Dynamics.

Na pierwsze dni miej plan awaryjny. Zwykle wystarczy, że Dynamics zostaje do odczytu, a skrypty ładowania delty czekają gotowe do ponownego uruchomienia — nikt nie robi pełnej migracji odwrotnej. Chodzi o spokój w ruchu do przodu, z możliwością wstrzymania się, gdyby coś poszło nie tak.

Checklist: nie przenoś starych problemów

Przejdź tę listę, zanim podpiszesz docelowy schemat. Każda pozycja to problem, który migracja odtworzy automatycznie, jeśli nie zdecydujesz inaczej.

1. Przebuduj własność, nie kopiuj jej. Przełóż owner teams i access teams z Dynamics na role, sharing rules i kolejki. Nie odtwarzaj własności zespołowej jako pola lookup.
2. Przeprojektuj aktywności na WhatId / WhoId. Każdy typ aktywności z Dynamics kieruj do Task albo Event świadomie; sprawdź w teście, że powiązania „regarding” lądują na właściwych rekordach.
3. Mapuj option sety po wartości, nie po etykiecie. Upewnij się, że rekordy historyczne trafiają na właściwe API name picklisty — łącznie z wartościami nieaktywnymi.
4. Zamknięte dane zostawiaj według reguły. Wszystko poza oknem wstecznym archiwizuj, zamiast ładować do produkcyjnego orga.
5. Deduplikuj przed ładowaniem. Duplikaty naprawiaj u źródła albo w stagingu — nie importuj ich z zamiarem sprzątania później.
6. Nie klonuj schematu Dynamics. Pomiń pola, których nikt nie używa, i całą otoczkę Business Process Flow, którą i tak zastąpisz automatyzacją Salesforce.
7. Standard danych referencyjnych ustal raz. Znormalizuj kraje, waluty i branże już na etapie mapowania, żeby org startował czysty.
8. Waliduj ładowanie na dowodach. Uzgadniaj liczby, własność i pipeline skanem jakości danych, a nie przypadkowymi próbkami.

Gdzie to się mieści — i kiedy nas nie potrzebujesz

Jeśli Twój org Dynamics jest mały — jeden zespół sprzedaży, niewiele integracji, głównie standardowe encje — sprawny admin i dobre narzędzie migracyjne poradzą sobie bez nas, a zatrudnianie architekta byłoby przesadą. Architektura zarabia na siebie tam, gdzie zaczyna się skala i współistnienie: kilka jednostek biznesowych, ERP, który zostaje system of record, nietrywialny sharing albo roadmapa Agentforce, dla której nowy model musi być poprawny.

Tak właśnie wygląda zlecenie CRM Transformation: prowadzone przez architekta, od mapowania obiektów po cutover, ze starymi problemami zostawionymi w starym systemie. Jeśli migracja jest na Twojej roadmapie, powyższe decyzje mapowania to pierwsza rzecz, którą warto przetestować na serio.

Jeśli stoisz przed szerszą decyzją albo migrujesz z innej platformy, zajrzyj do naszych przewodników o strategii replatformingu CRM, migracji z SAP CRM do Salesforce i migracji z HubSpot do Salesforce.

Najczęściej zadawane pytania

Ile trwa migracja z Dynamics 365 do Salesforce?

Wszystkie terminy zależą od zakresu, więc traktuj je orientacyjnie. Org jednego zespołu ze standardowymi encjami może przenieść się w kilka tygodni; org z kilkoma jednostkami biznesowymi, integracją z ERP, rozbudowaną historią option setów i wymogiem współistnienia potrzebuje dłużej. Najmocniej na termin wpływa mapa obiektów i uzgadnianie w parallel runie, a nie samo kopiowanie danych.

Czy można zmigrować aktywności z Dynamics 365 do Salesforce?

Tak, ale nie metodą kopiuj-wklej. Dynamics trzyma aktywności jako jedną polimorficzną encję powiązaną polem „regarding”. Salesforce rozbija je na Task i Event z WhatId i WhoId. Każdy typ aktywności trzeba przy ładowaniu skierować do właściwego obiektu Salesforce i przełożyć powiązanie regarding — inaczej historyczne aktywności przyczepią się do złych rekordów.

Czy migrować wszystkie dane historyczne z Dynamics?

Nie. Przenieś wszystkie otwarte rekordy i zamknięte z ustalonego okna wstecznego, a resztę zarchiwizuj do eksportu tylko do odczytu albo data lake. Każdy załadowany zamknięty rekord to dane, które do końca świata indeksujesz i backupujesz — a większości nikt już nigdy nie odczyta. Migracja to Twoja bramka porządkowa.

Co psuje się najczęściej w migracji z Dynamics do Salesforce?

Trzy rzeczy. Aktywności — bo polimorficzny model z Dynamics rozpada się na Task i Event. Własność — bo owner teams i access teams nie mają jednego odpowiednika w Salesforce i trzeba je przełożyć na role, sharing rules i kolejki. I option sety — bo ich kluczem są wartości liczbowe, więc mapujesz po wartości, a nie po wyświetlanej etykiecie.

Czy Dynamics ma działać w trakcie migracji?

Tak, przez ograniczony czas parallel runu. Oba systemy pracują wtedy na danych produkcyjnych, a Ty uzgadniasz liczby rekordów, własność i otwarty pipeline. Integracje Dynamics zostaw włączone, żeby systemy downstream dalej dostawały dane. Potem zamrażasz zapisy, robisz końcowe ładowanie delty, weryfikujesz metryki i przełączasz integracje na Salesforce.