Jak bezpiecznie zmienić dostawcę IT i przejąć istniejący projekt?

Krótka odpowiedź: bezpieczna zmiana dostawcy IT to nie „podpiszcie umowę z kimś nowym i jutro robią sprinty”. To kontrolowany handover: dostępy → ocena ryzyk → cutover odpowiedzialności → stabilizacja → dopiero rozwój. Poniżej checklista i typowe błędy przy przejmowaniu kodu od poprzedniego wykonawcy.

Przejęcie projektu od innego wykonawcy

Bezpieczny handover, stabilizacja produkcji i powrót do przewidywalnego tempa delivery — gdy poprzedni vendor nie dowozi.

Zobacz ścieżkę przejęcia

Kiedy zmiana dostawcy ma sens?

Typowe triggery z rozmów z klientami:

• poprzedni software house nie dowozi tempa (małe zmiany trwają tygodnie),
• na produkcji brakuje właściciela awarii,
• komunikacja jest „miła”, ale brakuje przewidywalnych release’ów,
• kończy się kontrakt i chcecie uporządkowany exit,
• zespół in-house nie ogarnia spadku po vendorze.

Zmiana dostawcy nie rozwiązuje sama z siebie długu technicznego. Rozwiązuje odpowiedzialność, tempo i komunikację — a dług adresujecie osobno (utrzymanie, audyt, modernizacja).

Złota zasada: najpierw kontrola, potem obietnice

Najczęstszy błąd: nowy partner obiecuje roadmapę feature’ów, zanim umie zbudować i wdrożyć obecną wersję.

Bezpieczna kolejność:

1. Inwentaryzacja dostępów
2. Wejście techniczne (build, CI, środowiska)
3. Cutover — jasna data, kto bierze dyżur
4. Stabilizacja (monitoring, hotfixy, runbooki)
5. Rozwój w przewidywalnym rytmie
6. Opcjonalnie: pełny audyt kodu albo SLA

Checklista dostępów przed zmianą dostawcy

Zróbcie listę zanim wypowiecie umowę poprzedniemu wykonawcy (albo w okresie wypowiedzenia). Dla każdego punktu: kto ma dostęp dziś, kto ma mieć po cutoverze, czy da się zresetować sekrety.

Kod i jakość

• repozytoria (GitHub / GitLab / Bitbucket),
• historia branchy i reguły review,
• dostęp do package registries (npm, Maven, CocoaPods…),
• dokumentacja (nawet niepełna — lepiej coś niż nic).

Budowanie i wdrożenia

• CI/CD (pipeline’y, self-hosted runner’y, sekrety w CI),
• środowiska: dev / staging / prod,
• sposób deployu (automatyczny vs „Kuba klika na serwerze”),
• możliwość rollbacku.

Chmura i infrastruktura

• konta AWS / GCP / Azure (lub hosting),
• IAM / użytkownicy / klucze API,
• domeny i DNS,
• certyfikaty TLS,
• bazy, buckety, kolejki, CDN,
• backupy i test przywracania (choćby „czy w ogóle są”).

Aplikacje mobilne

• konta Apple Developer / Google Play,
• dostęp do App Store Connect / Play Console,
• certyfikaty podpisujące, provisioning,
• Firebase / crashlytics / push.

Operacje i wiedza

• monitoring i alerty (kto dostaje maile o 3:00?),
• kanał zgłoszeń od supportu / klientów,
• lista integracji zewnętrznych (płatności, ERP, SMS, mapy),
• osoby z wiedzą „tylko w głowie” (single points of knowledge).

Jeśli połowy z tej listy nie da się domknąć — to nie blokuje zmiany dostawcy, ale musi wejść do planu i wyceny wejścia.

Plan handoveru w praktyce

Tydzień 0: decyzja i NDA

• NDA z nowym partnerem,
• shortlista systemów w zakresie przejęcia,
• ustalenie, czy poprzedni vendor jeszcze współpracuje przy exitcie.

Tydzień 1: dostęp i „czy w ogóle się buduje”

• nowy zespół klonuje repo, odpala CI, wdraża na staging,
• spis luk w dostępach,
• mapa krytycznych ścieżek (logowanie, płatność, sync, admin).

Cutover: jedna jasna data

Unikajcie szarej strefy „oba zespoły trochę odpowiadają”. W dniu cutoveru zapiszcie:

• kto robi release,
• kto reaguje na awarie,
• jak wygląda eskalacja do Was (PM / CTO),
• co robi jeszcze poprzedni vendor (jeśli cokolwiek).

30 dni po: stabilizacja, nie feature-party

Cel pierwszego miesiąca:

• przewidywalny deploy,
• monitoring na kluczowych błędach,
• domknięcie najgroźniejszych dziur,
• runbook „jak wdrożyć / jak cofnąć”,
• dopiero potem ambitniejszy backlog.

Szczegóły procesu: przejęcie projektu od innego wykonawcy.

Audyt, utrzymanie, przejęcie — co wybrać?

Sytuacja	Sensowny start
Vendor nie dowozi tempa, potrzebujecie nowego ownera	Przejęcie projektu
Boicie się jakości kodu / idziecie do inwestora	Audyt, potem decyzja
Macie już kontrolę, potrzebujecie dyżuru i poprawek	Utrzymanie ze SLA
System blokuje każdą zmianę	Audyt → plan modernizacji

To nie są konkurencyjne oferty — to etapy. Często: przejęcie → 30 dni stabilizacji → SLA + rozwój; pełny audyt tylko gdy trzeba większej decyzji.

Więcej o kosztach opieki i diagnozy: ile kosztuje utrzymanie lub audyt aplikacji.

Czego unikać przy zmianie software house

1. „Od poniedziałku przepisujemy na nowy stack” — zanim ogarniecie deploy starego.
2. Brak cutoveru — dwa zespoły, zero właściciela awarii.
3. Wypowiedzenie bez checklisty dostępów — sekrety zostają na Slacku poprzedniego PM.
4. Ocena tylko po demo — demo nie mówi, czy CI jest zielone i czy backup działa.
5. Ukrywanie historii awarii przed nowym partnerem — oni i tak to odkryją, drożej i w gorszym momencie.
6. Liczenie, że dokumentacja „jakoś się znajdzie” — zakładajcie, że jej nie ma; wszystko powyżej to bonus.

Jak przygotować brief dla nowego dostawcy

Im mniej mgły na starcie, tym tańsze i szybsze wejście. Przydatne:

• krótki opis produktu i użytkowników,
• stack (języki, chmura, mobile),
• lista środowisk i jak dziś wdrażacie,
• top 5 problemów z poprzednim vendorrem (tempo, jakość, komunikacja, dostępność),
• co musi działać bez przerwy w pierwszych 30 dniach,
• czy możliwy jest kontakt z poprzednim zespołem przy handouverze,
• budżet na pakiet wejściowy vs dalszy retainer / sprinty.

Podsumowanie

Bezpieczna zmiana dostawcy IT to operacja na produkcji, nie tylko decyzja zakupowa:

1. Zróbcie checklistę dostępów, zanim stracicie poprzedni zespół.
2. Wejdźcie technicznie (build + deploy), zanim obieacie roadmapę.
3. Ustalcie jedną datę cutoveru i właściciela awarii.
4. Dajcie 30 dni na stabilizację.
5. Dopiero potem wróćcie do tempa feature’ów — a audyt/modernizację dokładajcie, gdy naprawdę trzeba.

Jeśli jesteście w środku takiej zmiany (albo zaraz wypowiecie umowę) — opiszcie sytuację z obecnym wykonawcą. Pomożemy ułożyć handover bez chaosu na produkcji.

Bezpieczne przejęcie projektu IT

Od inwentaryzacji dostępów po cutover, stabilizację i dalszy rozwój — gdy chcecie zmienić dostawcę bez przestoju biznesu.

Umów rozmowę o przejęciu