Checklista przejęcia aplikacji od wykonawcy

Kto zatwierdza zakres, dostęp i priorytety po przejęciu.

Co nie może przestać działać podczas zmiany wykonawcy.

Od czego ma zacząć nowy wykonawca po rozpoznaniu sytuacji.

Kiedy można wdrażać poprawki, a kiedy system musi pozostać bez zmian.

Kto jest właścicielem konta i może zmienić ustawienia domeny. Bez podawania hasła.

Kto kontroluje usługę, płatności i możliwość nadawania dostępu.

Czy firma ma dostęp właścicielski albo może go uzyskać od obecnego wykonawcy.

Kto kontroluje pocztę, płatności, SMS, analitykę i pozostałe usługi używane przez aplikację.

Czy repozytorium odpowiada wersji działającej na serwerze.

Czy istnieje instrukcja, wymagania środowiska albo osoba potrafiąca je wyjaśnić.

Czy wiadomo, które środowisko jest produkcyjne, testowe lub deweloperskie.

Czy wiadomo, jak zmiany trafiają na serwer i jak wrócić po nieudanym wdrożeniu.

Czy są znane płatne biblioteki, moduły, konta oraz ograniczenia licencyjne.

Kto administruje bazą i może przygotować bezpieczny sposób dostępu do uzgodnionego zakresu.

Czy wiadomo, co jest kopiowane, gdzie i kto odpowiada za próbę odtworzenia.

Z jakimi systemami aplikacja wymienia dane i kto zna te połączenia.

Czy aplikacja wykonuje cykliczne importy, wysyłki, kolejki lub inne prace poza widocznym interfejsem.

Jakie kategorie danych przetwarza aplikacja i które role powinny mieć do nich dostęp. Bez wpisywania samych danych.

Kto obecnie otrzymuje informację o błędach i niedostępności.

Które problemy są znane firmie i jak dziś radzą sobie z nimi użytkownicy.

Co jest niedokończone, zamówione albo uzgodnione z obecnym wykonawcą.

Kto zna system, infrastrukturę, dane i proces biznesowy. Wystarczą role, bez danych osobowych.

Kto zatwierdzi dostęp nowego wykonawcy i zamknie zbędne uprawnienia po zakończeniu przekazania.