Zmiana firmy IT to jeden z tych momentów, w których małe błędy proceduralne kosztują naprawdę drogo. Nie dlatego, że stary dostawca jest złośliwy — czasem jest, częściej po prostu jest zajęty czym innym i nie ma powodu, żeby oddawać Twoje systemy w idealnym stanie. Dlatego przekazanie musi być zaplanowanym projektem, nie mailem „proszę o przesłanie dokumentacji do jutra".
Ten tekst nie jest o tym, jak zwolnić dostawcę. Jest o tym, co trzeba mieć w rękach, zanim on faktycznie zniknie — bo po ostatnim dniu współpracy telefon przestaje być odbierany, a hasła, o które nie zapytałeś, kosztują później po kilka tysięcy złotych każde.
Dlaczego przekazania idą źle
W umowach z dostawcami IT dla MŚP klauzula o przekazaniu praktycznie nie istnieje, albo składa się z jednego zdania w stylu „dostawca przekaże dokumentację". W praktyce oznacza to tyle, że kiedy przychodzi moment rozstania, każda strona rozumie „przekazanie" inaczej.
Stary dostawca uważa, że dostarczył Ci działający system i to Twoja rzecz go zrozumieć. Ty uważasz, że skoro płaciłeś przez trzy lata, to całość dokumentacji powinieneś dostać na tacy. Nowy dostawca ogląda się na Ciebie i pyta, czy jest schemat integracji z bankiem, bo bez niego wycena nowych zmian to strzelanie w ciemno.
Efekt: przez trzy do sześciu miesięcy nowy dostawca „poznaje środowisko", stary już nie odbiera, a Ty płacisz podwójnie — nowej firmie za rekonstrukcję wiedzy i pośrednio starej, bo bez tej wiedzy część zmian musisz odkładać.
Co realnie trzeba przejąć
W 25-osobowej firmie produkcyjnej z Wielkopolski, którą przejmowaliśmy po poprzedniej firmie IT (współpraca 4 lata, ok. 6 tys. zł/miesiąc), zrobiliśmy inwentaryzację przed rozstaniem. Wyszło 47 aktywnych dostępów, kont i zasobów, które musiały fizycznie zmienić właściciela lub hasło. Klient przed audytem szacował, że będzie ich „no może dwadzieścia". Różnica to nie jest wyjątek — to reguła.
Typowe kategorie, których nie wolno pominąć:
- Dostępy administracyjne — konto Global Admin w Microsoft 365, konto właściciela w Google Workspace, root w środowisku Linuxowym,
saw SQL Serverze, konto administratora w Comarch Optima / enova365 / Subiekcie, panele w firewallu, w NAS-ie, w UPS-ie, w drukarkach sieciowych. Każde z nich musi być odzyskane, hasło zmienione i konto właściciela wpisane na Ciebie lub Twoją nową firmę. - Domena i DNS — konto w rejestrze domen (nazwa.pl, home.pl, OVH), dostęp do panelu DNS, konfiguracje SPF/DKIM/DMARC, certyfikaty SSL i ich klucze prywatne. Jeżeli domena jest zarejestrowana na dostawcę, a nie na Ciebie — masz problem. Zmiana rejestranta trwa i wymaga jego zgody.
- Kod źródłowy i repozytoria — dostęp do repozytorium Git (GitHub, GitLab, Azure DevOps, Bitbucket) razem z historią commitów, pipeline'y CI/CD, artefakty buildów, klucze deploymentowe. Kod bez historii to połowa kodu — bez niej nie wiadomo, dlaczego coś jest jak jest.
- Klucze API, tokeny, sekrety — integracje z bankiem, kurierem, sklepem, płatnościami, systemami rządowymi (KSeF, ZUS, e-Deklaracje). Trzymane w pliku, w Vault, w konfiguracji aplikacji lub — najgorzej — w głowie jednego programisty.
- Bazy danych i backupy — dostęp do produkcyjnej bazy, do serwera backupu, do przestrzeni w chmurze (Azure, AWS, S3-compatible u OVH lub Backblaze). Do tego: klucze szyfrujące backupy. Backup, którego nie umiesz odszyfrować, jest bezwartościowy.
- Umowy z podwykonawcami — hosting, monitoring, antywirus, licencje na wtyczki i moduły, umowa z operatorem SMS-ów, umowa z dostawcą certyfikatów. Sprawdź, na kogo są wystawione faktury. Jeżeli na Twojego dostawcę — musisz przenieść umowę, zanim on ją wypowie.
Dokumentacja, której nikt nie napisał
W większości MŚP dokumentacja techniczna nie istnieje albo jest kompletnie nieaktualna. To normalne. Problem robi się dopiero wtedy, kiedy trzeba oddać system komuś, kto nie widział go od środka. Wtedy okazuje się, że jedyna „dokumentacja" to notatki w Notesie na laptopie programisty, który przechodzi do konkurencji.
Rozsądne minimum, o które warto walczyć w klauzuli przekazania, to:
- Schemat architektury — jednostronicowy diagram: co gada z czym, przez jaki protokół, w którą stronę. Nie musi być piękny, musi być prawdziwy.
- Lista integracji — bank, kurier, sklep, KSeF, Comarch, każda z opisem: co robi, gdzie leżą klucze, w jakim rytmie działa, co się dzieje przy awarii.
- Procedury operacyjne — jak wgrać nową wersję, jak zrobić restart, jak odtworzyć bazę z backupu, jak dodać nowego użytkownika.
- Rejestr zmian z ostatnich 12 miesięcy — nawet w formie listy commitów albo maili. Bez tego nowy dostawca nie ma jak zrozumieć, co i dlaczego się działo.
Naciskaj konkretnie, punkt po punkcie. „Dokumentacja techniczna" jako ogólny wymóg zostanie oddana w postaci pliku PDF ze zrzutami ekranu z konsoli.
Klauzula przekazania w umowie
Jeżeli negocjujesz nową umowę z dostawcą IT albo aneksujesz starą, dołóż dosłownie kilka zdań o wyjściu. Bez tego jesteś zdany na dobrą wolę.
- Okres przekazania — minimum 4 tygodnie po wypowiedzeniu, w tym co najmniej 2 warsztaty z nowym dostawcą.
- Zakres przekazania — wypunktowany, nie „dokumentacja". Wskaż konkretnie: dostępy, kod, klucze, dokumentacja, rejestr zmian, listy integracji.
- Własność intelektualna — kod napisany na Twoje zlecenie jest Twój, bez ograniczeń. Bez tej klauzuli w Polsce często kod pozostaje własnością wykonawcy (art. 74 ustawy o prawie autorskim — utwory pracownicze i utwory na zamówienie mają różne reżimy, warto to jasno zapisać).
- Kara umowna za niewykonanie przekazania — nie musi być duża. Nawet 5–10 tys. zł działa dyscyplinująco.
- Rate za pracę po zakończeniu umowy — jeżeli po miesiącu okaże się, że trzeba dopytać o jedną rzecz, dostawca ma prawo za to policzyć — ale stawka jest znana z góry, a nie negocjowana pod presją.
Realny harmonogram
W przywoływanej wcześniej 25-osobowej firmie produkcyjnej cały proces zajął 8 tygodni. Podzieliliśmy go tak:
- Tydzień 1–2: inwentaryzacja. Nowy dostawca robi listę wszystkich systemów, kont, integracji, umów. Stary dostawca dostaje listę i uzupełnia braki. Klient dostaje jedną tabelę z całością.
- Tydzień 3–4: przekazanie dostępów. Punkt po punkcie: każde konto zmienia właściciela lub hasło, każde jest logowane. Nic nie jest „załatwione ustnie".
- Tydzień 5–6: przekazanie wiedzy. Warsztaty (2 razy po 3 godziny) z udziałem starego i nowego dostawcy. Wszystkie pytania nowego dostawcy trafiają do dokumentu i mają dostać odpowiedź na warsztacie lub w ciągu 5 dni roboczych.
- Tydzień 7: próba samodzielności. Nowy dostawca próbuje wykonać rutynowe operacje bez pomocy starego. Wychodzą braki — wracamy do punktu 3.
- Tydzień 8: formalne zamknięcie. Podpisany protokół przekazania z listą tego, co zostało przekazane. Bez podpisu nie płacimy ostatniej faktury.
Klient zaoszczędził szacunkowo 4–5 miesięcy „poznawania środowiska" przez nową firmę — a to w kosztach usługi IT jest 25–30 tys. zł, które nie zostały wydane na rekonstrukcję wiedzy, tylko na realne zmiany.
Co dalej
Jeżeli akurat rozważasz zmianę dostawcy IT albo już podjąłeś decyzję, zacznij od jednej rzeczy: zrób listę wszystkich systemów, kont i integracji w firmie. Nawet niepełna lista pokaże Ci skalę i pozwoli zaplanować rozmowę z obiema stronami — starą i nową — na konkretach, a nie na obietnicach.
Jeżeli chcesz spojrzenia z zewnątrz na to, co realnie musisz przejąć i jak zapisać to w umowie, żeby przekazanie odbyło się bez zakładników — pomagamy MŚP przeprowadzać takie audyty i sam proces przejęcia. Pierwsza rozmowa jest bezpłatna i trwa pół godziny.
Dostawca IT, który wychodzi na dobrych warunkach, oddaje klucze. Dostawca, który wychodzi na złych, oddaje wymówki.