Jak przygotować dane do migracji z Excela lub starego CRM?

Przygotowanie migracji warto zacząć od wykonania niezmienianej kopii danych i spisania wszystkich miejsc, w których firma je przechowuje. Następnie trzeba ustalić, co przenosimy, jak rozpoznajemy klientów i kontakty, które pola odpowiadają sobie w obu systemach oraz co robimy z brakami i duplikatami. Dopiero po próbnym imporcie i sprawdzeniu wyniku można planować właściwe przełączenie.

Sam eksport do CSV nie potwierdza, że dane są kompletne i gotowe do użycia. Plik może zawierać listę klientów, ale nie musi zachowywać relacji z osobami kontaktowymi, notatek, załączników, historii zmian, zadań ani informacji o uprawnieniach. Dlatego migracja nie polega wyłącznie na przeniesieniu wierszy z jednego miejsca do drugiego.

Plik CSV to dopiero jedno ze źródeł

CSV jest popularnym formatem wymiany danych między arkuszami i systemami. Nawet jego podstawowa struktura wymaga jednak prawidłowej obsługi nagłówków, separatorów, znaków końca linii i wartości zawierających przecinki albo cudzysłowy. Różne programy mogą też zapisywać takie pliki na różne sposoby.

To problem techniczny, ale ważniejszy jest problem biznesowy. Kolumna `Klient` może w jednym arkuszu oznaczać firmę, a w innym konkretną osobę. Pole `Status` może zawierać etap sprzedaży, stan płatności albo informację, czy kontakt jest aktywny. Podobna nazwa kolumny nie oznacza więc automatycznie tego samego znaczenia.

Przed importem trzeba również sprawdzić, gdzie znajdują się dane, których nie ma w głównej tabeli. Mogą to być:

• kontakty przypisane do firm;
• notatki i historia rozmów;
• zadania, terminy oraz przypomnienia;
• dokumenty i załączniki;
• zamówienia, sprawy lub szanse sprzedaży;
• zgody, źródła kontaktu i informacje o opiekunach;
• wartości przechowywane tylko w dodatkowych arkuszach albo plikach.

Jeżeli nowy system ma obsługiwać te informacje, trzeba zaplanować ich przeniesienie osobno. Nie należy zakładać, że pojawią się w eksporcie tylko dlatego, że były widoczne na ekranie starego CRM.

1. Zabezpiecz dane przed rozpoczęciem porządkowania

Najpierw zachowaj oryginalny eksport albo kopię w miejscu, w którym nikt nie będzie jej poprawiał. Zapisz datę wykonania, nazwę systemu, zakres danych i osobę odpowiedzialną. Jeżeli dane pochodzą z kilku arkuszy lub aplikacji, zachowaj każde źródło oddzielnie.

Nie poprawiaj jedynej kopii pliku. Utwórz wersję roboczą i prowadź listę wykonanych zmian. Dzięki temu można wrócić do materiału źródłowego, porównać wartości i wyjaśnić, skąd wzięła się konkretna decyzja.

Trzeba też ustalić, czy pracownicy nadal zmieniają dane w starym systemie. Jeżeli przygotowanie migracji potrwa kilka dni lub tygodni, pierwszy eksport szybko przestanie być aktualny. Wtedy plan powinien uwzględniać ostatni eksport albo przeniesienie różnic powstałych po wykonaniu próbnej kopii.

Sposób wykonania kopii zależy od używanego systemu i dostępnych uprawnień. Eksport widoczny w panelu nie zawsze obejmuje bazę, pliki i całą historię, dlatego zakres trzeba potwierdzić dla konkretnego rozwiązania.

2. Spisz wszystkie źródła i ustal, którym wartościom ufać

W wielu firmach część danych znajduje się w CRM, część w arkuszach, a najnowsze ustalenia w poczcie albo prywatnych notatkach pracowników. Przed migracją trzeba te miejsca nazwać i określić, kto ich używa.

Nie trzeba wskazywać jednego źródła jako najlepszego dla wszystkich informacji. CRM może być właściwym źródłem danych kontaktowych, a system zamówień źródłem wartości sprzedaży. Ważne, aby reguła była jawna dla każdego istotnego pola.

Jeżeli dwie wartości są sprzeczne, importer nie powinien sam zgadywać, która jest prawidłowa. Taki przypadek można oznaczyć do sprawdzenia albo rozstrzygnąć według wcześniej zaakceptowanej zasady.

3. Zdecyduj, co przenosić, a co zostawić w archiwum

Przeniesienie wszystkiego nie zawsze jest najlepszym rozwiązaniem. Stary CRM może zawierać lata nieaktualnych kontaktów, zamknięte sprawy, testowe rekordy i pola, których firma już nie używa. Skopiowanie ich bez oceny przeniesie stary bałagan do nowego systemu i utrudni codzienną pracę.

Warto osobno ustalić zakres dla:

• aktywnych i archiwalnych klientów;
• osób kontaktowych oraz ich powiązań z firmami;
• otwartych i zakończonych spraw, zleceń lub szans sprzedaży;
• notatek, zadań, terminów i historii zmian;
• dokumentów, załączników i odnośników do plików;
• statusów, źródeł kontaktu, opiekunów i innych słowników;
• danych potrzebnych do raportów, obsługi i rozliczeń.

Czasem pełny eksport można zachować jako archiwum do odczytu, a do nowego CRM przenieść tylko dane potrzebne w bieżącej pracy. Nie należy jednak podejmować takiej decyzji wyłącznie technicznie. Zakres powinien zatwierdzić właściciel procesu i osoba odpowiedzialna za dane. Artykuł nie rozstrzyga również prawnych okresów przechowywania informacji.

4. Przygotuj mapę pól i słownik wartości

Mapa pól opisuje, skąd pochodzi każda informacja, co oznacza i gdzie ma trafić w nowym systemie. Powinna też zawierać regułę dla brakującej albo nieprawidłowej wartości.

Osobnej uwagi wymagają statusy i pola wyboru. W starym systemie mogą występować wartości `nowy`, `w toku`, `oddzwonić`, `wygrany` i `zamknięty`, podczas gdy nowy CRM ma inny podział etapów. Każda stara wartość powinna mieć uzgodniony odpowiednik albo zostać skierowana do ręcznej decyzji.

Podobnie jest z datami, kwotami, numerami telefonów, kodami pocztowymi, krajami i językami. Można bezpiecznie usunąć zbędne odstępy albo ujednolicić zapis, jeżeli nie zmienia to znaczenia. Nie należy natomiast wymyślać brakujących wartości tylko po to, aby import przeszedł bez komunikatu o błędzie.

5. Zachowaj identyfikatory i relacje między rekordami

Nowy CRM powinien wiedzieć nie tylko, że firma i osoba kontaktowa istnieją, lecz także że są ze sobą powiązane. To samo dotyczy spraw, zamówień, notatek i dokumentów. Jeżeli podczas eksportu znikną identyfikatory albo relacje, system może utworzyć poprawną liczbę rekordów, ale przypisać je do niewłaściwych klientów.

Adres e-mail, telefon lub nazwa firmy nie zawsze jest bezpiecznym identyfikatorem. Kilka osób może korzystać ze wspólnej skrzynki `biuro@`, jeden kontakt może współpracować z więcej niż jedną firmą, a nazwa przedsiębiorstwa może się zmienić. Z kolei ten sam klient może występować w kilku arkuszach pod nieco inną nazwą.

Dlatego warto zachować identyfikator ze starego systemu i nadać rekordowi identyfikator w systemie docelowym. Tabela powiązań pomaga później sprawdzić, gdzie trafiły kontakty, sprawy i historia.

6. Rozdziel pewne duplikaty od podobnych rekordów

Duplikat nie zawsze oznacza dwa identyczne wiersze. Rekordy mogą różnić się literówką, numerem telefonu, dawnym adresem albo nazwą oddziału. Mogą też wyglądać podobnie, mimo że dotyczą różnych osób lub firm.

Przed scaleniem trzeba ustalić:

1. po jakich cechach rozpoznajemy pewne powtórzenie;
2. które wartości zostają w rekordzie wynikowym;
3. co robimy z notatkami, historią i powiązanymi sprawami obu rekordów;
4. które przypadki wymagają decyzji człowieka;
5. jak zapisujemy informację o wykonanym scaleniu.

Bezpiecznie można automatyzować tylko zmiany zgodne z zaakceptowaną regułą. Podejrzanych rekordów nie należy łączyć wyłącznie na podstawie podobieństwa nazwy. Lepiej pozostawić je do weryfikacji niż połączyć historie dwóch różnych klientów.

7. Wykonaj próbny import na reprezentatywnej próbce

Próbny import powinien odbyć się w środowisku testowym albo odizolowanej kopii systemu docelowego, jeżeli jest dostępna. Nie wybieraj wyłącznie najprostszych rekordów. Próbka powinna zawierać zwykłe dane oraz przypadki, które mogą ujawnić błąd mapowania.

Warto uwzględnić między innymi:

• firmę z kilkoma osobami kontaktowymi;
• kontakt bez numeru telefonu albo innego pola wymaganego w nowym systemie;
• długą notatkę ze znakami narodowymi;
• dwa podobne rekordy, których nie wolno automatycznie połączyć;
• zamkniętą i aktywną sprawę;
• załącznik albo odnośnik do dokumentu;
• nieaktywnego użytkownika wskazanego jako dawny opiekun;
• wartość statusu, która nie ma prostego odpowiednika.

Po próbie zapisz błędy i decyzje, popraw mapę, a następnie wykonaj import ponownie. Komunikat `import zakończony` oznacza jedynie, że proces się wykonał. Nie potwierdza, że dane trafiły do właściwych pól i dają się wykorzystać w pracy.

8. Sprawdź wynik na kilku poziomach

Sama liczba wierszy nie wystarcza do odbioru migracji. Trzeba wiedzieć, ile rekordów wyeksportowano, odrzucono, połączono i zaimportowano, a następnie sprawdzić ich znaczenie oraz powiązania.

Wynik powinny sprawdzić osoby znające dane i proces, nie tylko wykonawca importu. Pracownik sprzedaży szybciej zauważy, że firma ma niewłaściwego opiekuna albo etap sprawy nie zgadza się z rzeczywistością.

9. Zaplanuj przełączenie i możliwość wycofania

Po poprawnej próbie trzeba ustalić moment końcowego eksportu, czas ograniczenia zmian w starym systemie i osoby zatwierdzające wynik. Plan powinien odpowiadać na kilka prostych pytań:

• kiedy przestajemy edytować dane w starym CRM;
• czy potrzebny jest ostatni eksport różnic powstałych po próbie;
• ile czasu przeznaczamy na kontrolę;
• kto podejmuje decyzję o rozpoczęciu pracy w nowym systemie;
• co robimy, jeżeli wynik nie spełnia ustalonych kryteriów;
• jak długo i w jakim zakresie zachowujemy dostęp do starego źródła albo archiwum.

Migracja nie zawsze może odbyć się bez przerwy. Zależy to od możliwości obu systemów, liczby zmian wprowadzanych w ciągu dnia i sposobu wymiany danych. Dlatego czasu przełączenia nie należy obiecywać przed sprawdzeniem konkretnego przypadku.

10. Co przygotować przed rozmową z wykonawcą?

Na początku nie trzeba wysyłać pełnej bazy. Wystarczy przygotować:

1. listę systemów, arkuszy i dodatkowych źródeł;
2. opis danych i ich znaczenia w codziennej pracy;
3. listę pól, statusów i najważniejszych relacji;
4. przybliżoną liczbę rekordów, plików i załączników;
5. informację o danych aktywnych i archiwalnych;
6. znane problemy z brakami, formatami i duplikatami;
7. oczekiwany termin oraz dopuszczalne ograniczenia pracy;
8. osobę, która może podejmować decyzje dotyczące danych;
9. kryteria odbioru próby i właściwej migracji;
10. anonimową albo syntetyczną próbkę pokazującą strukturę danych.

Do pierwszego formularza nie przesyłaj haseł, kluczy, prawdziwych danych klientów ani kopii bazy. Najpierw potrzebny jest opis sytuacji i struktury, a sposób bezpiecznego przekazania materiałów można ustalić później.

Jeżeli nie masz jeszcze pewności, czy firma potrzebuje gotowego CRM, integracji czy własnego systemu, użyj planera wyboru rozwiązania CRM. Narzędzie pomaga uporządkować potrzeby, ale nie analizuje przesłanych danych i nie tworzy wyceny migracji.

Co pokazują wcześniejsze realizacje Domin Software?

W historycznym projekcie HUB.ITM.PL przygotowaliśmy system, który odczytywał dane pochodzące z różnych programów księgowych i przekształcał je do formatu EDI++ używanego przez Subiekt GT oraz Subiekt nexo. Rozwiązanie ograniczało ręczne przepisywanie dużej liczby faktur w biurze rachunkowym. Projekt nie działa już produkcyjnie, ponieważ formaty i warunki wymiany danych się zmieniły. Ten przykład potwierdza doświadczenie w mapowaniu wielu źródeł, ale nie jest obietnicą zgodności z dzisiejszymi wersjami tych programów.

W projekcie HUB-2-API system importował dużą listę produktów z arkusza, a następnie wykorzystywał dane do obsługi ofert eBay.de, zamówień i API dla trzech klientów z Francji. Był to przepływ produktów i zamówień, a nie migracja klientów ze starego CRM. Pokazuje jednak, dlaczego przed automatyzacją trzeba znać strukturę źródła i reguły systemu docelowego.

W obu przypadkach najważniejsze było ustalenie znaczenia danych i sposobu ich kontroli. Sam format pliku nie rozwiązywał problemu.

Najczęstsze pytania

Czy do migracji wystarczy eksport z Excela albo CSV?

Zwykle nie. Eksport może zawierać podstawowe pola, ale trzeba osobno sprawdzić relacje, notatki, historię, załączniki, słowniki i identyfikatory. Zakres zależy od możliwości starego i nowego systemu.

Czy trzeba przenosić wszystkie dane ze starego CRM?

Nie zawsze. Część informacji można pozostawić w uzgodnionym archiwum, a do nowego systemu przenieść dane potrzebne w bieżącej pracy. Decyzję powinien zatwierdzić właściciel danych i procesu.

Jak wykrywać duplikaty klientów i kontaktów?

Najpierw trzeba ustalić cechy wskazujące pewne powtórzenie oraz sposób zachowania historii. Podobna nazwa, wspólny e-mail albo telefon nie zawsze wystarczą do automatycznego scalenia.

Co zrobić z brakującymi albo sprzecznymi danymi?

Należy określić regułę dla każdego ważnego pola. Wartość można oznaczyć do sprawdzenia, pozostawić pustą albo przypisać według zaakceptowanego słownika. System nie powinien sam wymyślać informacji.

Czy można zachować notatki, historię i załączniki?

Czasem tak, ale zależy to od eksportu źródłowego, API, struktury plików i możliwości importu nowego systemu. Wykonalność trzeba sprawdzić przed ustaleniem zakresu.

Jak sprawdzić, czy próbny import jest poprawny?

Porównaj liczby rekordów, kluczowe pola, relacje i słowniki, a następnie przejrzyj reprezentatywne przypadki. Sprawdź też, czy użytkownicy potrafią wykorzystać dane w swoim codziennym procesie.

Czy migrację można wykonać bez zatrzymania pracy firmy?

Nie można tego zagwarantować bez sprawdzenia obu systemów. Czasem wystarczy krótka przerwa i końcowy eksport, a czasem potrzebny jest etap przejściowy albo dodatkowa integracja.

Jak bezpiecznie przekazać próbkę do wyceny?

Na początku przekaż opis struktury i próbkę syntetyczną lub zanonimizowaną. Nie wysyłaj przez zwykły formularz haseł, kluczy, pełnej bazy ani prawdziwych danych klientów.

Wybierz następny krok

Jeżeli dopiero wybierasz rozwiązanie, przejdź do planera wyboru CRM. Pomoże ustalić, czy bardziej pasuje gotowy CRM, integracja, dodatkowy moduł czy własny system.

Jeżeli znasz już proces i potrzebujesz rozwiązania dopasowanego do firmy, sprawdź systemy bazodanowe, CRM i ERP na zamówienie. Zakres migracji i wycena wymagają sprawdzenia źródeł, relacji, liczby danych oraz możliwości systemu docelowego.

Gdy stary i nowy system mają działać równolegle albo dane trzeba regularnie wymieniać, użyj planera integracji systemów i sprawdź ofertę integracji systemów oraz API. Migracja jednorazowa i stała integracja to dwa różne zakresy prac.

Źródła

• RFC 4180: Common Format and MIME Type for Comma-Separated Values (CSV) Files, RFC Editor, dostęp sprawdzony 30.10.2026.