Software handover checklist: co zebrać przed zmianą vendora

Software handover checklist brzmi nudno, dopóki stary vendor traci zainteresowanie projektem, a nowy zespół odkrywa, że nikt nie ma dostępu do produkcji.

Większość zmian vendora psuje się w lukach: jeden sekret CI, jeden nieopisany cron, jedna baza staging z innymi danymi niż produkcja, jedna osoba, która wiedziała, jak robi się release, ale już wyszła ze Slacka. Repozytorium z kodem to tylko część przekazania. Prawdziwy handover to kontekst, dzięki któremu nowy zespół może bezpiecznie zmienić system bez zgadywania.

Ta checklista jest dla founderów, CTO, liderów operacyjnych i product ownerów, którzy przenoszą custom software od jednego zespołu do drugiego. Użyj jej przed końcem umowy, nie po.

Software handover checklist na pierwsze 48 godzin

Zacznij od rzeczy, które trzymają produkt przy życiu. Jeśli odchodzący vendor ma mało czasu, nie zaczynaj od ładnego dokumentu architektury. Zacznij od dostępów, backupów, deploymentu i listy osób, które wiedzą, gdzie są ukryte problemy.

Zbierz to w pierwszych 48 godzinach:

repozytoria kodu, także archiwalne repo, skrypty deploymentu, infrastructure as code i prywatne mirrors pakietów
adresy środowisk production, staging i test wraz z właścicielami i ścieżką dostępu
konta hostingowe, projekty cloud, DNS, domeny, email, analytics, monitoring i płatności
konfigurację CI/CD, komendy builda, zmienne środowiskowe, listę sekretów, gałęzie release i kroki rollback
reguły dostępu do baz danych, lokalizacje backupów, instrukcje restore, retencję i wyniki ostatniego testu odtworzenia
aktualne incydenty, otwarte problemy bezpieczeństwa, zablokowane release i znane kruche miejsca

Celem nie jest natychmiastowa migracja wszystkiego. Celem jest odpowiedź, czy nowy zespół utrzyma system jutro, jeśli coś zepsuje się dziś w nocy.

Handover codebase to więcej niż zaproszenie do GitHuba

Zaproszenie do GitHuba pokazuje, gdzie leży kod. Nie wyjaśnia, jak system zachowuje się na produkcji.

Poproś odchodzący zespół o godzinny technical walkthrough. Wystarczy zwykłe nagranie ekranu: struktura repo, główne usługi, local setup, testy, release flow i miejsca, których sami boją się dotykać. Zapisz nagranie. Dokumentacja pisemna jest przydatna, ale rozmowa często odsłania prawdziwe skróty.

Dla każdego repozytorium zapisz:

wersje runtime, package managers, komendy builda, testów i lintowania
wymagane lokalne usługi, pliki Docker, seed data, feature flags i mocki integracji
reguły branchy, tagi release, wersjonowanie i hotfix process
kod generowany, migracje, skrypty, background workers i joby cykliczne
moduły ze słabym pokryciem testów albo zmianami, które często psują inne części
zależności przypięte dlatego, że poprzedni upgrade coś zepsuł

Dobra reguła: nowy developer powinien sklonować repo, uruchomić aplikację lokalnie, puścić testy i wysłać niewielką zmianę bez prywatnej rozmowy ze starym zespołem. Jeśli to niemożliwe, zapisz dokładnie, co blokuje ten scenariusz.

Przeniesienie dostępów i własności przed końcem umowy

Dostępy to miejsce, w którym handover robi się polityczny. Odchodzący vendor mógł założyć konta cloud, konta developerskie Apple albo Google, DNS, klucze API, monitoring i subskrypcje third party na firmowy email vendora. To ryzyko biznesowe, nie detal administracyjny.

Zbuduj tabelę własności z czterema kolumnami: system, obecny właściciel, docelowy właściciel, status transferu. Uwzględnij nudne usługi: transactional email, SMS, mapy, tax calculation, error tracking, uptime checks, odnowienia domen, package registries i narzędzia projektowe.

Potem usuń konta współdzielone. Utwórz nazwane konta dla nowego zespołu, obróć sekrety po zmianie dostępów i zostaw awaryjny owner access po stronie klienta. Jeśli nikt po stronie klienta nie może zresetować credentiali produkcyjnych, handover nie jest skończony.

Dokumentacja, która pomaga następnemu zespołowi

Nie proś o 60-stronicowy dokument, którego nikt nie będzie utrzymywał. Poproś o notatki robocze, których nowy zespół użyje w pierwszym tygodniu.

Pakiet handover powinien zawierać:

overview systemu: usługi, bazy, kolejki, integracje i aplikacje użytkowników
deployment guide: jak kod trafia na produkcję, kto akceptuje release i jak działa rollback
data guide: główne encje, source of truth, eksporty danych, ograniczenia prywatności i reguły usuwania
integration guide: zewnętrzne API, webhooki, limity, retry i alerty po awarii
operations guide: typowe incydenty, skrzynki supportu, ręczne zadania admina i eskalacje
product guide: aktywna roadmapa, porzucone pomysły, bóle użytkowników i obiecane prace dla klientów

Jeden dobry diagram wystarczy, jeśli jest uczciwy. Pokaż systemy, które istnieją, a nie architekturę, która ładnie wyglądałaby w prezentacji.

Handover danych i check compliance

Dane łatwo potraktować jak zwykły eksport techniczny. Zwykle są bardziej wrażliwe. Przed zmianą vendora ustal, do jakich danych ma dostęp vendor, gdzie istnieją kopie oraz co trzeba usunąć albo zachować po handoverze.

Sprawdź dane klientów, dane pracowników, logi, eksporty analytics, backupy, screenshoty w ticketach, załączniki supportowe i bazy testowe. Jeśli dane produkcyjne trafiły na staging, zdecyduj, czy trzeba je wyczyścić. Jeśli odchodzący vendor trzyma backupy, ustal termin i dowód usunięcia.

To też moment, żeby sprawdzić, czy system ma prawdziwą ścieżkę restore. Backup, którego nikt nie odtworzył, jest życzeniem. Zrób co najmniej jeden test restore, zanim stary zespół zniknie.

Handover release: udowodnij, że nowy zespół może wdrażać

Handover nie kończy się na przeniesieniu plików. Kończy się wtedy, gdy nowy zespół potrafi bezpiecznie wysłać małą zmianę.

Zaplanuj kontrolowany release w okresie nakładania się zespołów. Wybierz coś mało ryzykownego: zmianę copy, poprawę logowania, cleanup feature flag albo drobną poprawkę w panelu admina. Nowy zespół prowadzi release. Stary zespół patrzy i odpowiada na pytania. Jeśli release się wysypie, uczysz się, kiedy oba zespoły są jeszcze dostępne.

Podczas tego release sprawdź:

CI startuje z czystej gałęzi
sekrety są dostępne przez właściwy vault albo manager środowiska
migracje są sprawdzone przed produkcją
monitoring pokazuje deployment i błędy
instrukcja rollback jest aktualna
product, support i operations wiedzą, co się zmieniło

Zmiana vendora bez testowego release to handover tylko na papierze.

30-dniowy plan software handover

Realistyczny handover nie musi trwać miesiącami, ale potrzebuje kolejności. Ten plan 30 dni pasuje do wielu małych i średnich produktów custom software.

Tydzień 1: zamroź ryzykowne zmiany zakresu, zbierz dostępy, zinwentaryzuj systemy, wyeksportuj dokumentację i zaplanuj technical walkthroughs.

Tydzień 2: uruchom local setup, przejrzyj architekturę, zmapuj integracje, sprawdź backupy i wypisz pilne ryzyka.

Tydzień 3: obróć credentiale, przenieś własność, domknij luki w CI/CD i zrób pierwszy release nowego zespołu na staging.

Tydzień 4: wyślij małą zmianę na produkcję, potwierdź monitoring, zamknij krytyczne luki dostępowe i ustal backlog utrzymania na pierwsze 90 dni.

Jeśli stary vendor odchodzi w konflikcie, skróć plan, ale zachowaj kolejność: dostępy, backupy, ścieżka release, ryzyka, dopiero potem usprawnienia.

Czerwone flagi przy software project takeover

Niektóre problemy handover są niewygodne. Inne mówią, że produkt wymaga głębszego audytu, zanim ktokolwiek obieca nowe funkcje.

Uważaj na te sygnały:

odchodzący zespół nie umie wyjaśnić, jak działa deployment na produkcję
sekrety produkcyjne leżą w czacie, prywatnym password managerze albo lokalnych plikach
klient nie jest właścicielem cloud account, domeny, konta app store albo płatności
testy istnieją, ale nikt im nie ufa przed release
staging jest kilka miesięcy za produkcją
backupy istnieją, ale kroki restore są nieznane
jeden developer jako jedyny rozumie krytyczny moduł
backlog miesza bugi, obietnice, faktury i zmiany zakresu bez właściciela

Jeśli widzisz kilka takich punktów naraz, potraktuj przejęcie jak due diligence, a nie zwykły onboarding. Nasza software due diligence checklist pokazuje głębszy przegląd przed przejęciem ryzyka.

Software handover FAQ

Czym jest software handover checklist?

Software handover checklist to lista kodu, dostępów, dokumentacji, danych, deploymentu, ryzyk i procesów supportu, które muszą przejść z jednego zespołu albo vendora do drugiego przed zmianą odpowiedzialności.

Ile powinien trwać software handover?

Mały produkt można często przekazać w dwa do czterech tygodni, jeśli dostępy są uporządkowane, a odchodzący zespół współpracuje. Złożone produkty z wieloma integracjami, słabą dokumentacją albo konfliktem z vendorem mogą potrzebować więcej czasu.

Co powinno wejść do software project handover?

Uwzględnij repozytoria, środowiska, credentiale, własność cloud, CI/CD, instrukcje deploymentu, backupy baz, kroki restore, notatki architektury, szczegóły integracji, znane bugi, procesy supportu i test pierwszego release.

Kto jest właścicielem kodu po handoverze od vendora?

Klient powinien być właścicielem kodu, repozytoriów, kont cloud, domen, danych i pipeline deploymentu, chyba że umowa mówi inaczej. Sprawdź zapisy IP i prawa transferu, zanim stary vendor odejdzie.

Jakie jest największe ryzyko przy zmianie software vendora?

Największym ryzykiem jest ukryta wiedza operacyjna: nieopisane kroki deploymentu, prywatne konta, brakujące sekrety, nieznane przepływy danych i kruche fragmenty kodu, które rozumie tylko stary zespół.

Potrzebujesz pomocy przy przejęciu produktu software?

Syntanea pomaga firmom audytować, stabilizować i przejmować custom software, gdy zmienia się vendor albo projekt utknął. Jeśli potrzebujesz czystego planu handover przed startem kolejnej umowy, porozmawiajmy. Zaczniemy od dostępów, bezpieczeństwa release, danych i ryzyk, które mogą zaboleć najszybciej.