경로별 S/4HANA 마이그레이션 일정과 프로젝트 계획

제 경험상 SAP ECC에서 출발하는 S/4HANA 마이그레이션 일정은 브라운필드 전환이 12~18개월, 그린필드 구축이 18~24개월입니다. 선택적 데이터 전환은 12~18개월이 걸립니다. 프로젝트 계획은 SAP Activate의 여섯 단계를 따르며, 가장 자주 초과되는 단계는 커스텀 코드입니다.

짧게 답하면 이렇습니다. 계획은 SAP Readiness Check로 시작하고, 데이터에 공수의 30~40%를 배정하십시오. 브라운필드라면 모의 전환을 세 번 계획하고, 컷오버 다운타임은 주말 하루에서 일주일까지 예상하십시오.

이 글은 제 ECC에서 S/4HANA로의 마이그레이션 가이드를 뒷받침하는 일정과 계획의 세부 내용입니다. 그 가이드는 경로와 ECC 기한을 다룹니다. ECC에서 옮기는 것이 아니라 SAP를 새로 구축한다면, 단계별 기간을 정리한 제 SAP 구축 일정 가이드가 그 경우를 다룹니다.

경로가 기간을 정합니다. 제 원칙은 이렇습니다. 다른 시스템에서 옮겨 오거나 새 프로세스를 정의해야 하면 그린필드입니다. 프로세스가 정의되어 잘 작동하면 브라운필드, 일부 영역의 프로세스를 다시 정의해야 하면 선택적 전환입니다.

제가 본 프로그램에서 각 경로에 걸린 기간과, 보통 기간을 늘리는 요인은 다음과 같습니다.

경로	일반적인 일정	계획의 중심	보통 기간을 늘리는 요인
브라운필드(시스템 전환)	12~18개월	Software Update Manager로 기존 ECC 시스템을 전환한 뒤 테스트 전환을 반복	커스텀 코드 조정과 비즈니스 파트너 전환
그린필드(신규 구축)	18~24개월	Fit-to-Standard 설계, 빌드, 데이터 로드 사이클 반복	긴 요구사항 목록으로 변하는 Explore 워크숍, 그리고 데이터 정제
선택적 데이터 전환	12~18개월	어떤 회사 코드, 조직 단위, 이력 데이터를 옮길지 합의한 뒤 전문 도구 사용	데이터 범위 설정과 전문 파트너 의존

경로만큼 달력도 중요합니다. 인핸스먼트 패키지 6~8의 ECC는 메인스트림 유지보수가 2027년 12월 31일에 끝납니다(SAP News). 이번 달에 시작한 브라운필드는 2027년 10월에서 2028년 4월 사이에 가동되고, 지금 시작한 그린필드는 2028년에 가동됩니다.

그래서 오늘 작성하는 계획 대부분은 예산에 어느 정도의 연장 유지보수가 필요합니다. 2년 차에 놀라지 말고 처음부터 넣어 두십시오.

RISE with SAP는 경로가 아니라 상업 패키지입니다. RISE에서의 브라운필드나 선택적 전환은 SAP Cloud ERP Private에 안착합니다. 이는 많은 사람이 아직 S/4HANA Cloud Private Edition으로 검색하는 제품을 SAP가 현재 부르는 이름입니다. 제가 제시하는 GROW with SAP 6~9개월, RISE 9~18개월은 신규 구축 기준이며, ECC 이전 기준이 아닙니다.

SAP Activate는 S/4HANA를 위한 SAP의 딜리버리 방법론입니다. Discover, Prepare, Explore, Realize, Deploy, Run의 여섯 단계로 이루어집니다(SAP Activate).

마이그레이션도 같은 단계를 씁니다. 달라지는 것은 각 단계 안의 작업입니다.

마이그레이션 프로젝트 계획

1. 01

   Discover

   Readiness Check, 경로 결정, 비즈니스 케이스.

2. 02

   Prepare

   계획, 거버넌스, 팀, 첫 샌드박스.

3. 03

   Explore

   Fit-to-Standard 또는 델타 설계, WRICEF 목록 합의.

4. 04

   Realize

   빌드, 커스텀 코드, 데이터 로드, 테스트 전환.

5. 05

   Deploy

   최종 리허설, 컷오버, Go-Live.

6. 06

   Run

   하이퍼케어, 안정화, ECC 폐기.

마이그레이션에서 각 단계에 담기는 내용과 경로별 차이는 다음과 같습니다.

단계	마이그레이션에서 하는 일	경로별 차이
Discover	SAP Readiness Check, 경로 결정, 비즈니스 케이스, 커스텀 코드와 데이터에 대한 첫 검토	선택적 전환은 여기서 첫 데이터 범위가 필요
Prepare	계획, 거버넌스, 팀, 데이터 오너십, 샌드박스	브라운필드는 첫 샌드박스 전환을 실행하고, 그린필드는 시스템과 워크숍 일정을 준비
Explore	Fit-to-Standard 워크숍 또는 델타 설계, WRICEF 목록 합의, 데이터 매핑	그린필드가 가장 오래 머무는 단계이고, 브라운필드는 해당되는 단순화 항목을 처리
Realize	빌드, 커스텀 코드 조정, 데이터 로드 사이클, 테스트 라운드	브라운필드는 모의 전환을, 그린필드는 보통 Migration Cockpit으로 로드 사이클을 실행
Deploy	최종 리허설, 컷오버, Go-Live	다운타임 기간은 경로, 데이터 양, 접근 방식에 따라 다름
Run	하이퍼케어, 안정화	ECC를 폐기하고 보관할 데이터를 아카이브

WRICEF는 워크플로, 보고서, 인터페이스, 전환, 개선(enhancement), 양식을 뜻합니다. SAP 표준을 넘어 직접 만드는 모든 것의 목록이며, 지켜봐야 할 숫자입니다.

제가 이끌었거나 구해 낸 21개 SAP 프로그램을 통틀어 가장 큰 실수는 구축 초기에 계획을 제대로 세우지 않는 것입니다. Prepare 단계에서 누가 데이터 정제를 맡을지, 어떤 커스텀 코드를 폐기할지, 각 테스트 전환과 리허설을 언제 할지 합의하십시오. 그 날짜들이 계획의 뼈대가 됩니다.

브라운필드: 테스트 전환을 중심으로 계획

브라운필드 계획은 전환 사이클을 중심으로 짭니다. Software Update Manager가 시스템을 전환하고, 테스트를 한 번 돌릴 때마다 실제 전환에 얼마나 걸릴지, 무엇이 깨지는지 알 수 있습니다.

브라운필드에서는 컷오버 전에 모의 전환을 세 번 계획합니다. 각 모의 전환은 최근 운영 시스템 복사본에서 실행해야 시간 측정이 의미가 있습니다. 마지막 모의 전환은 Go-Live처럼 진행해야 합니다. 같은 순서, 같은 사람, 같은 점검입니다.

다운타임 최적화 방식에 대한 SAP 자체 계획도 비슷합니다. 샌드박스 실행, 품질 보증 실행, 클론에서의 로드 검증, 최종 리허설을 제시합니다(SAP Learning). SAP는 실행 횟수를 줄이는 것이 기술적으로는 가능하지만 위험이 커진다고 밝힙니다.

그린필드: 설계와 데이터 로드를 중심으로 계획

그린필드의 시간은 Explore에 들어갑니다. Fit-to-Standard 워크숍에서 SAP 표준을 얼마나 채택할지 정하고, 모든 갭은 빌드하고 테스트하고 유지보수해야 할 WRICEF 오브젝트가 됩니다.

데이터는 로드 사이클로 옮기며, 보통 SAP S/4HANA Migration Cockpit을 씁니다. 전체 로드 사이클을 여러 번 계획하고, 매번 현업이 서명하는 대사(reconciliation)를 거치십시오. 제 Migration Cockpit 단계별 가이드에서 스테이징 테이블, 마이그레이션 오브젝트, 로드 절차를 다룹니다.

선택적 전환: 데이터 범위를 중심으로 계획

선택적 전환 계획은 데이터 범위에서 시작합니다. 어떤 회사 코드, 사업 단위, 몇 년 치 이력을 옮길지, 그리고 어떤 프로세스를 재설계할지입니다.

그 범위가 도구, 전문 파트너, 테스트 사이클을 결정합니다. 범위를 늦게 바꾸면 일정도 함께 움직입니다.

제 경험상 커스텀 코드는 가장 자주 초과되는 단계입니다. 마이그레이션에서 가장 자주 잊히는 숨은 비용이기도 하며, 이는 제 S/4HANA 마이그레이션 비용 가이드에서 다룹니다.

제가 지켜볼 지점은 순서대로 다음과 같습니다.

1. 커스텀 코드. 팀은 보고서로 범위를 잡은 뒤, 수정 작업이 시작되고 나서야 실제 규모를 알게 됩니다. 한 프로그램에서는 smartShift로 분석해 커스텀 오브젝트를 18,000개에서 3,200개로 줄였습니다. 먼저 폐기하고, 그다음에 조정하십시오.
2. 평가에서 놓친 커스텀 오브젝트. 제 경험상 SAP Readiness Check가 놓친 커스텀 오브젝트가 나중에 문제를 일으킵니다. 그 결과를 범위로 삼기 전에 제 SAP Readiness Check 가이드를 읽어 보십시오.
3. 데이터. 데이터 마이그레이션은 공수의 30~40%를 차지합니다. 정제 담당자가 없으면 늦게 시작되고, 결국 테스트 사이클을 압박합니다. SAP 데이터 마이그레이션이 실패하는 이유에 관한 제 글에서 더 깊이 다룹니다.
4. Explore. WRICEF 목록이 늘어나면서 예산은 Explore에서 타격을 받습니다. 벤더가 범위를 통제하면, 벤더 쪽에는 그 증가를 멈출 이유가 있는 사람이 아무도 없습니다.
5. 시간을 아끼려고 줄인 리허설. 날짜를 지키려고 뺀 리허설은 아낀 시간보다 Go-Live 주말에 더 많은 시간을 잡아먹는 경향이 있습니다.

제 의견은 이렇습니다. Go-Live 날짜는 WRICEF 목록과 커스텀 코드 범위가 확인되는 Explore 말에 확정하십시오. 킥오프 때 정한 날짜는 이사회 보고 자료가 붙은 추측일 뿐입니다.

제가 본 컷오버 다운타임은 주말 하루에서 일주일까지였습니다. 데이터 양, 전환 방식, 함께 가동되는 법인과 인터페이스의 수, 현업이 얼마나 빨리 검증할 수 있는지가 모두 이를 좌우합니다.

브라운필드의 경우 SAP는 Software Update Manager에서 다운타임 최적화 전환 방식을 제공합니다. 운영 시스템이 계속 돌아가는 동안 데이터 전환과 마이그레이션의 일부를 업타임으로 옮깁니다.

공짜로 얻는 시간은 아닙니다. SAP는 추가 테스트 실행, 더 복잡한 계획, 다운타임 전 커스터마이징과 개발 동결, 그리고 이 방식에 숙련된 전문가를 요건으로 듭니다.

그러므로 기술적 방식을 고르기 전에 현업이 받아들일 수 있는 다운타임을 합의하십시오. 그리고 Go-Live 주말이 아니라 모의 전환에서 그것을 입증하십시오. 컷오버는 월 마감과 성수기를 피하십시오.

계획은 그 뒤에 있는 가정만큼만 좋습니다. 누군가 서명하기 전에 제가 물어볼 질문은 다음과 같습니다.

1. 계획은 어떤 경로를 가정하며, 우리 Readiness Check 결과 중 무엇이 그것을 뒷받침합니까?
2. 사용량 분석 후 범위에 남은 커스텀 오브젝트는 몇 개이며, 그중 몇 개를 폐기합니까?
3. 데이터 정제는 누가 맡으며, 어느 단계에서 시작합니까?
4. 모의 전환이나 로드 사이클은 몇 번 계획되어 있고, 어떤 데이터로 실행합니까?
5. 계획은 어느 정도의 다운타임을 가정하며, 어떤 테스트 실행이 그것을 입증합니까?
6. 날짜는 언제 확정되며, Explore에서 WRICEF 목록이 늘어나면 날짜는 어떻게 됩니까?

파트너에게 귀사와 비슷한 프로그램의 레퍼런스와 상위 수준 설계를 요청하십시오. 답이 귀사 비즈니스에 맞춘 것이 아니라 일반론이라면 경고 신호로 받아들이십시오.

이번 분기에 SAP Readiness Check를 실행하십시오. 누구든 Go-Live 날짜를 약속하기 전에 커스텀 코드와 데이터 결과를 CFO와 프로그램 디렉터 앞에 내놓으십시오.

그다음 받아들일 수 있는 컷오버 기간에서 거꾸로 계획을 세우십시오. 브라운필드라면 모의 전환 세 번, 아니면 귀사 경로에 필요한 로드 사이클을 넣으십시오. 경로 자체를 먼저 점검하려면 제 그린필드 대 브라운필드 마이그레이션 평가를 해 보십시오.

저는 이런 마이그레이션 계획을 세우고 압박 테스트하는 일을 돕습니다. 독립적인 시각이 필요하다면 연락해 주십시오.

S/4HANA 마이그레이션은 얼마나 걸립니까?

제 경험상 ECC에서의 브라운필드 전환은 12~18개월, 그린필드 구축은 18~24개월, 선택적 데이터 전환은 12~18개월이 걸립니다. 커스텀 코드가 가장 자주 초과되는 단계이며, 데이터 마이그레이션은 공수의 30~40%를 차지합니다.

S/4HANA 마이그레이션 프로젝트 계획의 단계는 무엇입니까?

계획은 SAP Activate를 따릅니다. Discover, Prepare, Explore, Realize, Deploy, Run입니다. 마이그레이션에서 Discover에는 Readiness Check와 경로 결정이, Realize에는 커스텀 코드, 데이터 로드, 테스트 전환이, Deploy에는 최종 리허설과 컷오버가 들어갑니다.

S/4HANA 브라운필드 마이그레이션에는 모의 전환이 몇 번 필요합니까?

브라운필드에서는 컷오버 전에 모의 전환을 세 번 계획합니다. SAP는 다운타임 최적화 방식에 대해 샌드박스 실행, 품질 보증 실행, 로드 검증, 최종 리허설을 제시하며, 실행 횟수를 줄이면 위험이 커진다고 말합니다.

S/4HANA 컷오버 다운타임은 얼마나 됩니까?

제가 본 컷오버 다운타임은 주말 하루에서 일주일까지였습니다. 데이터 양, 전환 방식, 함께 가동되는 법인과 인터페이스의 수에 따라 달라집니다. SAP의 다운타임 최적화 전환은 작업 일부를 업타임으로 옮기지만, 더 많은 테스트 실행과 계획이 필요합니다.

2027년 ECC 지원 종료 전에 S/4HANA 마이그레이션을 끝낼 수 있습니까?

인핸스먼트 패키지 6~8의 ECC는 메인스트림 유지보수가 2027년 12월 31일에 끝납니다. 2026년 10월에 시작한 브라운필드는 2027년 10월에서 2028년 4월 사이에, 그린필드는 2028년에 가동됩니다. 지금 시작하는 프로그램 대부분은 어느 정도의 연장 유지보수를 예산에 넣어야 합니다.

S/4HANA 마이그레이션 프로젝트를 가장 많이 지연시키는 것은 무엇입니까?

제 경험상 커스텀 코드가 가장 자주 초과되고, 그다음이 늦게 시작하는 데이터 정제와 Explore에서 계속 늘어나는 WRICEF 목록입니다. 이런 문제 대부분의 뿌리는 프로그램 초기에 계획을 제대로 세우지 않은 데 있습니다.