Migracja zaczyna się od zdania „przenosimy tylko konto”. Potem okazuje się, że trzeba przenieść projekty, instrukcje, wiedzę, integracje, uprawnienia, przyzwyczajenia i jeden bardzo ważny skrypt, o którym nikt nie pamiętał. Nowe narzędzie ma ładniejszy interfejs, ale stary proces przestaje działać w piątek o 16:00.
Dobra migracja nie jest kopiowaniem wszystkiego. Jest sprawdzeniem, co faktycznie wymaga przeniesienia, jak zachować jakość i jak wrócić, jeśli nowa opcja nie zadziała. Poniższy plan pomaga zmienić model lub platformę bez utraty wiedzy i bez urządzania tygodnia awaryjnego.
Inwentarz przed eksportem
Wypisz projekty, dokumenty, instrukcje, integracje, konta, właścicieli i zależności. Zaznacz, co jest aktywne, co archiwalne i co nie ma właściciela. Jeżeli nie wiesz, czy coś działa, otwórz proces i sprawdź, zamiast przenosić na zasadzie „na wszelki wypadek”.
Zapisz wersje instrukcji i źródeł. Screenshot nie wystarczy. Potrzebujesz tekstu, nazw, dat i informacji o tym, która wersja jest obowiązująca. Zanotuj także rzeczy niemigrowalne: historię, konkretne funkcje, ustawienia, format eksportu i ograniczenia dostawcy.
Do każdego elementu przypisz decyzję: przenieść, zaktualizować, zarchiwizować, usunąć lub odtworzyć. Migracja jest dobrym momentem na porządek. Nie przenoś czterech wersji cennika, z których trzy były błędne.
Zmapuj zmianę znaczenia
Nowy model może interpretować tę samą instrukcję inaczej. Zapisz, które zasady są krytyczne: źródła, format, ograniczenia, odmowa, uprawnienia, styl. Nie zakładaj, że skopiowany prompt zachowa się identycznie. Przygotuj przypadki testowe przed zmianą.
Zrób mapę różnic: format wejścia, ograniczenia kontekstu, sposób cytowania, dostępne narzędzia, retencja, eksport i logi. Zaznacz, co wymaga nowej decyzji, a co tylko konfiguracji. Integracja działająca przez przypadek wymaga udokumentowania, nie podziwu.
Jeżeli proces zależy od funkcji, której nowa platforma nie ma, zaplanuj zamiennik albo ogranicz zakres. Nie udawaj, że da się to załatwić później. Później jest zwykle produkcja.
Eksport, który da się odebrać
Pobierz dane w dostępnym formacie i sprawdź otwarcie bez starego konta. Tytuły, treść, daty, właściciele, załączniki i relacje powinny być kompletne. Zrób małą próbkę importu, nie czekaj na pełną migrację.
Zachowaj oryginały w stanie tylko do odczytu przez uzgodniony czas. Nie kasuj starej wiedzy przed potwierdzeniem nowej. Zanotuj liczbę dokumentów i sumę kontrolną, żeby wykryć braki. Jeżeli relacje nie przechodzą, opisz je osobno.
Nie eksportuj sekretów do zwykłych plików. Tokeny i klucze przenoś przez właściwy menedżer sekretów. Przygotuj nowe uprawnienia zamiast kopiować stare szerokie dostępy. To dobry moment na ograniczenie zakresu.
Evaluacje przed migracją
Przygotuj zestaw przypadków zwykłych, trudnych i krytycznych. Zapisz wynik starego systemu jako punkt odniesienia: poprawność, źródło, format, czas przeglądu i błędy. Nie porównuj nowego modelu tylko z wrażeniem „kiedyś było lepiej”.
Dołącz przypadki bez odpowiedzi i sprzeczne źródła. Nowy model powinien zachować ograniczenia, nie tylko odpowiadać. Oceń polskie znaki, nazwy i naturalny ton. Integracja powinna zwracać oczekiwany format, nie tylko ładny akapit.
Jeżeli nowy wynik jest gorszy, zapisz przyczynę: inna wiedza, inna instrukcja, brak funkcji, inny kontekst czy rzeczywista zmiana jakości. To pozwala poprawić właściwy element.
Równoległy pilotaż, nie wielki wyłącznik
Uruchom nowy system na małym zakresie, podczas gdy stary nadal działa. Jedna grupa, jeden typ zadania, krótki okres. Porównaj ten sam przypadek w obu. Nie wyłączaj starego przed odbiorem nowego.
Ustal warunki przejścia: jakość nie gorsza od progu, brak błędów krytycznych, komplet dokumentów, działające uprawnienia i możliwość rollbacku. Po spełnieniu zwiększaj zakres. Nie przenoś wszystkiego w jednym weekendzie.
Komunikuj, kiedy zaczyna się test i gdzie zgłaszać problemy. Zespół nie powinien zgadywać, która wersja jest właściwa. Oznacz stare i nowe źródła, żeby uniknąć mieszania odpowiedzi.
Uprawnienia i logi
Odtwórz role zgodnie z zasadą minimalizmu. Sprawdź odczyt, zapis, wysyłkę i usuwanie osobno. Testuj odmowę poza zakresem. Nowy system nie powinien odziedziczyć konta administratora tylko dlatego, że było wygodnie.
Zachowaj logi migracji: kto przeniósł, kiedy, jaki zakres, wynik testów i akceptacje. Przy danych wrażliwych ogranicz treść logów do identyfikatorów i rezultatów. Nie kopiuj pełnych dokumentów do kolejnego rejestru.
Jeżeli integracja wymaga nowych tokenów, przygotuj odwołanie starych dopiero po odbiorze. Plan odłączenia jest częścią migracji, nie dodatkiem na później.
Rollback, czyli plan powrotu bez paniki
Zapisz, kiedy wracasz do starego systemu: błąd krytyczny, utrata danych, spadek jakości poniżej progu, brak wymaganej funkcji lub koszt poza limitem. Wyznacz właściciela decyzji i sposób przywrócenia. Rollback nie może zaczynać się od „a może da się to naprawić”.
Przechowaj konfigurację starego procesu i wymagane dostępy przez okres testowy. Po przywróceniu sprawdź, czy działa rzeczywisty przypadek, nie tylko logowanie. Poinformuj zespół o decyzji i źródłach prawdy.
Po migracji zaplanuj usunięcie duplikatów i odwołanie dostępu do starego systemu. Nie zostawiaj dwóch produkcyjnych źródeł prawdy. To prosty sposób na przypadkową odpowiedź z nieaktualnej wersji.
Komunikacja bez technicznego mgławika
Wyjaśnij, co zmienia się dla użytkowników: nowy adres, sposób pracy, data, ograniczenia i miejsce zgłoszeń. Nie wysyłaj tylko informacji „mamy nowe narzędzie, będzie lepiej”. Powiedz, co trzeba zrobić i kiedy.
Przygotuj krótką instrukcję z dwoma przykładami i sekcją „jeśli coś nie działa”. Zaznacz, czy stare projekty są dostępne tylko do odczytu. Dobre wdrożenie zmniejsza opór, bo ludzie nie muszą zgadywać nowych reguł.
Po tygodniu zbierz konkretne problemy i porównaj z założeniami. Jeżeli nowa opcja wymaga więcej pracy, nie tłumacz, że użytkownicy nie chcą zmian. Czasem proces po prostu nie jest lepszy.
Kiedy warto skorzystać z planu wyjścia zamiast migracji
Jeżeli nowy system nie przechodzi testów, nie musisz go bronić. Możesz zostać przy obecnym, wybrać inny albo ograniczyć AI. Plan wyjścia od dostawcy powinien istnieć przed podpisaniem, nie dopiero po problemie.
Pomocny jest artykuł Aeneia Signal o planie wyjścia od dostawcy AI. Przy odbiorze materiałów i odpowiedzialności warto sprawdzić również odbiór kodu i poufność po pracy agentów.
Lista odbioru przed wyłączeniem starego systemu
Sprawdź każdy aktywny projekt: czy ma właściciela, źródło, wersję i działający przypadek w nowym miejscu. Otwórz eksport bez starego konta i porównaj liczbę dokumentów. Jeżeli relacje nie przechodzą, zapisz je w osobnym rejestrze. Nie uznawaj importu za kompletny tylko dlatego, że nie zgłosił błędu.
Przetestuj rolę zwykłego użytkownika i administratora. Jedna powinna widzieć tylko swoje dokumenty, druga zarządzać zakresem. Sprawdź odmowę dostępu i usunięcie integracji. Jeżeli odwołanie nie działa, nie migruj dalej.
Dopiero po tych krokach wyznacz datę ograniczenia starego systemu do odczytu. Zapisz, kiedy dostęp zostanie odwołany całkowicie. Migracja kończy się dopiero wtedy, kiedy nie ma dwóch aktywnych źródeł prawdy.
Jak porównać ten sam prompt w dwóch systemach
Przygotuj jeden przypadek z dokumentem i jeden bez odpowiedzi. Wklej tę samą instrukcję i zapisz wynik obok siebie. Sprawdź fakty, format, źródło i ograniczenia. Nie oceniaj tylko stylu. Jeżeli nowy model zmienia decyzję, zapisz konkretne zdanie.
Jeżeli różnica wynika z braku funkcji, nie poprawiaj promptu bez końca. Zmień proces albo wybierz inny sposób. Funkcja nie zawsze ma odpowiednik tekstowy. To jest decyzja architektoniczna, nie kwestia lepszej prośby.
Zachowaj wynik starego systemu jako dowód. Kiedy ktoś powie „kiedyś było lepiej”, możesz porównać dane zamiast wspomnień. Czasem nowa opcja jest lepsza, a czasem tylko inna.
Rollback nie polega na ponownym imporcie wszystkiego
Jeżeli nowy system zawodzi, zatrzymaj zapis i określ, które dokumenty powstały po migracji. Stare źródło powinno nadal mieć komplet sprzed przełączenia, a nowe prace trzeba wyeksportować osobno. Bez takiego rejestru powrót może nadpisać najnowsze zmiany starszą kopią.
Przypisz właściciela decyzji i czas, w którym zespół przestaje tworzyć nowe wersje. Przywróć poprzedni proces dla jednego przypadku, sprawdź uprawnienia i źródła, a dopiero potem otwórz go dla wszystkich. Komunikat ma wskazywać właściwe miejsce pracy, nie tylko „wracamy do starego”.
Po rollbacku porównaj liczbę rekordów i daty ostatniej zmiany. Zachowaj log błędów nowego systemu do analizy. Jeśli nowe dokumenty nie da się od razu przenieść, oznacz je jako osobne archiwum z właścicielem. Nie mogą zniknąć dlatego, że wdrożenie nie wyszło.
Zamknięcie konta jest częścią migracji
Po okresie odczytu wykonaj eksport końcowy i sprawdź go na innym koncie. Następnie odwołaj integracje, webhooki i tokeny. Usuń użytkowników, zamknij automatyczne odnawianie oraz zapisz potwierdzenie zakończenia rozliczeń. Sam brak logowania przez miesiąc nie jest rezygnacją z subskrypcji.
Sprawdź politykę retencji i procedurę usunięcia danych. Eksport nie oznacza, że dostawca automatycznie kasuje kopie. Wewnętrzny rejestr powinien pokazywać, co zostało usunięte, jakie kopie zapasowe mają określony termin i kto odebrał potwierdzenie. Nie używaj prawdziwych danych klientów do testowania tej ścieżki.
Na końcu otwórz stare publiczne linki i skróty. Jeżeli mają działać, przygotuj odpowiednie przekierowania lub instrukcję dla użytkowników. Jeśli mają wygasnąć, sprawdź brak dostępu po wylogowaniu. Porządek po migracji chroni zarówno dane, jak i kolejny rachunek. Pełny rachunek z okresem równoległym opisuje przewodnik o całkowitym koszcie AI.
Ręczna próba bez pomocy twórcy procesu
Poproś osobę, która nie uczestniczyła w konfiguracji, o znalezienie jednego dokumentu, wykonanie typowego zadania i zgłoszenie błędu w nowym systemie. Daj jej tylko instrukcję przeznaczoną dla zespołu. Nie pomagaj w trakcie poza sytuacją ryzyka.
Zapisz miejsca zawahania i różnice w terminologii. Być może „projekt” znaczy co innego w obu narzędziach albo eksport znajduje się pod nieintuicyjną nazwą. Popraw instrukcję przed kolejną grupą. Proces, który działa tylko z autorem migracji przy barku, nie został jeszcze odebrany.
Komunikat dla zespołu na dzień migracji
Napisz krótko: co przechodzi, kiedy, co trzeba zrobić i gdzie zgłaszać problemy. Dodaj dwa przykłady nowego procesu i wskazanie starego archiwum. Nie wymagaj od zespołu odkrywania nowych reguł metodą klikania.
Zaznacz, że nowe prace są wykonywane tylko w nowym systemie, a stare służy do odczytu. To ogranicza duplikaty i przypadkowe wersje. Wskaż właściciela decyzji o rollbacku i sposób jego uruchomienia.
Po tygodniu zbierz trzy najczęstsze błędy i popraw instrukcję. Nie odpisuj „to kwestia przyzwyczajenia”, jeżeli proces rzeczywiście wymaga więcej pracy. Dane z testów są lepsze niż optymistyczna narracja o transformacji.
Migracja ma dać lepszą pracę, nie nową religię. Masz inwentarz, testy, komplet danych, ograniczone uprawnienia i możliwość powrotu. Jeżeli coś z tego brakuje, jeszcze nie jesteś gotowy na wielki przycisk „przenieś wszystko”.
Sprawdź nas. To zdrowe.
Temat zmienia się szybko. Linki prowadzą do źródeł pierwotnych i stron, na których możesz zweryfikować kontekst.
