서버 이전은 지금 돌아가고 있는 서비스를 다른 서버나 다른 클라우드로 옮기는 작업이에요. 옮기는 대상이 물리 서버에서 클라우드로 바뀌면 클라우드 마이그레이션이라고 부르고, 시스템은 그대로 두고 관리 주체만 다른 회사로 넘기면 운영 이관이라고 불러요. 세 가지 모두 새 기능을 만드는 일이 아니라 이미 돈을 벌고 있는 시스템을 멈췄다가 다시 켜는 일이라서, 발주자가 확인해야 할 항목이 신규 개발과 완전히 다릅니다.
이 글은 이전을 어떻게 수행하는지가 아니라, 비개발자 발주자가 이전을 외주로 맡길 때 무엇을 요구하고 무엇을 확인해야 하는지를 정리한 글이에요. 기술 절차는 개발사가 압니다. 발주자가 챙겨야 하는 건 다운타임 합의, 롤백 조건, 데이터 검증 기준, 계정 명의, 그리고 이전 이후의 대응 책임입니다.
발주자와 개발사가 같은 단어를 다르게 이해하는 지점이 여기예요. 발주자 입장에서는 "우리 서비스를 새 서버로 옮긴다"가 하나의 덩어리로 보이는데, 실제로 옮겨야 하는 것은 최소 다섯 덩어리로 나뉩니다.
견적을 받을 때 이 다섯 덩어리 중 무엇이 견적에 포함됐는지 따로 물어보세요. 특히 견적서에 파일 저장소와 외부 서비스 키가 적혀 있지 않다면 포함 여부를 서면으로 확인하세요. 적히지 않은 항목은 이전 당일에야 드러납니다. 견적서를 항목 단위로 뜯어보는 방법은 IT 외주 개발 견적서 완전 분석 가이드에 정리해 뒀습니다.
신규 개발은 실패해도 아직 세상에 없던 기능이 조금 늦게 나오는 것으로 끝나요. 이전은 다릅니다. 실패하면 이미 잘 돌아가던 서비스가 멈추고, 고객은 어제까지 되던 것이 오늘 안 되는 상황을 겪어요. 같은 규모의 예산을 써도 실패 비용의 성격이 완전히 달라집니다.
위험이 커지는 이유는 세 가지예요. 첫째, 성공 기준이 "새 기능이 동작한다"가 아니라 "이전과 똑같이 동작한다"입니다. 똑같은지 확인하려면 원래 어떻게 동작했는지를 알아야 하는데, 오래된 시스템일수록 그 기록이 없어요. 둘째, 작업 시점이 서비스 운영 중이라 되돌릴 시간이 짧습니다. 셋째, 문제가 이전 당일이 아니라 며칠 뒤 배치 작업이나 월말 정산에서 처음 드러나는 경우가 있어요.
그래서 이전 프로젝트의 계약은 신규 개발 계약을 그대로 쓰면 안 됩니다. 신규 개발 계약은 "무엇을 만든다"를 정의하는 문서이고, 이전 계약은 "무엇이 깨지면 누가 어떻게 되돌린다"를 정의하는 문서여야 해요.
세 단어가 미팅에서 섞여 쓰이는데, 계약에서는 갈라야 합니다. 무엇이 바뀌는지에 따라 확인할 항목이 달라져요.
| 구분 | 무엇이 바뀌나 | 발주자가 특히 확인할 것 |
|---|---|---|
| 서버 이전 | 서버는 바뀌고 코드와 운영 주체는 그대로 | 다운타임 창, 데이터 정합성, 구 서버 유지 기간 |
| 클라우드 마이그레이션 | 서버와 함께 인프라 구성 방식이 바뀜 | 계정 명의, 월 고정비 변화, 관리형 서비스 종속 |
| 운영 이관 | 시스템은 그대로, 관리하는 회사가 바뀜 | 계정 권한 회수, 문서와 런북, 장애 대응 책임 시점 |
| 이전 + 리팩터링 | 옮기면서 구조나 버전도 함께 손봄 | 범위 분리, 검증 기준 이원화, 롤백 가능 여부 |
특히 위험한 조합은 마지막 줄이에요. 옮기는 김에 낡은 프레임워크 버전도 올리고 구조도 정리하자는 제안은 합리적으로 들리지만, 문제가 생겼을 때 이전 때문인지 리팩터링 때문인지 구분할 수 없게 됩니다. 되돌릴 지점도 사라져요. 두 가지를 한 계약에 넣더라도 일정과 검수는 분리해서 받으세요.
운영 이관은 개발사를 바꾸는 상황과 겹치기도 해요. 그 맥락에서 챙길 것은 외주 개발사 교체·중도 해지 완전 가이드에 따로 정리돼 있습니다.
인수인계는 개발사가 떠나면서 자산과 권한을 넘기는 절차예요. 이전은 시스템을 실제로 옮기는 별도의 프로젝트입니다. 둘은 자주 붙어서 일어나지만 같은 일이 아니에요.
구분이 중요한 이유는 견적과 책임 때문이에요. 인수인계 범위는 개별 계약서의 종료·인계 조항에 무엇이 적혀 있는지가 먼저입니다. 계약서에 인계 의무가 없으면 무상 마무리가 아니라 별도 발주예요. 이전은 그와 별개로 새로 발주하는 작업이라 별도 견적과 별도 검수 기준이 필요합니다. 기존 개발사가 "인계해 드리면서 서버도 옮겨 드릴게요"라고 말할 때, 그 말이 계약서상 마무리 의무인지 유상 프로젝트인지 먼저 확정하세요.
넘겨받아야 할 자산 목록 자체는 이미 정리된 글로 대신합니다. IT 외주 개발 인수인계 완전 가이드를 보세요. 이 글은 그다음, 즉 옮기는 행위 자체의 리스크와 계약을 다룹니다.
이전 견적을 제대로 받으려면 현재 상태를 적은 문서가 먼저 있어야 해요. 이 문서가 없으면 개발사는 위험을 견적에 얹거나, 얹지 않고 들어왔다가 중간에 추가 비용을 요구합니다. 둘 다 발주자에게 불리해요.
발주자가 직접 만들 수 있는 최소한의 조사 문서는 다음 항목이에요. 기술 지식 없이도 현재 개발사나 운영자에게 물어서 채울 수 있습니다.
이 중에서 6번과 7번은 이전 방식 자체를 바꾸는 항목이에요. 백업 복원을 한 번도 해본 적이 없는 시스템이라면, 이전 계획보다 복원 테스트가 먼저입니다. 백업이 있다는 사실과 그 백업으로 서비스를 되살릴 수 있다는 사실은 다르고, 이 둘의 차이는 백업·복구·재해대응 가이드에서 더 자세히 다뤘어요.
이전 프로젝트에서 순서를 잘못 잡으면 되돌리기 어려운 항목 중 하나가 계정 명의예요. 클라우드 계정, 도메인 등록 계정, 앱스토어 계정, 결제 대행사 계정이 개발사 명의로 남아 있으면 새 환경을 만드는 권한도 옛 환경을 지우는 권한도 전부 개발사에 있습니다. 개발사가 폐업하거나 담당자가 퇴사하면 명의 이전 자체가 어려워지는 경우도 있어요.
그래서 이 글에서 못 박을 것은 순서 하나입니다. 발주자 명의로 계정을 먼저 만들고, 그 계정 안에 새 환경을 구축하게 하세요. 계약서에는 "모든 인프라 자산은 발주자 명의 계정에 생성한다"는 문장을 넣습니다. 이 한 줄이 빠진 채 진행하면 이전이 끝난 뒤에도 소유 관계는 그대로예요.
이미 개발사 명의로 돼 있는 계정을 넘겨받는 절차와, 프로젝트가 끝난 뒤 회수해야 할 권한 목록은 클라우드·인프라 인계 완전 가이드에 있어요. 이 글이 다루는 건 그 정리를 이전 착수 전에 끝내야 하는 이유입니다. 이전이 시작된 뒤에는 명의가 곧 작업 권한이라, 순서를 되돌리기 어려워요.
개발사가 제안하는 방식은 이름과 조합이 다양한데, 이 글에서는 발주자가 판단하기 쉬운 세 가지를 놓고 정리합니다. 무엇을 고르느냐는 기술 취향이 아니라 발주자가 감당할 수 있는 정지 시간이 결정해요.
| 방식 | 한 줄 요약 | 감당해야 하는 것 | 맞는 상황 |
|---|---|---|---|
| 정지 후 통째 이전 | 멈추고 옮긴 뒤 켠다 | 정지 시간 동안 매출과 문의가 멈춤 | 야간에 트래픽이 사실상 없는 서비스 |
| 동기화 후 전환 | 미리 띄워 두고 따라 붙인 뒤 전환한다 | 준비 기간과 비용이 늘어남 | 24시간 주문이나 예약이 들어오는 서비스 |
| 단계적 이전 | 나눠서 순차 전환한다 | 두 환경을 동시에 운영하는 기간이 생김 | 기능이 여러 덩어리로 나뉜 큰 시스템 |
방식별 실행 절차는 데이터·DB 인계 완전 가이드의 D-Day 항목에 있고, 이 표는 발주자가 어떤 제약을 먼저 던져야 그 방식이 결정되는지를 보는 용도예요.
발주자가 할 일은 방식을 고르는 게 아니라 제약을 먼저 주는 것이에요. "우리는 정지를 몇 시까지, 몇 시간까지 감당할 수 있다"를 먼저 말하면 개발사가 그에 맞는 방식을 제안합니다. 반대로 방식을 먼저 정해두고 시작하면, 감당 못 할 정지 시간이 이전 당일에 드러나요.
다운타임 합의에서 발주자가 자주 놓치는 건 시간의 길이가 아니라 판단 기준이에요. "새벽에 두 시간 정도면 됩니다"라는 말에는 시작 시각, 초과했을 때의 처리, 실패 선언 시점이 전부 빠져 있습니다. 아래 네 가지를 문서로 남기세요.
| 합의 항목 | 정하지 않으면 생기는 일 | 문서에 적을 형태 |
|---|---|---|
| 작업 창 | 이전이 영업시간까지 이어짐 | 시작 시각과 종료 예정 시각을 날짜와 함께 명시 |
| 허용 정지 시간 | 길어져도 아무도 중단시키지 못함 | 서비스 중단 상태로 허용하는 최대 시간 |
| 중단 판단 시점 | 새벽에 연락이 안 되는 사람을 기다림 | 몇 시까지 전환이 안 되면 롤백을 시작한다 |
| 판단 권한자 | 개발사와 발주자가 서로 결정을 미룸 | 롤백을 선언할 사람과 대체 연락처 |
중단 판단 시점을 미리 못 박는 것이 이 표의 핵심이에요. 이전 당일 새벽에 "조금만 더 하면 될 것 같다"는 판단이 반복되면서 정지가 늘어나는 상황이 반복적으로 관찰됩니다. 사람이 그 순간에 냉정하기 어려우니, 냉정할 때 미리 시각을 정해 두는 것이 현실적인 방어예요.
고객 공지도 함께 정하세요. 언제, 어디에(앱 내 공지, 문자, 홈페이지 배너) 올릴지와 문구를 이전 전에 만들어 두면, 정지가 길어져도 문의 폭주를 줄일 수 있어요. 공지 담당은 개발사가 아니라 발주자 쪽입니다.
롤백은 새 환경에서 문제가 확인됐을 때 옛 환경으로 되돌리는 절차예요. 계획이 없으면 되돌리지 못하는 게 아니라, 되돌릴지 말지를 새벽 세 시에 즉흥으로 결정하게 됩니다. 그 상황에서는 "이미 여기까지 왔으니 앞으로 간다"는 판단이 나오기 쉬워요.
더 곤란한 경우는 롤백이 기술적으로 어려워지는 순간이에요. 새 환경에서 주문이 몇 건이라도 들어오면, 그 사이 쌓인 주문을 옛 환경으로 옮겨 오는 절차를 따로 합의해 두지 않는 한 롤백과 함께 그 주문이 사라집니다. 즉 롤백에는 유효 기간이 있고, 그 기간은 새 환경이 실제 트래픽을 받기 시작하는 순간부터 짧아져요. 계약서에 이걸 적어야 합니다.
발주자가 요구할 롤백 조항은 네 문장이면 충분해요.
마지막 줄이 빠지면, 되돌리는 작업에 추가 견적이 붙어서 판단이 또 흐려져요. 되돌리는 비용이 무료여야 담당자가 제때 되돌립니다.
"이전 완료했습니다"라는 말과 "데이터가 맞습니다"는 다른 문장이에요. 발주자가 눈으로 확인할 수 있는 검증 기준을 미리 정해 두지 않으면, 검수는 화면 몇 개를 열어보는 것으로 끝납니다. 문제는 그때 안 보이고 며칠 뒤 정산에서 보여요.
| 검증 항목 | 무엇을 대조하나 | 누가 확인하나 |
|---|---|---|
| 건수 대조 | 주요 테이블의 행 수가 이전 전후로 같은가 | 개발사가 수치 제출, 발주자가 확인 |
| 금액 합계 | 결제·정산 금액의 합계가 일치하는가 | 발주자 재무 담당 |
| 최근 데이터 샘플 | 직전 며칠 치 주문과 회원 정보가 그대로인가 | 발주자 운영 담당 |
| 첨부 파일 | 이미지와 파일이 실제로 열리는가 | 발주자 운영 담당 |
| 번호 이어짐 | 주문번호 같은 순번이 겹치거나 되돌아가지 않는가 | 개발사 |
| 정해진 시각 작업 | 배치와 알림이 새 환경에서 실제로 돌았는가 | 개발사, 다음 실행 시각 이후 |
이 표는 발주자가 눈으로 대조할 항목이고, 스키마 동결·마이그레이션 히스토리·삭제 인증서처럼 데이터베이스 쪽에서 밟아야 하는 절차는 데이터·DB 인계 완전 가이드에 있어요. 옮기는 대상이 DB 하나가 아니라 서버와 인프라 전체라면 이 글의 순서를 따르고, DB 인계 절차 자체가 필요하면 그 글을 보세요.
표에서 발주자가 반드시 직접 해야 할 항목은 금액 합계와 최근 데이터 샘플이에요. 개발사는 시스템이 정상인지를 보고, 발주자는 장부가 맞는지를 봅니다. 두 시선이 다르기 때문에 한쪽만으로는 부족해요. 결제와 정산이 얽힌 시스템이라면 결제·정산 시스템 인계 가이드의 대조 항목을 같이 쓰면 됩니다.
마지막 줄, 정해진 시각에 도는 작업은 이전 당일에 확인할 수 없는 항목이에요. 그래서 검수 완료 시점을 이전 당일이 아니라 배치가 한 번 돌고 난 뒤로 잡아야 합니다. 검수와 잔금의 관계는 산출물 검수·사인오프 가이드에 정리돼 있어요.
서버를 다 옮겨놓고도 사용자가 여전히 옛 서버로 들어가는 일이 생겨요. 도메인이 어느 서버를 가리킬지 정하는 DNS 설정은 전 세계 여러 곳에 잠시 저장되기 때문에, 바꿔도 즉시 모두에게 반영되지 않습니다. 이 지연 시간을 TTL이라고 불러요.
발주자가 요구할 것은 두 가지예요. 하나는 현재 TTL이 몇 초로 설정돼 있고 이전 며칠 전에 얼마로 낮출 것인지를 개발사에 숫자로 받아 두는 것이고, 다른 하나는 전환 후에도 옛 서버를 살려둔 채 그쪽으로 들어오는 요청을 새 서버로 넘겨 달라는 것입니다. 이렇게 하면 늦게 반영된 사용자도 서비스를 정상적으로 쓸 수 있어요.
인증서도 함께 챙깁니다. 주소창의 자물쇠를 만드는 SSL 인증서가 새 서버에 제대로 설치되지 않으면 브라우저가 경고 화면을 띄우고, 사용자는 서비스가 해킹당했다고 생각해요. 자동 갱신 설정이 새 환경으로 따라왔는지도 확인 대상입니다. 인증서 만료는 이전 당일이 아니라 몇 달 뒤에 조용히 터지는 항목이라 인수 문서에 갱신 방법을 적어두게 하세요.
메일도 잊기 쉬워요. 도메인으로 발송하는 안내 메일과 인증 메일은 발송 서버가 바뀌면 스팸으로 분류될 수 있습니다. 회원가입 인증 메일이 안 가는 문제가 이전 며칠 뒤에 드러나는 경우가 있으니, 이전 후 확인 목록에 실제 메일 수신 테스트를 넣으세요.
서버 주소가 바뀌면 그 주소를 알고 있던 외부 서비스들이 새 주소를 모릅니다. 이전 당일에 서비스는 멀쩡해 보이는데 결제만 안 되거나, 알림만 안 오는 상황이 여기서 나와요. 아래 네 가지는 연동을 새로 만들 때의 관점이 아니라 이미 붙어 있는 연동이 이전 때 어디서 깨지는가로 읽으세요.
발주자는 이 목록을 개발사에 던지고 연동처별 담당 창구와 처리 소요를 표로 받아 두세요. 외부 업체가 개입하는 항목은 우리 일정으로 통제되지 않아요. 복원 테스트나 TTL 인하와 마찬가지로, 이전 당일이 아니라 앞당겨 시작해야 하는 구간입니다. 키 관리와 노출 대응은 보안 점검·취약점 대응 가이드에서 다룹니다.
이전 당일 계획서는 작업 순서가 아니라 판단 지점이 적혀 있어야 쓸모가 있어요. 발주자가 받아야 할 문서는 아래 형태입니다. 시각은 실제 일정에 맞춰 채우면 돼요.
| 단계 | 하는 일 | 통과 조건 | 실패하면 |
|---|---|---|---|
| 사전 점검 | 새 환경 준비 상태와 백업 확인 | 백업 파일로 복원이 되는 것을 확인 | 이전 자체를 연기 |
| 서비스 정지 | 공지 노출, 신규 요청 차단 | 정해진 시각에 공지가 실제로 보임 | 공지부터 다시 |
| 데이터 이전 | 데이터와 파일 옮기기 | 건수·합계 대조 통과 | 롤백 |
| 전환 | 도메인이 새 서버를 가리키게 변경 | 주요 화면과 결제 한 건이 성공 | 롤백 |
| 개시 확인 | 실제 사용자 유입 확인 | 오류 급증이 없음 | 중단 판단자 호출 |
| 안정화 | 모니터링과 대기 | 다음 배치가 정상 실행 | 대응 개시 |
이 표에서 발주자 몫은 통과 조건 열이에요. 무엇을 봐야 통과인지는 사업을 아는 사람이 정해야 합니다. 개발사는 오류 로그를 보고 판단하는데, 발주자에게 중요한 건 주문이 실제로 들어오는가예요. 두 기준이 다르기 때문에 표에 둘 다 적습니다.
새 환경의 이상 징후를 볼 수 있는 화면이 없다면 그것도 이전 범위에 넣으세요. 무엇을 보고 정상이라 판단할지 정하는 문제는 모니터링 외주 개발 인계 가이드에 정리했어요.
이전 프로젝트의 계약이 전환 완료로 끝나면 안 되는 이유가 여기 있어요. 이전으로 생긴 문제가 시차를 두고 드러나는 경우가 반복적으로 관찰됩니다. 배치 작업, 월말 정산, 인증서 갱신, 메일 도달률처럼 주기가 긴 항목은 며칠에서 몇 주 뒤에 처음 실행되기 때문이에요.
그래서 계약서에는 전환 이후의 대응 구간을 따로 적습니다. 이 구간에서 이전 프로젝트가 소유하는 건 두 가지예요.
이 구간이 끝난 뒤부터는 유지보수 계약의 영역이에요. 이전 계약과 유지보수 계약이 이어지지 않으면 그 사이에 아무도 책임지지 않는 공백이 생깁니다. 유지보수 범위를 정하는 방법은 개발 유지보수 계약·비용 가이드를 참고하세요.
신규 개발 계약서에 없는데 이전 계약서에는 있어야 하는 조항들이에요. 표의 왼쪽 항목이 계약서에 없다면 가운데 열의 상황이 그대로 발주자 부담이 됩니다.
| 조항 | 없으면 생기는 일 | 넣을 문장의 방향 |
|---|---|---|
| 계정 명의 | 새 환경도 개발사 소유로 남음 | 모든 인프라 자산은 발주자 명의 계정에 생성한다 |
| 다운타임 상한 | 정지가 영업시간까지 이어짐 | 허용 정지 시간과 초과 시 조치를 명시한다 |
| 롤백 의무 | 되돌리는 작업에 추가 비용이 붙음 | 롤백 실행은 원 계약 범위에 포함한다 |
| 구 환경 유지 | 비교 대상이 사라짐 | 발주자 승인 전까지 구 환경을 삭제하지 않는다 |
| 데이터 검증 기준 | 검수가 화면 확인으로 끝남 | 대조할 항목과 통과 기준을 부속 문서로 첨부한다 |
| 안정화 대응 | 전환 다음 날부터 유상 대응 | 지정 기간의 이전 기인 장애는 무상 대응한다 |
| 자격 증명 취급 | 키가 채팅에 남음 | 인증 정보 전달 경로와 작업 후 교체를 규정한다 |
| 문서 인계 | 다음 담당자가 구조를 모름 | 새 환경 구성도와 복구 절차서를 산출물에 포함한다 |
여덟 줄 가운데 롤백 의무와 안정화 대응은 개발사 입장에서 범위가 열려 보이는 항목이라 이견이 나오기 쉬워요. 그래서 기간과 사유를 좁혀서 제시하세요. "무제한 무상 대응"이 아니라 "지정한 기간 동안, 이전으로 생긴 문제에 한해"라고 적으면 개발사 입장에서 범위가 닫히기 때문에 협의 여지가 생겨요. 반대로 발주자에게 일방적으로 불리한 문구가 들어오는 패턴은 IT 외주 개발 계약서 독소조항 완전 분석에 모아 뒀습니다.
같은 이전인데 견적이 벌어진다면, 실력 차이보다 포함 범위 차이를 먼저 의심하세요. 아래 항목들이 견적에 들어갔는지 아닌지에 따라 총액이 달라집니다.
금액 자체는 옮길 시스템의 크기와 연동 개수에 따라 크게 달라져서, 이 글에 특정 금액대를 적는 것은 의미가 없어요. 시중에 도는 이전 비용 수치들은 국내 외주 시장의 현장 견적 기준이고 공표된 통계가 아니니 그대로 기준 삼지 마세요. 대신 위 여섯 줄을 견적서에 항목으로 적어 달라고 요구하면, 총액이 아니라 구조로 비교할 수 있습니다.
월 인프라 비용의 변화도 견적과 함께 물어보세요. 클라우드로 옮기면 관리형 서비스를 쓰게 되면서 매달 나가는 고정비 구조가 바뀝니다. 이전 비용은 한 번이지만 운영비는 계속 나가니, 이전 후 예상 월 비용을 문서로 받아 두는 편이 낫습니다.
이전은 만드는 일이 아니라 되돌릴 줄 아는 일이에요. 그래서 고를 때 보는 기준도 다릅니다. 미팅에서 다음 세 질문을 던져 보세요.
세 질문 모두 기술 질문이 아니라 절차 질문이에요. 비개발자 발주자도 답의 구체성으로 판단할 수 있습니다. 답이 "문제 생기면 바로 조치하겠다" 수준이면 계획이 없다는 뜻이에요.
맡길 곳을 고를 때 저희 쪽 기준도 함께 적어 둡니다. 웹·앱 서비스의 서버 이전과 클라우드 마이그레이션, 운영 이관은 포텐랩이 맡습니다. 반면 옮기는 대상이 챗봇이나 RAG처럼 AI 자체가 제품인 시스템이라면 트리숲(TreeSoop) 쪽이 맞아요. 모델 서빙과 벡터 데이터베이스, 임베딩 재생성처럼 일반 웹 서버 이전과는 다른 검증 항목이 필요하기 때문입니다. 맞지 않는 쪽으로 보내는 것이 서로에게 손해라서, 기준을 먼저 말씀드리는 편이에요. 참고로 포텐랩은 자체 집계 기준 97% 수행완수율을 유지하고 있습니다.
이전을 여러 곳에 견적 요청할 계획이라면, 요청서에 담을 내용은 RFP 뜻과 작성법 완전 가이드의 구조를 그대로 쓰면 됩니다.
미팅 전에 이 목록만 손에 들고 가도 대화의 수준이 달라져요. 각 줄은 앞의 본문에서 근거를 다뤘습니다.
이 열세 줄 가운데 여러 항목에 "아직"이라고 답하게 된다면, 이전 일정을 잡기 전에 조사부터 하는 편이 안전해요. 이전은 준비 기간을 줄여서 얻는 이득보다 준비가 부족해서 잃는 것이 큰 종류의 프로젝트입니다.
서버 이전은 서버만 바뀌고 코드와 운영 주체는 그대로인 작업이에요. 클라우드 마이그레이션은 서버와 함께 인프라 구성 방식까지 바뀌고, 운영 이관은 시스템은 그대로 둔 채 관리하는 회사가 바뀝니다. 확인할 항목도 갈려서 서버 이전은 다운타임 창과 구 서버 유지 기간을, 클라우드 마이그레이션은 계정 명의와 월 고정비 변화를, 운영 이관은 계정 권한 회수와 장애 대응 책임 시점을 봅니다.
시간의 길이만 정하지 말고 네 가지를 문서로 남기세요. 시작과 종료 예정 시각을 담은 작업 창, 서비스 중단 상태로 허용하는 최대 시간, 몇 시까지 전환이 안 되면 롤백을 시작한다는 중단 판단 시점, 그리고 롤백을 선언할 사람과 대체 연락처입니다. 중단 판단 시점을 미리 못 박아야 새벽에 "조금만 더 하면 된다"가 반복되면서 정지가 늘어나는 상황을 막을 수 있어요.
네 문장이면 충분합니다. 구 환경을 지정한 날짜까지 삭제하지 않는다, 롤백이 가능한 마지막 경계를 명시한다, 그 경계를 넘어선 뒤의 복구는 별도 데이터 복원 절차로 다룬다, 롤백 실행은 추가 비용 없이 원 계약 범위에 포함한다. 새 환경에 쌓인 주문을 옛 환경으로 옮겨 오는 절차를 따로 합의해 두지 않으면 롤백과 함께 그 주문이 사라지니, 역이관 절차도 같이 정해 두세요.
클라우드, 도메인, 앱스토어, 결제 대행사 계정이 개발사 명의로 남아 있으면 새 환경을 만드는 권한도 옛 환경을 지우는 권한도 개발사에 있어요. 개발사가 폐업하거나 담당자가 퇴사하면 명의 이전 자체가 어려워지는 경우도 있습니다. 발주자 명의로 계정을 먼저 만들고 그 안에 새 환경을 구축하게 한 뒤, 계약서에 "모든 인프라 자산은 발주자 명의 계정에 생성한다"는 문장을 넣으세요.
개발사가 제출하는 건수 대조와 별개로, 발주자는 금액 합계와 최근 데이터 샘플을 직접 봐야 해요. 결제와 정산 금액의 합계가 이전 전후로 맞는지, 직전 며칠 치 주문과 회원 정보가 그대로인지, 첨부 이미지와 파일이 실제로 열리는지 확인합니다. 개발사는 시스템이 정상인지를 보고 발주자는 장부가 맞는지를 보기 때문에 한쪽만으로는 부족합니다.
전환 완료가 아니라 정산 배치가 최소 한 번은 돌고 난 이후까지를 책임 구간으로 잡으세요. 이전으로 생긴 문제가 배치 작업, 월말 정산, 인증서 갱신, 메일 도달률처럼 주기가 긴 항목에서 시차를 두고 드러나는 경우가 반복적으로 관찰되기 때문이에요. 계약서에는 기간, 무상 대응 범위(이전으로 생긴 문제에 한정), 연락 방법과 응답 기준을 함께 적고, 구 서버 삭제는 발주자 승인 후에만 하도록 규정합니다.