서비스에 의존하기 전에 종료와 전환 검증하기

무엇을 계속 사용할 수 있어야 하는지 정하세요

소스 코드 소유권은 가치가 있습니다. 하지만 서비스 종료 및 전환 계획의 한 부분일 뿐입니다.

소스가 회사 저장소에 있는 가상의 애플리케이션을 생각해 보세요. 빌드는 공급업체의 비공개 패키지를 다운로드합니다. 프로덕션은 공급업체 소유의 클라우드 계정을 사용합니다. 데이터베이스 복원 절차는 아무도 기록하지 않았습니다.

회사는 코드를 갖고 있지만 아직 서비스를 독립적으로 운영할 수 없습니다. 전환 계획은 권리, 자산, 접근, 지식을 함께 다뤄야 합니다.

의존성 목록을 만드세요

내보내기 형식과 범위를 확인하세요. 읽을 수 있는 문서 내보내기가 모든 관계, 첨부 파일, 실행 기록까지 보존하는 것은 아닙니다. 예시를 요청하고 실제로 사용할 사람들과 살펴보세요.

독립적으로 다시 빌드하세요

안전한 테스트 환경과 승인된 예시 데이터를 사용하세요. 권한 있는 엔지니어에게 제안된 인계 자료를 제공하세요. 애플리케이션 빌드, 구성 적용, 데이터 복원, 완전한 비즈니스 작업 하나의 검증을 요청하세요.

누락된 항목과 확보하는 데 걸린 시간을 기록하세요. 훈련 중 문서화되지 않은 지식을 조용히 제공하지 마세요. 목적은 다음 팀에 무엇이 부족할지 찾는 것입니다.

그런 다음 전환 제약을 살펴보세요. 구독 기간 중복, 데이터 전송 시간, 패키지 접근, ID 변경, 지원 가능 여부 등이 있습니다. 이 비용을 직접 구축과 구매 비교에 포함하세요.

내보내기와 삭제를 구분하세요

내보내기는 사본을 만듭니다. 전환은 서비스 운영 주체를 바꿉니다. 삭제는 합의한 프로세스에 따라 지정한 기록을 제거합니다. 서로 다른 증거가 필요한 별개의 결정입니다.

관련 담당자와 필요한 보존 및 삭제 범위를 정하세요. 공급업체의 현재 약관과 절차를 확인하세요. 인수할 시스템을 검증하기 전에 유일하게 사용 가능한 복구 사본을 삭제하지 마세요.

Taiga는 관리자 내보내기 프로세스와 별도의 삭제 프로세스를 문서화합니다. 비밀 정보의 값은 내보내기에서 제외됩니다. 따라서 인계에는 필요한 비밀 정보를 다시 만들 수 있는 허가된 방법이 필요합니다. 현재 내보내기 내용을 전환 요구와 대조해 검증하세요. 완전한 애플리케이션 백업이라고 가정하지 마세요.

수용 가능한 의존성을 결정하세요

이식성을 위해 모든 관리형 서비스를 제거할 필요는 없습니다. 가치, 제약, 전환 경로를 이해한다면 의존성도 합리적인 선택일 수 있습니다.

수락한 의존성, 담당자, 검토 계기를 기록하세요. 중요한 아키텍처 또는 계약 변경 후에는 전환 훈련을 반복하세요. 처음부터 이 책임을 포함하는 도입 계획으로 이어 가세요.