SAP S/4HANA Migration Cockpit 단계별 가이드

SAP S/4HANA Migration Cockpit은 Fiori 앱 Migrate Your Data를 통해 새 S/4HANA 시스템에 마스터 데이터와 미결 항목을 로드하는 SAP 도구입니다. 스테이징 테이블과 직접 전송 중 하나를 고르고, 마이그레이션 오브젝트를 선택하고, 값을 매핑하고, 시뮬레이션한 뒤 의존 관계 순서대로 오브젝트별로 로드합니다.

프로그램 리더를 위해 짧게 답하면, 신규 구축에 쓰고, 첫 주부터 하나의 워크스트림으로 계획하고, 데이터 오너를 일찍 정하십시오. 도구는 쉬운 부분입니다.

이 가이드는 제 ECC에서 S/4HANA로의 마이그레이션 가이드의 하위 주제입니다. Cockpit을 설치만 하는 것이 아니라 잘 운영해야 하는 프로그램 리더와 데이터 리더를 위해 썼습니다.

Cockpit은 사전 정의된 마이그레이션 오브젝트를 이용해 비즈니스 데이터를 S/4HANA로 옮깁니다. 각 오브젝트는 고객, 공급업체, 자재, 미결 항목 같은 비즈니스 오브젝트 하나의 소스 구조와 타깃 구조, 그리고 둘 사이의 매핑 규칙을 기술합니다.

SAP는 범위를 분명히 합니다. Cockpit은 신규 구축의 초기 로드를 위해 설계되었으며, 시스템 동기화나 지속적인 데이터 흐름용이 아닙니다. 브라운필드 전환은 핵심 이전에 Cockpit을 쓰지 않습니다. Software Update Manager가 데이터를 그 자리에서 전환하기 때문입니다.

명칭 두 가지를 알아 두면 혼란이 줄어듭니다. 예전 Web Dynpro 트랜잭션 LTMC는 지원 중단되어 더 이상 데이터 마이그레이션에 쓸 수 없으며, 예전 프로젝트를 조회하는 데만 쓸 수 있습니다. 그 후속은 Fiori 앱 Migrate Your Data이며, 지금 사람들이 "Cockpit"이라고 하면 이것을 뜻합니다.

Cockpit은 모든 에디션에 적용되지만, 구성하고 확장하는 방식에 차이가 있습니다. 아래 표는 2026년 10월 기준으로 이를 비교합니다.

영역	SAP S/4HANA 온프레미스 및 SAP Cloud ERP Private(S/4HANA Cloud Private Edition)	SAP S/4HANA Cloud Public Edition
앱	Migrate Your Data	Migrate Your Data(앱 F3473)
스테이징 테이블	로컬 S/4HANA 스키마 또는 원격 SAP HANA 스키마	로컬 스키마 또는 SAP BTP의 원격 SAP HANA Cloud 스키마, 범위 항목 2Q2로 설정
직접 전송	SAP ERP(ECC 6.0 이상), SAP AFS 6.0, SAP EWM 5.1 이상, SAP APO SPP(SCM 7.14 이상)에서	SAP ECC 6.0 이상에서, 범위 항목 BH3로 설정
오브젝트 변경	트랜잭션 LTMOM, 즉 마이그레이션 오브젝트 모델러	스테이징은 Model Your Migration Objects 앱, 직접 전송은 Implementation Activities 앱, 릴리스된 오브젝트만 확장 가능
소스 시스템 제한	S/4HANA 시스템은 소스가 될 수 없음	S/4HANA, Private Edition, Public Edition 시스템은 소스가 될 수 없음

모든 마이그레이션 프로젝트는 두 방식 중 하나를 씁니다. 이 선택이 데이터 워크스트림 전체의 모양을 정하므로, Realize가 아니라 Explore에서 결정하십시오.

스테이징 테이블. Cockpit이 프로젝트의 마이그레이션 오브젝트마다 데이터베이스 테이블 세트를 생성합니다. SAP의 XML 템플릿 파일이나 CSV 파일로, 또는 SAP Data Services나 다른 ETL 도구 같은 자체 도구로 이를 채웁니다. 소스는 무엇이든 될 수 있습니다. 예전 SAP 시스템, Oracle, Dynamics, 자체 개발 시스템, 스프레드시트도 됩니다.

직접 전송. Cockpit이 RFC로 SAP 소스 시스템에 연결해 직접 데이터를 선택하며, ERP 소스라면 회사 코드 단위로 선택합니다. 전제 조건에는 소스 시스템의 DMIS 애드온이 포함되며, 이는 S/4HANA 라이선스에 포함되어 있습니다. 소스 시스템은 비유니코드여도 됩니다.

데이터 리더가 내려야 할 결정을 기준으로 두 방식을 비교하면 다음과 같습니다.

질문	스테이징 테이블	직접 전송
어떤 소스인가?	파일이나 도구를 통한 모든 시스템	지원되는 SAP 소스만
어디서 정제하는가?	로드 전에 스테이징 테이블 또는 그 앞단에서	주로 선택 전에 소스 시스템에서
로드 전에 누가 데이터를 검토할 수 있는가?	테이블이나 파일에 접근할 수 있는 누구나	주로 Cockpit 화면을 통해 Cockpit 팀이
시작에 드는 공수	더 많음: 추출을 만들고 테이블을 채워야 함	더 적음: Cockpit이 대신 선택함
가장 잘 맞는 경우	여러 소스, 더러운 데이터, 많은 변환	새 S/4HANA 설계로 옮겨 가는 깨끗한 SAP ERP 소스

직접 전송도 선택한 데이터를 중간 저장소로서 스테이징 테이블에 둘 수 있어, 그 사이에 검토 지점을 만들 수 있습니다. 이를 전제로 설계하기 전에 귀사 릴리스가 지원하는지 확인하십시오.

제가 이끄는 팀이 스테이징 테이블을 쓰는 이유

Cockpit은 제가 이끄는 팀이 씁니다. 제가 직접 돌리지는 않습니다. 팀의 기본값이자 제 선호는 직접 전송보다 스테이징 테이블입니다.

이유는 통제입니다. 스테이징 테이블에서는 로드될 데이터가 테이블에 있어서, 무엇이든 S/4HANA에 닿기 전에 조회하고 비즈니스 규칙에 비춰 점검하고 고칠 수 있습니다. 데이터 스튜어드는 믿어야만 하는 선택 결과가 아니라 실제로 본 것에 승인할 수 있습니다.

정제와 로드도 분리됩니다. 중복 공급업체, 누락된 은행 정보, 잘못된 단위는 감사 추적과 함께 한곳에서 고쳐지고, 로드 자체는 반복 가능해집니다. 직접 전송은 시작이 빠르지만, 소스 시스템의 습관을 새 시스템에 그대로 옮기는 경향이 있습니다.

그래도 직접 전송이 맞는 경우가 있습니다. 소스가 잘 관리된 단일 SAP ERP 시스템이고 타깃 설계가 그와 가깝다면, 추출 작업을 실제로 줄여 줍니다.

SAP는 마이그레이션 절차를 정해진 순서로 설명합니다. 아래는 팀이 스테이징 테이블로 실행할 단계입니다.

Migration Cockpit 절차

1. 01

   프로젝트 생성

   Migrate Your Data를 열고 프로젝트를 만든 뒤 범위에 든 마이그레이션 오브젝트를 선택합니다.

2. 02

   스테이징 테이블 채우기

   템플릿을 내려받아 업로드하거나, 자체 도구로 테이블을 채웁니다.

3. 03

   값 매핑

   미결 매핑 작업을 처리합니다. 값 매핑과 고정값입니다.

4. 04

   시뮬레이션

   로드를 시뮬레이션하고, 무엇이든 전기하기 전에 모든 오류를 고칩니다.

5. 05

   마이그레이션과 수정

   의존 관계 순서대로 로드한 뒤 실패한 레코드를 고치고 대사합니다.

1. 마이그레이션 프로젝트를 만드십시오. Migrate Your Data 앱에서 프로젝트를 만들고, 스테이징 테이블의 위치(로컬 또는 원격 스키마)를 정하고, 범위에 든 오브젝트를 선택합니다. SAP는 운영 시스템 복사본인 테스트 시스템에서 먼저 프로젝트를 만들고, 테스트 전송마다 이전 전송의 수정 사항을 반영한 새 프로젝트를 만들 것을 권장합니다.
2. 의존 관계를 확인하십시오. 마이그레이션 오브젝트에는 먼저 처리해야 하는 선행 오브젝트와 뒤에 오는 후속 오브젝트가 있을 수 있습니다. Explore Migration Objects 앱(F8638)은 필수 및 선택 선행 오브젝트를 그래프로 보여 줍니다. 미결 항목보다 비즈니스 파트너가 먼저, 재고보다 자재가 먼저입니다. Cockpit은 순서를 건너뛰게 두지 않습니다.
3. 스테이징 테이블을 채우십시오. XML 템플릿이 SAP의 기본 및 권장 옵션입니다. 파일 하나에 오브젝트의 모든 구조와 설명이 들어 있기 때문입니다. CSV는 구조당 파일 하나를 쓰는 전문가용 옵션입니다. XML 파일 하나는 최대 100 MB이고 여러 XML 파일을 묶은 zip도 100 MB를 넘을 수 없으므로, 큰 오브젝트는 나누거나 테이블에 직접 쓰는 도구가 필요합니다.
4. 검증 메시지를 읽으십시오. 업로드 후 시스템은 파일을 검증하고, 모든 오류와 경고를 해당 셀에 연결한 Messages 시트를 추가합니다. 경고가 있는 파일은 데이터가 다음으로 넘어가기 전에 무시해도 되는지 누군가 결정해야 합니다.
5. 매핑 작업을 처리하십시오. 값 매핑 작업은 예전 플랜트 코드를 새 코드로 바꾸듯 소스 값을 타깃 값으로 변환합니다. 고정값 작업은 기본값을 정합니다. 매핑이 많으면 화면에 값을 입력하지 말고 매핑 템플릿을 내려받으십시오.
6. 시뮬레이션하십시오. 시뮬레이션은 전기하지 않고 로드를 실행하며, 어떤 인스턴스가 성공하고 어떤 것이 실패할지 보여 줍니다. 새 매핑 작업이 생길 수 있으니 처리하고 다시 시뮬레이션하십시오. 일부 오브젝트는 시뮬레이션할 수 없으므로 그런 오브젝트는 추가 점검을 계획하십시오.
7. 마이그레이션하십시오. 선행 오브젝트부터 오브젝트별로 로드를 실행합니다. 일부 오브젝트에는 전송 단계가 둘 이상 있으며, 각 단계를 차례로 시뮬레이션하고 마이그레이션합니다.
8. 수정하고 대사하십시오. 필요하면 수정 파일을 써서 실패한 인스턴스를 고친 뒤, 건수와 재무 합계를 소스와 대사합니다. 오류 없이 끝난 작업이 데이터가 맞다는 증거는 아닙니다.

직접 전송도 같은 패턴을 따르되 시작에 한 가지가 다릅니다. 테이블을 채우는 대신 소스 시스템에 대해 Select Data를 실행하며, 모델러에서 선택 범위를 더 좁힐 수 있습니다.

언젠가는 마이그레이션 오브젝트가 딱 맞지 않는 때가 옵니다. 소스의 커스텀 필드, 들어오는 길에 필요한 분할, 또는 SAP가 제공하지 않는 오브젝트입니다.

온프레미스와 프라이빗 에디션에서 쓰는 도구는 트랜잭션 LTMOM, 즉 SAP S/4HANA migration object modeler입니다. 팀은 이것으로 표준 오브젝트를 확장하고, 필드를 추가하고, 커스텀 오브젝트를 정의하고, 시스템 간 마이그레이션 콘텐츠의 이송을 관리할 수 있습니다. 별도의 개발자 역할이 필요하므로, 누가 그 역할을 맡을지 계획하십시오.

퍼블릭 에디션에서는 선택지가 더 좁습니다. 스테이징 테이블의 경우 Model Your Migration Objects 앱은 SAP가 릴리스한 특정 마이그레이션 오브젝트만 확장할 수 있으며, 오브젝트마다 확장 가능한 항목을 나열한 SAP Note가 있습니다. 이는 퍼블릭 에디션의 Clean Core 모델과 일치하며, 귀사 데이터가 정말로 예전 모습 그대로여야 하는지 시험하기에 좋습니다.

제 조언은 모델러 변경 하나하나를 커스텀 코드처럼 다루라는 것입니다. 기록하고, 담당자를 정하고, 현업에 정말 필요한지 물으십시오.

제가 보는 S/4HANA 프로그램에서 데이터 마이그레이션은 공수의 30~40%입니다. Cockpit은 그 워크스트림 안에 있으므로, Cockpit에서 잘못되는 것 대부분은 도구 문제가 아닙니다.

Cockpit 작업의 성패를 가르는 것은 다섯 가지입니다.

1. Explore에서 오브젝트 범위를 정하십시오. 모든 마이그레이션 오브젝트와 그 소스, 양, 담당자를 나열합니다. 실제 건수가 나오면 무료 데이터 마이그레이션 추정 도구가 근거 있는 공수 범위를 줍니다.
2. 오브젝트별 데이터 오너를 지정하십시오. 재무는 고객과 공급업체의 재무 데이터를, 구매는 자재를 소유합니다. 중복된 공급업체 두 건 중 어느 것이 맞는지 IT가 결정할 수는 없습니다.
3. 종료 기준이 있는 로드 사이클을 계획하십시오. 각 사이클은 테스트 시스템의 새 프로젝트이며, 각각 현업이 서명하는 대사로 끝납니다. 제 SAP 데이터 마이그레이션이 실패하는 이유 가이드에 그대로 가져다 쓸 수 있는 모의 로드 계획이 있습니다.
4. 컷오버 기간을 산정하십시오. 한 사이클은 운영 수준의 전체 데이터 양으로 실행하십시오. 파일 한도와 로드 시간은 실제 규모에서만 드러납니다.
5. 컷오버 전에 오브젝트와 매핑을 동결하십시오. 운영 로드는 같은 프로젝트, 템플릿, 매핑으로 최종 리허설을 반복해야 합니다.

제가 S/4HANA 프로그램에서 보는 가장 큰 실수는 처음에 계획을 제대로 세우지 않는 것입니다. Cockpit에서는 그것이 늦게 나오는 오브젝트 목록, 비어 있는 담당자, 그리고 Explore에서 찾았어야 할 문제를 Realize의 첫 로드 사이클에서 찾는 모습으로 나타납니다.

그 사이클들은 전체 계획의 모양도 정합니다. 제 S/4HANA 마이그레이션 일정 가이드는 경로별로 로드 사이클이 어디에 들어가는지 보여 주고, S/4HANA 마이그레이션 비용 가이드는 데이터 예산을 좌우하는 요인을 다룹니다.

Cockpit에 대해 파트너에게 물어야 할 것

서명하기 전에 파트너에게 데이터 접근 방식을 제안 발표가 아니라 서면으로 보여 달라고 하십시오.

1. 오브젝트별로 스테이징 테이블과 직접 전송 중 어느 방식을 제안하며, 그 이유는 무엇인지.
2. 로드 사이클을 몇 번 계획하며, 각 사이클의 종료 기준은 무엇인지.
3. 모델러에서 바꿀 것으로 예상하는 오브젝트는 무엇이며, 그 변경은 누가 유지보수하는지.
4. 귀사 쪽에서 누가 각 오브젝트를 언제 승인하는지.

여기서 일반론적인 답은 경고 신호입니다. 이 일을 해 본 파트너라면 귀사 산업에서 까다로운 오브젝트를 이름으로 댈 수 있습니다.

이번 달에 고객, 공급업체, 자재 마스터를 전체 추출해 레코드 수를 세고 품질을 프로파일링하십시오. 그다음 담당자를 지정해 오브젝트별로 스테이징 테이블과 직접 전송 중 하나를 정하십시오.

아직 소스 시스템을 평가하지 않았다면 SAP Readiness Check와 마이그레이션 평가부터 시작하십시오. 데이터 마이그레이션 계획에 대해 독립적인 시각이 필요하다면 연락해 주십시오.

SAP S/4HANA Migration Cockpit이란 무엇입니까?

새 S/4HANA 시스템에 비즈니스 데이터를 초기 로드하기 위한 SAP 도구이며, Fiori 앱 Migrate Your Data로 실행합니다. 마스터 데이터와 미결 항목에 대해 사전 정의된 마이그레이션 오브젝트를 쓰며, 스테이징 테이블과 SAP 소스 시스템에서의 직접 전송이라는 두 가지 방식을 지원합니다.

S/4HANA에서 LTMC를 아직 쓸 수 있습니까?

데이터 마이그레이션에는 쓸 수 없습니다. SAP는 트랜잭션 LTMC를 지원 중단했으며, 더 이상 S/4HANA로 데이터를 마이그레이션하는 데 쓸 수 없습니다. 예전 프로젝트를 조회하는 것은 여전히 가능합니다.

새 마이그레이션은 Migrate Your Data 앱에서 실행합니다.

스테이징 테이블과 직접 전송의 차이는 무엇입니까?

스테이징 테이블에서는 Cockpit이 마이그레이션 오브젝트마다 테이블을 생성하고, 귀사가 어떤 소스에서든 XML 또는 CSV 템플릿이나 자체 도구로 이를 채웁니다. 직접 전송에서는 Cockpit이 SAP ERP 6.0 같은 지원되는 SAP 소스 시스템에서 RFC 연결로 데이터를 직접 읽습니다. 스테이징 테이블은 로드 전에 점검하고 정제할 여지를 더 줍니다.

브라운필드 전환에 Migration Cockpit을 쓸 수 있습니까?

핵심 이전에는 쓸 수 없습니다. SAP는 Cockpit을 신규 구축 시나리오의 초기 로드용으로 설계합니다. 브라운필드 시스템 전환은 Software Update Manager로 데이터를 그 자리에서 전환합니다.

SAP에서 LTMOM이란 무엇입니까?

LTMOM은 온프레미스와 프라이빗 에디션에서 쓰는 SAP S/4HANA migration object modeler의 트랜잭션입니다. 표준 마이그레이션 오브젝트를 확장하고, 커스텀 필드를 추가하고, 자체 오브젝트를 만들고, 마이그레이션 콘텐츠를 이송할 수 있습니다. 퍼블릭 에디션에서는 Model Your Migration Objects 앱이 같은 일을 더 좁은 범위로 합니다.

S/4HANA Migration Cockpit의 파일 크기 제한은 얼마입니까?

XML 템플릿 파일 하나는 최대 100 MB이며, 여러 XML 파일을 묶은 zip도 100 MB를 넘을 수 없습니다. zip 안의 파일은 압축 전 기준으로 더 클 수 있으며, 파일당 한도는 에디션과 릴리스에 따라 다릅니다.

CSV 폴더도 100 MB로 제한됩니다. 아주 큰 오브젝트는 파일 대신 도구로 스테이징 테이블을 채우십시오.