Jacek Szafader 2026-09-29 Czytasz:
Migracja z Salesforce do Dynamics 365: czego nie widać w ofercie
- Anatomia typowego przypadku
- Wyzwanie historyczne: dług technologiczny bez właściciela
- Wyzwanie techniczne: dane są tylko jednym ze strumieni
- Wyzwanie biznesowe: CRM jako źródło forecastingu finansowego
- Dwa strumienie, których nie wolno schować w „migracji danych”
- Wyzwanie terminowe: dlaczego „lift and shift” bywa złudzeniem
- Archiwum: eksport to dopiero początek
- Wyzwanie adopcyjne: zmiana nawyków, nie ikony
- 10 pytań przed wyborem partnera migracyjnego
- Najważniejszy wniosek
Dziesięć lat konfiguracji, setki nieużywanych pól, automatyzacje, których autor dawno nie pracuje w firmie — i twardy deadline wynikający z wygasającej umowy licencyjnej. To nie jest zwykła migracja danych. To projekt archeologiczny.
Migracje z Salesforce do Microsoft Dynamics 365 coraz częściej wynikają z presji kosztowej, potrzeby pracy w ekosystemie Microsoft 365 oraz chęci połączenia CRM z narzędziami używanymi codziennie przez sprzedaż. Sama decyzja o zmianie platformy jest jednak łatwiejsza niż jej wykonanie.
Poniżej opisujemy realne wyzwania na przykładzie zanonimizowanego scenariusza: międzynarodowej firmy usługowej posiadającej około 100 licencji Salesforce, około 100 aktywnych użytkowników i środowisko rozwijane od dziesięciu lat. Liczby i problemy są autentyczne, ale nie identyfikują konkretnego klienta.
Anatomia typowego przypadku
Punkt wyjścia wygląda niegroźnie. To właśnie dlatego takie projekty bywają niedoszacowane.
Wymiar | Stan zastany | Dlaczego to ma znaczenie |
|---|---|---|
Wiek instalacji | ok. 10 lat | Konfiguracja utrwala dawne procesy i decyzje. |
Licencje | ok. 100 aktywnych użytkowników | Niewielka liczba użytkowników nie oznacza małej złożoności. |
Zakres | Business Development / Sales | Pozostałe zespoły pracują poza CRM-em lub ręcznie. |
Główne dane | Accounts, Contacts, Opportunities, Activities | Trzon jest prosty; złożoność zwykle znajduje się w konfiguracji i wyjątkach. |
Pola | dużo nieużywanych | Trzeba rozstrzygnąć, co jest wymaganiem, a co reliktem. |
Automatyzacje | niepełna wiedza o liczbie i użyciu | To jedna z największych niewiadomych wyceny. |
Kompetencje | brak eksperta Salesforce wewnątrz organizacji | Brakuje pamięci instytucjonalnej: „po co to powstało?”. |
Właściciel | jedna osoba biznesowa i techniczna | Wąskie gardło decyzyjne oraz ryzyko ciągłości. |
Integracje | formalnie poza zakresem | Mimo to trzeba sprawdzić API, Connected Apps, SSO, pocztę i eksporty. |
Zależność krytyczna | forecasting finansowy z Opportunity | CRM jest krytycznym systemem źródłowym dla budżetowania. |
Termin | twardy; bez długiej pracy równoległej | Cutover i plan awaryjny stają się częścią zakresu podstawowego. |
Wyzwanie historyczne: dług technologiczny bez właściciela
Ośmioletnia instalacja Salesforce to warstwy decyzji podejmowanych przez osoby, które często nie pracują już w firmie. Pola dodawane pod jedną kampanię. Powiadomienia kierowane do nieaktywnych skrzynek. Reguły walidacji chroniące proces, który dawno się zmienił.
Do tego dochodzi zmiana po stronie producenta: Salesforce zakończył 31 grudnia 2025 r. wsparcie dla Workflow Rules i Process Builder. Istniejące automatyzacje mogą nadal działać, ale są to narzędzia legacy, dla których producent zakończył wsparcie i rekomenduje przejście do Flow Buildera. Źródło: Salesforce Help
Co zrobić przed wyceną
- Wspólnie zinwentaryzować automatyzacje: partner wydobywa i analizuje konfigurację, a właściciele biznesowi potwierdzają jej znaczenie procesowe.
- Dla każdej pozycji opisać obiekt, wyzwalacz, warunki, działania, zależności, właściciela biznesowego oraz ostatnie potwierdzone użycie.
- Automatyzacje, które długo się nie uruchamiały, traktować jako kandydatów do wycofania — dopiero po potwierdzeniu z właścicielem procesu i sprawdzeniu zależności.
- Nie kopiować długu technologicznego 1:1. Każdy element powinien otrzymać decyzję: odtworzyć, uprościć, zastąpić standardem albo wycofać.
Ostrzeżenie: Inwentaryzacja automatyzacji i zależności może zająć więcej czasu niż techniczny transport podstawowych rekordów. Oferta przygotowana bez tej wiedzy jest scenariuszem budżetowym, a nie pełną wyceną.
Wyzwanie techniczne: dane są tylko jednym ze strumieni
Częste założenie brzmi: „mamy cztery główne obiekty i kilkadziesiąt tysięcy rekordów, więc migracja będzie prosta”. Transport podstawowych rekordów bywa rzeczywiście bardziej przewidywalny niż rekonstrukcja konfiguracji i logiki. Nie oznacza to jednak niskiego ryzyka.
- Relacje między rekordami, hierarchie klientów i identyfikatory źródłowe muszą pozostać spójne.
- Właściciele rekordów oraz widoczność danych zależą od docelowego modelu bezpieczeństwa.
- Activities, e-maile, notatki i pliki wymagają osobnego modelu mapowania i testów.
- Historia zmian i audyt nie są zwykłymi polami biznesowymi.
- Każdy przebieg migracji wymaga reconciliation: policzenia rekordów, błędów, relacji i kluczowych sum biznesowych.
Record Types nie mają jednego odpowiednika
Salesforce i Dynamics 365 realizują podobne cele CRM, ale różnią się sposobem implementacji modelu danych, bezpieczeństwa, procesów i automatyzacji. Dobrym przykładem są Salesforce Record Types. Mogą wpływać m.in. na układ strony, dostępne wartości list oraz przebieg procesu. W Dynamics 365 i Dataverse nie istnieje jeden mechanizm, który należy zawsze zastosować w ich miejsce.
Intencję Record Type odwzorowuje się — zależnie od przypadku — za pomocą kombinacji formularzy, security roles, kolumn Choice, Business Process Flows, business rules, Power Automate, a czasem odmiennego modelu tabel i relacji. Dlatego mapowanie „pole do pola” nie wystarcza. Trzeba zmapować cel biznesowy stojący za konfiguracją.
Mniejszy wolumen pomaga, ale nie skraca wszystkiego
Ograniczenie migracji do aktywnych danych i historii wymaganej przez finanse zmniejsza czas ekstrakcji, ładowania, czyszczenia, reconciliation oraz liczbę wyjątków. Nie skraca jednak proporcjonalnie całego wdrożenia. System docelowy nadal wymaga modelu danych, formularzy, bezpieczeństwa, automatyzacji, raportowania, testów i przygotowania startu.Narzędzia przyspieszają mechanikę, nie decyzje
Dostępne są narzędzia Microsoft oraz akceleratory partnerskie wspierające analizę metadanych, mapowanie i transport danych z Salesforce do Dataverse. Mogą ograniczyć pracę ręczną i zwiększyć powtarzalność kolejnych przebiegów migracji. Ich dostępność i zakres należy jednak potwierdzić dla konkretnego projektu.Zasada: Żaden akcelerator nie rozstrzygnie, czy stara automatyzacja nadal ma sens, kto powinien widzieć rekord ani jak ma działać forecasting. Narzędzia wspierają migrację; nie zastępują analizy procesów i architektury.
Wyzwanie biznesowe: CRM jako źródło forecastingu finansowego
Najważniejsze ryzyko często wychodzi na jaw dopiero podczas rozmowy o raportach. W opisywanym scenariuszu wartości z Opportunity — spodziewany przychód rozłożony na lata — są cyklicznie eksportowane i wykorzystywane przez finanse do budżetowania. CRM nie jest systemem finansowo-księgowym, ale jest krytycznym systemem źródłowym dla forecastingu.Konsekwencje praktyczne
- Minimalny zakres danych na start określa nie tylko sprzedaż, lecz także finanse: okres, waluty, statusy, daty i sposób rozkładania przychodu.
- Ciągłość raportowania jest kryterium go-live, a nie zadaniem do dopracowania w hypercare.
- Definicje raportów Salesforce nie mają natywnej konwersji 1:1 do Dynamics. Trzeba odtworzyć ich logikę, filtry, uprawnienia i prezentację w Dynamics 365 lub Power BI.
- Reconciliation powinno obejmować nie tylko liczbę Opportunities, lecz także sumy expected revenue według roku, waluty, etapu, właściciela i jednostki organizacyjnej.
Przykładowa brama go/no-go: Kluczowe raporty finansowe w systemie docelowym muszą zwracać uzgodnione wyniki dla tego samego, zamrożonego zbioru danych co raporty źródłowe. Dopuszczalne różnice powinny być jawnie opisane i zaakceptowane.
Bezpieczeństwo i ownership nie mapują się automatycznie
Profile, Permission Sets i mechanizmy sharing w Salesforce nie przekładają się wprost na security roles, business units, teams, ownership i zabezpieczenia kolumn w Dataverse. Docelowy model dostępu trzeba zaprojektować, a następnie przetestować na realnych personach: handlowcu, menedżerze, finansach, administratorze oraz użytkowniku z dostępem tylko do wybranego zakresu.
Pułapka jednego właściciela
Jeżeli ta sama osoba odpowiada za biznes, technikę, czyszczenie danych, UAT i adopcję, staje się pojedynczym punktem awarii. Przed startem należy wskazać sponsora, właścicieli procesów oraz co najmniej jedną osobę wspierającą decyzje techniczne i operacyjne. Brak wewnętrznego administratora powinien być uwzględniony w modelu usług po uruchomieniu.
Konsekwencje praktyczne
1. Jakość danych, duplikaty i wyjątki
2. Activities, e-maile i pliki
3. Integracje ukryte poza formalnym zakresem
Wyzwanie terminowe: dlaczego „lift and shift” bywa złudzeniem
Gdy umowa z Salesforce wygasa, a równoległe utrzymywanie dwóch platform jest zbyt kosztowne, naturalnym pomysłem jest „lift and shift”: przenieść stan obecny bez ulepszeń. Przy starej instalacji podejście to ma jednak ograniczenie — nie da się wiernie odtworzyć konfiguracji, której znaczenia organizacja nie potrafi już wyjaśnić.Podejście fazowane przy krótkim terminie
Strumień | Zakres | Warunek powodzenia |
|---|---|---|
Faza 1 — minimum na start | Accounts, Contacts, Opportunities i niezbędne Activities; prosty proces sprzedaży; dane aktywne i historia wymagana przez finanse; kluczowe raporty; bezpieczeństwo; szkolenia i hypercare. | Zakres zamrożony wcześnie; mierzalne kryteria go/no-go. |
Faza 2 — po stabilizacji | Pozostała historia, kolejne typy procesów, wybrane automatyzacje, dodatkowe raporty i rozszerzenie na account management. | Roadmapa oraz decyzje „odtworzyć / uprościć / wycofać”. |
Archiwum — równolegle | Kompletny i zweryfikowany eksport danych, plików, metadanych i historii dostępnej w środowisku źródłowym. | Archiwum musi być czytelne i możliwe do przeszukania, nie tylko zapisane. |
Cutover jest osobnym produktem projektu
Przy twardej dacie migracji plan przełączenia nie może być pojedynczym zadaniem w harmonogramie. Powinien obejmować co najmniej:- mock cutover i potwierdzenie realnego czasu ekstrakcji, transformacji, ładowania oraz walidacji;
- freeze zmian i danych w Salesforce oraz zasady obsługi wyjątków;
- final delta i jednoznaczną godzinę graniczną;
- właścicieli kroków, kanał dowodzenia i kryteria go/no-go;
- plan rollbacku lub kontrolowany scenariusz awaryjny, jeśli powrót do pełnej pracy w Salesforce nie będzie możliwy;
- komunikację do użytkowników i gotowość hypercare od pierwszej godziny pracy.
Ostrzeżenie: Jeśli oferta nie pokazuje cutoveru, reconciliation i odpowiedzialności za decyzję go/no-go, ryzyko nie zniknęło. Zostało tylko przeniesione na klienta.
Archiwum: eksport to dopiero początek
Pełny eksport Salesforce należy wykonać i zweryfikować przed wyłączeniem środowiska. Operacyjny dostęp po zakończeniu subskrypcji może ustać, a możliwość późniejszego odzyskania danych zależy od warunków umowy oraz obowiązujących procedur. Dlatego nie warto budować planu na założeniu, że „w razie czego wrócimy do Salesforce”.Co powinno obejmować kompletne archiwum
- Dane wraz z oryginalnymi identyfikatorami, relacjami, hierarchiami i słownikami wartości.
- Użytkowników, właścicieli i informacje potrzebne do interpretacji ownership.
- Salesforce Files, Content Versions, Attachments i Documents — wraz z powiązaniami do rekordów.
- Osobny snapshot metadanych i konfiguracji: pola, obiekty, układy, Record Types, automatyzacje, walidacje, Apex, permission sets i raporty.
- Dostępną historię zmian i audyt, z uwzględnieniem faktycznej retencji oraz posiadanych licencji.
- Manifest eksportu, liczbę rekordów per obiekt, listę błędów, checksums plików oraz raport reconciliation.
- Praktyczną warstwę odczytu: katalog danych, opis relacji i uzgodniony sposób wyszukania informacji po wyłączeniu CRM.
Ważne: Zbiór plików CSV i folder załączników w Data Lake jest kopią techniczną. Staje się archiwum biznesowym dopiero wtedy, gdy organizacja potrafi znaleźć rekord, odtworzyć jego relacje i otworzyć powiązany dokument.
Wyzwanie adopcyjne: zmiana nawyków, nie ikony
Użytkownicy pracujący od lat w jednym CRM mają wypracowane odruchy. Zmiana platformy jest zmianą sposobu pracy: gdzie zapisujemy notatkę, jak kwalifikujemy Opportunity, które dane są obowiązkowe i gdzie szukamy historii klienta. Praca w ekosystemie Microsoft może obniżyć barierę wejścia, ponieważ użytkownicy pozostają blisko Outlooka i Teams. Nie należy jednak obiecywać konkretnych funkcji Copilota ani zakresu integracji bez sprawdzenia konfiguracji. Dostępność funkcji zależy od wybranych planów Dynamics 365 i Microsoft 365, konfiguracji administratora, pojemności Dataverse oraz ewentualnych licencji Power BI, Power Automate i Copilot.Minimum planu adopcyjnego
- Szkolenia oparte na rzeczywistych scenariuszach pracy, zakończone przed startem produkcyjnym.
- Super-userzy uczestniczący w testach i wspierający zespół po uruchomieniu.
- Hypercare z określonym zakresem, godzinami dostępności, priorytetami i czasem trwania.
- Model wsparcia po hypercare, szczególnie gdy klient nie ma własnego administratora.
- Fusion team: osoby klienta pracują z partnerem, aby kompetencje pozostały w organizacji.
10 pytań przed wyborem partnera migracyjnego
1. Jak partner zinwentaryzuje automatyzacje, Record Types, walidacje, raporty, uprawnienia i zależności oraz jak podzieli odpowiedzialność z właścicielami biznesowymi?
2. Które elementy zostaną odtworzone, uproszczone, zastąpione standardem lub wycofane — i kto zatwierdzi te decyzje?
3. Jak będzie wyglądało mapowanie modelu bezpieczeństwa, ownership i dostępu do danych między Salesforce a Dataverse?
4. Jakie reguły jakości, deduplikacji i survivorship zostaną zastosowane do Accounts, Contacts i pozostałych danych?
5. Jak partner potraktuje Activities, e-maile, notatki i pliki oraz jak potwierdzi kompletność relacji?
6. Jakie są mierzalne kryteria odbioru i go/no-go — w tym reconciliation rekordów, relacji, plików oraz sum finansowych forecastingu?
7. Jaki jest szczegółowy plan cutoveru: mock cutover, freeze, final delta, okno niedostępności, właściciele kroków i scenariusz rollbacku lub awaryjny?
8. Co dokładnie obejmuje archiwum: dane, pliki, metadane, historia/audyt, manifest, weryfikacja kompletności i sposób późniejszego odczytu?
9. Które raporty muszą działać w dniu startu i jak zostanie odtworzona ich logika, filtry, uprawnienia oraz prezentacja w Dynamics 365 lub Power BI?
10. Jakie licencje i pojemności są wymagane dla poszczególnych person oraz które funkcje Dynamics 365, Outlook, Teams, Power BI, Power Automate i Copilot są zawarte, dodatkowo płatne lub ograniczone?
Najważniejszy wniosek
Migracja Salesforce do Dynamics 365 nie jest trudna dlatego, że rekordy są ciężkie do skopiowania. Jest trudna dlatego, że przez lata konfiguracja CRM stała się nieformalną dokumentacją procesów, wyjątków, odpowiedzialności i sposobu raportowania firmy.
Najbezpieczniejsze projekty nie próbują przenieść wszystkiego bezrefleksyjnie. Najpierw ustalają, co musi działać w dniu startu, jak zostanie potwierdzona zgodność wyników oraz gdzie bezpiecznie trafi pozostała historia. Dopiero potem dobierają narzędzia i kolejność migracji.
Jedno zdanie do zapamiętania: Przy twardym terminie redukuj zakres funkcjonalny, ale nie redukuj kontroli: bezpieczeństwa, testów, reconciliation, cutoveru i archiwum.