Software vendor exit plan: jak zachować kontrolę przed końcem umowy

Software vendor exit plan to nie notatka o rozstaniu z dostawcą. To zestaw praw, plików, kont i rutyn, które pozwalają odejść od vendora bez ryzykowania produktu.

Większość firm myśli o takim planie dopiero wtedy, gdy relacja jest już napięta. Wtedy zwykle znika spokojny overlap. Stary zespół wolniej zamyka tickety, nowy zadaje podstawowe pytania, a nikt nie jest pewien, kto ma klucze do deploymentu.

Jeśli utrzymujesz custom software, plan wyjścia powinien istnieć wtedy, gdy współpraca z vendorem nadal działa. Powinien leżeć obok umowy, procesu supportu i kalendarza release.

Co powinien obejmować software vendor exit plan

Dobry software vendor exit plan odpowiada na jedno praktyczne pytanie: czy inny sensowny zespół mógłby utrzymać produkt w ciągu 30 dni?

To nie znaczy, że wymieniasz wszystkich developerów z dnia na dzień. Chodzi o to, żeby produkt nie był zamknięty w skrzynce, koncie cloud, laptopie albo pamięci jednego dostawcy.

Minimum to:

własność kodu źródłowego i repozytoriów
dostęp do production, staging i backupów
kroki deploymentu i rollback
zasady eksportu, retencji i usuwania danych
konta third party i klucze API
otwarte incydenty, znane bugi i rutyny supportu
dokumentacja, walkthroughs i wsparcie w przejściu

Jeśli którykolwiek z tych punktów zależy od tego, czy jedna osoba będzie miła w dniu odejścia, nie masz planu wyjścia. Masz nadzieję.

Zacznij od zapisów w umowie przed wyjściem od vendora

Najlepszy plan wyjścia zaczyna się przed pierwszym sprintem. Sama umowa nie uratuje zepsutego projektu, ale daje punkt oparcia, gdy termin robi się niewygodny.

Poproś o proste zapisy dotyczące tych spraw:

klient jest właścicielem kodu custom, projektów, dokumentacji, danych i elementów deploymentu po opłaceniu pracy
repozytoria, projekty cloud, domeny, konta app store i analytics powinny być tam, gdzie to możliwe, pod kontrolą klienta
vendor musi na żądanie przekazać aktualne instrukcje builda, deploymentu, backupu i restore
vendor musi zapewnić okres transition support, zwykle od 2 do 6 tygodni zależnie od rozmiaru produktu
vendor musi usunąć albo zwrócić dane klienta, backupy, screenshoty i eksporty po ustalonym czasie retencji
vendor nie powinien blokować transferu z powodu pobocznego sporu handlowego, chyba że umowa wyraźnie dopuszcza wstrzymanie usług

Pisz to nudnym językiem. Nie próbujesz przewidzieć każdego konfliktu. Chcesz, żeby podstawy nie były negocjowane w najgorszym tygodniu współpracy.

Trzymaj kod i infrastrukturę pod kontrolą klienta

Najdroższe problemy przy wyjściu od vendora zwykle zaczynają się od własności. Agencja założyła organizację GitHub. Konto cloud używa billing profile agencji. Apple Developer account jest przypięty do kontraktora. DNS leży u kogoś, kto odszedł dwa lata temu.

Napraw to, gdy wszyscy jeszcze współpracują.

Używaj organizacji GitHub, GitLab albo Bitbucket kontrolowanej przez klienta. Konta cloud powinny być po stronie firmy klienta. Vendor dostaje imienne dostępy z właściwymi uprawnieniami, ale nie własność. Awaryjne credentiale trzymaj w password managerze albo vault kontrolowanym przez klienta.

Na starcie może to wyglądać na dodatkowy ciężar. Jest tańsze niż odkrycie podczas handoveru, że produkcja zależy od prywatnego konta, którego nie możesz audytować.

Zbuduj transition pack, zanim będzie potrzebny

Transition pack to plan wyjścia w wersji roboczej. Powinien wystarczyć, żeby nowy engineer zrozumiał, jak działa produkt, bez tygodnia archeologii.

Nie musi być ładny. Musi być aktualny.

Uwzględnij:

mapę repozytoriów: serwisy, aplikacje, skrypty, infrastructure code, archiwalne repo i właściciele
local setup: wersje runtime, package managers, zmienne środowiskowe, seed data i typowe problemy z uruchomieniem
release guide: branche, akceptacje, joby CI, komendy deploymentu, rollback i zasady hotfixów
notatki operacyjne: joby cykliczne, ręczne zadania admina, monitoring, alerty, inboxy supportu i ścieżki eskalacji
notatki o danych: główne encje, eksporty, backupy, testy restore, ograniczenia prywatności i usuwanie danych
lista ryzyk: kruche moduły, słabe testy, dług techniczny, stare zależności i skróty specyficzne dla vendora

Aktualizuj taki pakiet co najmniej raz na kwartał albo przed każdym odnowieniem umowy. Nieaktualny transition pack bywa gorszy niż brak dokumentacji, bo nowy zespół ufa złym instrukcjom.

Zaplanuj timeline wyjścia od software vendora

Spokojne wyjście zwykle potrzebuje 30 do 60 dni. Da się szybciej, ale wtedy tniesz zakres, nie ryzyko.

Dla wielu produktów custom software wystarcza prosty rytm:

Tydzień 1: potwierdź własność, zamroź ryzykowne prace roadmapowe, zbierz dostępy, wyeksportuj dokumentację i zaplanuj technical walkthroughs.

Tydzień 2: uruchom produkt lokalnie, zmapuj integracje, przejrzyj deployment, przetestuj backupy i wypisz pilne ryzyka operacyjne.

Tydzień 3: obróć sekrety, przenieś konta third party, domknij luki w CI/CD i zrób release na staging prowadzony przez nowy zespół.

Tydzień 4: wyślij małą zmianę na produkcję, potwierdź monitoring, ustal odpowiedzialność za support i zamknij backlog transition.

Przy większych systemach dodaj tygodnie na migrację danych, security review, komunikację z klientami i równoległy support. Nie wydłużaj handoveru dla komfortu. Wydłużaj go tylko wtedy, gdy jest konkretne ryzyko do spalenia.

Nie zapomnij o danych, backupach i logach

Dane robią z wyjścia temat wrażliwy. Odchodzący vendor może mieć dumpy baz, kopie staging, eksporty logów, załączniki supportowe, pliki analytics i screenshoty w starych ticketach.

Zapisz, co istnieje i co ma się z tym stać.

Dla każdego zbioru danych określ właściciela, lokalizację, zasadę retencji, format eksportu, datę usunięcia i wymagany dowód. Jeśli dane produkcyjne skopiowano na staging, zdecyduj, czy trzeba je wyczyścić przed pracą nowego zespołu. Jeśli vendor trzyma backupy przez ograniczony czas, poproś o potwierdzenie okna retencji na piśmie.

Przetestuj też restore przed odejściem starego zespołu. Ścieżka backupu, której nikt nie sprawdził, nie jest planem odzyskania. To folder z optymistyczną nazwą.

Przetestuj exit plan małym releasem

Jedynym uczciwym testem jest release. Nie slajdy, nie przekazanie repozytorium, nie rozmowa, w której wszyscy mówią, że dostęp powinien działać.

Przed wyjściem vendora poproś nowy albo wewnętrzny zespół o wysłanie małej zmiany: copy, linia logowania, cleanup feature flag albo drobna poprawka w panelu admina. Odchodzący vendor obserwuje i odpowiada na pytania. Nowy zespół prowadzi.

Podczas tego release sprawdź, czy:

CI startuje z czystej gałęzi
właściwe osoby czytają sekrety bez kont współdzielonych
migracje i rollback są zrozumiałe
monitoring pokazuje deployment
support wie, co się zmieniło
ktoś potrafi powiedzieć, co zrobić, gdy deploy się wysypie

Jeśli ten testowy release jest trudny, exit plan właśnie wykonał swoją robotę. Napraw te luki przed końcem umowy.

Czerwone flagi w software vendor exit plan

Niektóre sygnały warto wyjaśnić, zanim podpiszesz kolejne odnowienie.

vendor mówi, że dokumentacja powstanie dopiero po wypowiedzeniu
dostęp do produkcji jest związany z prywatnymi kontami albo wspólnymi hasłami
klient nie jest właścicielem repozytoriów, domen, kont cloud ani app store
vendor nie potrafi pokazać niedawnego testu restore
kroki release istnieją tylko w głowie jednego developera
nie ma listy usług third party, kluczy API ani jobów cyklicznych
umowa mówi, że vendor posiada komponenty wielokrotnego użytku, ale nie definiuje, co to znaczy
vendor blokuje mały testowy release prowadzony przez inny zespół

Jedna albo dwie czerwone flagi mogą być do naprawy. Cała grupa oznacza, że plan wyjścia powinien stać się częścią szerszego technical due diligence.

Software vendor exit plan FAQ

Czym jest software vendor exit plan?

Software vendor exit plan to praktyczny plan przeniesienia kodu, dostępów, danych, dokumentacji, release i odpowiedzialności za support od jednego dostawcy software bez przerywania działania produktu.

Kiedy stworzyć software vendor exit plan?

Najlepiej przed startem projektu albo w zdrowym momencie współpracy. Jeśli czekasz do wypowiedzenia, możesz mieć mniej współpracy ze strony vendora i mniej czasu na naprawę luk własności.

Co powinno wejść do vendor exit plan dla custom software?

Uwzględnij własność kodu, dostęp do repozytoriów, własność cloud i domen, CI/CD, kroki deploymentu, rollback, backupy, retencję danych, konta third party, dokumentację, znane ryzyka i transition support.

Ile trwa wyjście od software vendora?

Małe produkty często potrzebują około 30 dni. Większe systemy z wieloma integracjami, problemami danych albo słabą dokumentacją mogą wymagać 60 do 90 dni. Wyjście jest krótsze, gdy własność i dokumentacja są uporządkowane wcześniej.

Kto powinien być właścicielem kont cloud i repozytoriów?

Klient powinien być właścicielem głównych organizacji dla repozytoriów, cloud, domen, app store, analytics i billing. Vendorzy powinni mieć imienne dostępy z ograniczonymi uprawnieniami, nie stałą własność.

Potrzebujesz czystego wyjścia od software vendora?

Syntanea pomaga firmom audytować custom software, przygotowywać transition packi i przejmować produkty bez zamiany handoveru w pożar. Jeśli planujesz zmianę vendora albo chcesz mieć pewność, że możesz odejść bezpiecznie później, porozmawiajmy, zanim umowa zrobi się napięta.