Migracja z arkuszy lub innego systemu: plan na 14 dni bez przestoju

Migracja z jednego systemu do drugiego budzi ten sam strach niezależnie od tego, czy odchodzisz z arkusza kalkulacyjnego, czy z innego narzędzia: co, jeśli dane się nie zgodzą, klient straci dostęp do bramy, a rozliczenie miesięczne przesunie się o kilka dni? Ten poradnik pokazuje plan, który eliminuje ten strach — dwie fazy importu, plan dzień po dniu i moment przełączenia, w którym stary system przestaje działać dopiero wtedy, gdy nowy jest sprawdzony.

Największym źródłem niepokoju przy migracji zwykle nie jest sam nowy system, tylko niepewność, czy stary da się bezpiecznie wyłączyć. Odpowiedź na to pytanie brzmi zawsze tak samo: stary system wyłączasz dopiero wtedy, gdy raport z importu na sucho jest czysty, a nie wtedy, gdy termin migracji wypada w kalendarzu. Poniższy plan zakłada dokładnie taką kolejność — najpierw sprawdzasz, potem przełączasz, nigdy odwrotnie.

Co naprawdę trzeba przenieść

Migracja nie polega na przeniesieniu wszystkiego, co kiedykolwiek zapisałeś. Cztery kategorie danych naprawdę muszą trafić do nowego systemu, zanim przełączysz operacje:

Zajętość. Które komórki są wynajęte, które wolne, jakie mają rozmiary i typy. Bez tego nowy system nie wie, co jeszcze można sprzedać, a co jest już zajęte.

Klienci. Dane kontaktowe, historia płatności na tyle, na ile jest potrzebna do rozliczeń, oraz informacja, czy klient ma jakąś zaległość w dniu migracji.

Umowy. Aktywne umowy najmu: komórka, czynsz, data rozpoczęcia, okres wypowiedzenia, kaucja. To one definiują, ile klient płaci i kiedy.

Kotwica rozliczeniowa. Dzień miesiąca, do którego przypisane jest naliczanie czynszu dla danego klienta — to najczęściej pomijany, a najbardziej kosztowny element migracji, opisany osobno w następnej sekcji.

Kody dostępu to piąty element, techniczny, ale krytyczny: kody PIN do bramy i zamków, które muszą działać w nowym systemie od dnia przełączenia, żeby żaden klient nie stanął przed zamkniętą bramą.

Czego zwykle nie trzeba przenosić z pełną wiernością: archiwalnej korespondencji sprzed lat, historii zmian cennika, która nie wpływa na bieżące umowy, ani danych klientów, którzy zakończyli najem dawno temu i nie wracają. Próba przeniesienia absolutnie wszystkiego wydłuża migrację bez realnej korzyści — skup się na tym, co wpływa na obsługę klienta od dnia startu.

Kotwica rozliczeniowa: najczęstszy błąd

Kotwica rozliczeniowa to dzień miesiąca, w którym nalicza się czynsz konkretnemu klientowi — nie każdy klient płaci „od pierwszego”, część płaci od dnia, w którym podpisała umowę, np. od 17. każdego miesiąca.

Najczęstszy błąd migracji polega na zresetowaniu wszystkich kotwic do jednego wspólnego dnia (np. 1. dnia miesiąca) dla wygody importu. Efekt: klient, który zawsze płacił od 17., dostaje nagle wezwanie do zapłaty 1., czyli efektywnie o dwa tygodnie wcześniej niż się spodziewał, albo płaci za okres, który już opłacił w starym systemie — podwójnie.

Poprawna migracja przenosi kotwicę rozliczeniową klient po kliencie, dokładnie tak, jak wynika ze starego systemu, i weryfikuje ją w fazie importu na sucho, zanim cokolwiek zostanie zapisane na stałe.

Dwie fazy importu

Bezpieczna migracja dzieli się na dwie fazy, z etapem pośrednim, który pozwala złapać błędy, zanim staną się realnym problemem klienta.

Faza 1: zrzut danych. Eksport zajętości, klientów, umów i historii płatności ze starego systemu do jednego pliku (najczęściej CSV lub eksport bazy danych). Ty sprawdzasz listę — to moment, w którym łatwiej zauważyć brakującego klienta niż po imporcie właściwym.

Faza pośrednia: import na sucho. Nowy system wczytuje dane bez zapisywania ich na stałe i generuje raport: ile komórek zaimportowano, ile umów, ile kwot się nie zgadza względem oczekiwań. Błędy poprawia się i powtarza import na sucho, aż raport wychodzi czysty — bez żadnych rozbieżności w liczbach.

Faza 2: import właściwy. Dopiero gdy raport z importu na sucho jest czysty, dane zapisują się na stałe, nadają się kody do bramy i ustawiają kotwice rozliczeniowe. Ten krok wykonuje się zwykle w nocy, żeby nie kolidował z bieżącą obsługą klientów.

Ten sam schemat — zrzut, na sucho, właściwy — sprawdza się niezależnie od tego, czy źródłem jest arkusz kalkulacyjny, czy inny system z eksportem danych. Dla źródeł bez API czy eksportu (typowe dla mniejszych, starszych narzędzi) minimalnym wsadem do zrzutu jest lista najemców z podstawowymi danymi umowy — reszta odtwarza się ręcznie na etapie importu na sucho.

Ile błędów zwykle łapie import na sucho? Najczęściej trzy typy: komórkę oznaczoną jako wolną w starym systemie, choć w rzeczywistości jest zajęta (albo odwrotnie); dwie różne daty kotwicy rozliczeniowej dla tego samego klienta w dwóch różnych eksportach; oraz kwotę czynszu, która nie zgadza się z ostatnią zaksięgowaną płatnością. Żaden z tych błędów nie jest groźny, jeśli wychwycisz go na sucho — każdy staje się problemem klienta, jeśli przejdzie niezauważony do importu właściwego.

Plan na 14 dni

Poniższy harmonogram to typowy przebieg migracji dla operatora z jednym placem, licząc od założenia konta w nowym systemie do dnia startu.

Dzień	Co się dzieje
1	Firma, plac, konto w systemie
2–3	Faktury i płatności: klucze API, test faktury i BLIK
4–5	Brama i zamki: sterownik, test kodu
6	Strona wynajmu: logo, kolory, opis
7–9	Zrzut danych i import na sucho
10–12	Poprawki, szkolenie operatorów (1 h)
13	Import właściwy w nocy
14	Start, wsparcie na czacie cały dzień

Kolejność nie jest przypadkowa: płatności i brama są gotowe i przetestowane zanim ruszy właściwy import danych, więc gdy dane trafiają do systemu, reszta infrastruktury już działa i czeka tylko na klientów. Odwrócenie tej kolejności — najpierw import danych, potem konfiguracja płatności i bramy — jest częstym błędem, bo prowadzi do sytuacji, w której dane klientów są już w nowym systemie, ale nikt nie może jeszcze zapłacić ani wjechać na plac.

Dla operatora z kilkoma placami plan wydłuża się proporcjonalnie do liczby lokalizacji, ale kolejność faz zostaje ta sama dla każdego placu z osobna — nie próbuj łączyć zrzutu danych z kilku placów w jeden import, bo utrudnia to później namierzenie błędu, jeśli raport z importu na sucho pokaże rozbieżność.

Komunikacja z klientami

Klienci nie muszą znać szczegółów technicznych migracji, ale powinni wiedzieć dwie rzeczy z wyprzedzeniem: że coś się zmienia i że to nie wymaga od nich żadnego działania poza ewentualnym zalogowaniem się do nowego portalu.

SMS przed migracją, kilka dni wcześniej: „[Imię], w najbliższych dniach zmieniamy system obsługi najmu. Twoja umowa i płatności zostają bez zmian, dostaniesz nowy dostęp do portalu i kod do bramy. Szczegóły wkrótce.”

E-mail w dniu startu, z konkretami: „Od dziś obsługujemy [nazwa placu] w nowym systemie. Twój kod do bramy: bez zmian / nowy — [kod]. Portal klienta: [link]. Pytania? Odpisz na tego maila albo zadzwoń: [telefon].”

Krótkie, konkretne komunikaty, wysłane właściwym kanałem (SMS dla pilnej informacji o dostępie, e-mail dla szczegółów z linkami) zmniejszają liczbę telefonów w dniu przełączenia niemal do zera. Warto też przygotować jedno zdanie odpowiedzi na najbardziej oczywiste pytanie — „czy muszę coś zrobić?” — i umieścić je w obu wiadomościach z góry, zamiast czekać, aż klienci zapytają o to osobno.

Dzień przełączenia

W dniu 14 stary system przestaje być jedynym źródłem prawdy, ale nie wyłączaj go tego samego dnia całkowicie — zostaw dostęp tylko do odczytu przez kolejny tydzień lub dwa, na wypadek gdyby trzeba było sprawdzić coś z historii sprzed migracji. Nowy system od tego dnia obsługuje wszystkie nowe płatności, rezerwacje i kody dostępu.

Pierwsze 24 godziny warto potraktować jak dyżur: sprawdzaj, czy pierwsze automatyczne przypomnienia i naliczenia wychodzą zgodnie z przeniesionymi kotwicami rozliczeniowymi, a nie zresetowaną datą. To najszybszy sposób złapania błędu, zanim dotrze do więcej niż jednego klienta.

Jeśli w pierwszym dniu ktoś zgłosi, że kod do bramy nie działa albo faktura pokazuje złą kwotę, potraktuj to jako sygnał do sprawdzenia szerzej, nie jako pojedynczy wyjątek — błąd w kotwicy rozliczeniowej albo w mapowaniu kodów dostępu zwykle dotyczy więcej niż jednego klienta naraz, tylko pierwszy zauważa go najszybciej.