ECC에서 S/4HANA로의 마이그레이션: 경로, 단계, 일정

SAP ECC의 표준 유지보수는 2027년 12월 31일에 끝납니다. 지금으로부터 약 15개월 뒤입니다. 선택적 연장 유지보수는 더 높은 수수료를 내면 2030년 말까지 이어집니다(SAP News). 복잡한 마이그레이션은 본격적인 테스트에 들어가면 18~24개월로 쉽게 늘어납니다. 아직 경로를 정하지 못했다면, 기한 안에 Go-Live하기는 이미 어렵습니다.

이 결정을 내리는 CIO나 프로그램 리드라면 선택지는 세 가지입니다. 그린필드, 브라운필드, 선택적 데이터 전환입니다. 어느 쪽이든 그 뒤의 작업은 같은 다섯 단계를 따릅니다. 먼저 SAP Readiness Check를 실행하고, 그다음에 고르십시오.

ECC에서 S/4HANA로 가는 것은 단순한 업그레이드가 아닙니다. 데이터를 저장하는 방식, 트랜잭션이 전기되는 방식, 사용자가 일하는 방식이 바뀝니다. 제가 참여한 한 프로젝트에서는 팀이 ECC에 있던 수십 개의 커스텀 리포트를 그대로 다시 만들었습니다. 아직 필요한지 묻는 사람은 없었습니다. 나중에 보니 절반은 한 번도 쓰이지 않았습니다. 마이그레이션은 기술적으로 깔끔했습니다. 가치는 그렇지 않았습니다.

마이그레이션 작업량을 좌우하는 차이는 다음과 같습니다.

영역	SAP ECC	SAP S/4HANA
데이터베이스	지원되는 모든 데이터베이스(Oracle, Db2, SQL Server 등)	SAP HANA만 가능
재무 데이터 모델	FI, CO, 수익성 테이블과 합계 테이블이 각각 따로 존재	유니버설 저널(ACDOCA 테이블)이 단일 라인 아이템 소스
고객 및 공급업체 마스터	고객과 공급업체 레코드가 분리됨	비즈니스 파트너 필수
사용자 인터페이스	SAP GUI	SAP Fiori 앱, 온프레미스와 프라이빗 에디션에서는 SAP GUI도 계속 사용 가능
배포	온프레미스	온프레미스, 프라이빗 에디션(RISE with SAP) 또는 퍼블릭 에디션(GROW with SAP)
확장	Z 프로그램과 수정	클린 코어: 릴리스된 API, 온스택 ABAP Cloud 또는 SAP BTP의 사이드 바이 사이드
유지보수	EHP 6~8은 2027년 말까지 표준 유지보수, 2030년 말까지 연장	SAP는 2040년 말까지 유지보수를 약속

함께 일한 한 고객사는 전환 후 커스텀 배치 잡이 왜 더 이상 동작하지 않느냐고 계속 물었습니다. 그 로직은 S/4HANA에서 바뀐 ECC 테이블 구조에 의존하고 있었습니다. 마이그레이션 자체는 끝나 있었습니다. 그 잡들이 새로운 모델에서도 의미가 있는지 물은 사람은 없었습니다.

마이그레이션은 데이터를 옮깁니다. 진짜 질문은 물려받은 설계상의 결정을 어떻게 할 것인가입니다.

Decide

어떤 마이그레이션 경로가 우리 상황에 맞을까요?

레거시가 분절되어 있고 프로세스를 재설계하려는 경우

→그린필드

프로세스가 탄탄하고 ECC가 안정적이며 이력을 보존해야 하는 경우

→브라운필드

여러 법인이 있고 일부만 재사용하며 선택적 데이터를 옮기려는 경우

→블루필드

그린필드: 새로 시작하기

S/4HANA를 새로 구축하는 방식입니다. 레거시 구성은 하나도 가져오지 않고, 프로세스는 SAP 표준에 맞춰 다시 설계하며, 필요한 데이터만 SAP S/4HANA Migration Cockpit으로 적재합니다.

적합한 경우: 레거시 시스템이 너무 분절되어 깔끔하게 전환하기 어렵거나, 비즈니스가 프로세스를 그대로 옮기지 않고 다시 생각하고 싶을 때입니다.

주의할 점은 변화의 무게입니다. 사용자는 익숙한 업무 방식을 잃습니다. 그린필드 시스템이 얼마나 다르게 느껴지는지 사용자에게 미리 준비시키지 않아 후회하는 기업을 여러 번 보았습니다. 도입 계획이 교육 단계에서 시작된다면 이미 늦은 것입니다.

브라운필드: 시스템 컨버전

기존 ECC 시스템을 그 자리에서 전환합니다. 구성, 커스텀 코드, 이력이 함께 넘어옵니다. 기술적 전환은 데이터베이스 마이그레이션 옵션이 있는 Software Update Manager(SUM)로 진행합니다.

적합한 경우: 프로세스가 성숙해 있고, 컴플라이언스상 트랜잭션 이력이 중요하며, 대규모 구조 개편이 진행 중이 아닐 때입니다.

주의할 점은 함께 넘어오는 기술 부채입니다. 전환 중에 의도적으로 정리하지 않으면 레거시의 복잡성이 그대로 따라옵니다.

선택적 데이터 전환

흔히 “블루필드”라는 이름으로 판매됩니다. 전부가 아니라 선택한 회사 코드, 사업부 또는 기간별 데이터 조각을 옮기며, 보통 전문 도구와 이 방식에 경험이 있는 파트너가 필요합니다. 인수합병이나 사업 분할로 만들어진 그룹, 또는 수년 치 이력이 더는 중요하지 않은 경우에 맞습니다.

적합한 경우: 그린필드 같은 프로세스 자유도와, 중요한 곳에서는 브라운필드 같은 데이터 연속성을 함께 원할 때입니다.

이사회가 보통 묻는 질문을 기준으로 세 방식을 비교하면 다음과 같습니다.

기준	그린필드	브라운필드	선택적 전환
프로세스 재설계	전면적, SAP 표준 기준	대체로 유지	단위별로 선택
과거 데이터	이월하지 않음(또는 미결 항목과 잔액만)	전부 이월	선택한 범위
Go-Live까지 걸리는 시간	더 길다	더 짧다	범위에 따라 다름
기술 부채	제거됨	이월됨	마이그레이션 범위에서는 감소
변화 영향	큼	낮음	중간
가장 적합한 경우	분절된 레거시, 대규모 재설계	안정적이고 관리가 잘 된 ECC	인수합병, 사업 분할, 단계적 롤아웃

마이그레이션 순서

1. 01

   평가

   SAP Readiness Check를 실행합니다. 커스텀 코드, 애드온, 인터페이스를 목록화합니다.

2. 02

   데이터 분류

   데이터를 핫, 웜, 콜드로 나눕니다. 콜드 데이터는 옮기지 않아도 됩니다.

3. 03

   데이터 정제

   중복, 불일치, 누락된 필드를 해결합니다. 언제나 계획보다 오래 걸립니다.

4. 04

   코드 조정

   ABAP Test Cockpit 점검을 실행합니다. Z 코드는 그대로 옮기지 말고 줄이십시오.

5. 05

   테스트 및 컷오버

   여러 차례 테스트와 최소 한 번의 전체 컷오버 리허설을 합니다.

1. 평가 및 준비도 확인

여기서 시작하십시오. 항상 그렇습니다. SAP Readiness Check는 ECC 시스템을 분석해 단순화 항목, 애드온 호환성, 커스텀 코드, 데이터 볼륨, 사이징을 보고합니다.

놀라는 대목은 대개 애드온과 커스텀 코드입니다. 제가 함께 일한 일부 고객사는 범위에 수백 개의 커스텀 오브젝트가 있었고, 대부분은 비활성 코드가 이렇게 많이 나온다는 데 놀랍니다. 이를 12개월 차가 아니라 2주 차에 찾는 편이 낫습니다.

기술 전제 조건도 동시에 확인하십시오. 전환은 어떤 인핸스먼트 패키지든 SAP ERP 6.0에서 시작할 수 있습니다. 시스템은 유니코드여야 하며, 그렇지 않으면 2단계 전환을 계획해야 합니다. 듀얼 스택 시스템은 먼저 분리해야 합니다. 고객 마스터와 공급업체 마스터는 전환 전에 비즈니스 파트너로 변환되어 있어야 합니다. 마지막 항목에서 걸리는 팀이 다른 어떤 항목보다 많습니다.

2. 데이터 분석 및 분류

옮기기 전에 데이터를 측정하고 분류하십시오.

1. 핫: 자주 사용하며 실시간 처리에 필요합니다.
2. 웜: 가끔 접근하며 관련은 있지만 매일 쓰지는 않습니다.
3. 콜드: 이력이거나 사용하지 않으며 감사용으로만 보관합니다.

콜드 데이터는 S/4HANA로 들어갈 필요가 없습니다. 아카이빙하십시오. 이 단계를 건너뛰는 팀은 새 시스템에 잡동사니를 들여와 마이그레이션과 성능을 모두 느리게 만듭니다.

3. 데이터 정제 및 아카이빙

이 단계는 어떤 계획이 허용하는 것보다도 오래 걸립니다. 중복된 공급업체 레코드. 일관되지 않은 단위. 반쯤만 채워진 고객 마스터. 이런 문제는 모든 ECC 시스템에 있으며, 먼저 고치지 않으면 그대로 S/4HANA로 넘어갑니다.

함께 일한 한 고객사는 데이터 정제와 아카이빙에만 5개월을 썼습니다. 정제를 건너뛴 팀은 컷오버 중에 문제를 발견하는데, 그때는 제대로 고칠 시간이 없습니다. 이 단계는 제 글 SAP 데이터 마이그레이션이 실패하는 이유에서 더 깊이 다룹니다.

4. 커스텀 코드 조정

ABAP Test Cockpit(ATC) S/4HANA 준비도 점검을 실행하십시오. 코드를 SAP의 단순화 항목과 비교합니다. 결과를 보면 구문 수정이 필요한 것, 기능적으로 교체해야 할 것, 폐기해야 할 것이 구분됩니다.

목표는 동작하는 Z 코드가 아니라 더 적은 Z 코드입니다. 옮겨 오는 커스텀 오브젝트는 하나하나가 이후 모든 업그레이드의 비용을 늘립니다. 남는 것을 분류하는 방법은 제 클린 코어 가이드에서 다룹니다.

5. 테스트, 교육, 컷오버

테스트는 단위, 통합, 사용자 인수 테스트(UAT) 순으로 단계를 나눠 진행하고, 마지막에 최소 한 번의 전체 컷오버 리허설을 하십시오. UAT에는 핵심 사용자와 가끔 쓰는 사용자를 모두 넣으십시오. 찾아내는 문제가 서로 다릅니다.

리허설은 선택 사항이 아닙니다. 전체 순서를 돌려 봐야 드러나는 시간 공백, 누락된 검증, 인터페이스 장애가 여기서 나옵니다. 리허설을 건너뛴 팀은 그 문제를 Go-Live 주말에 만납니다.

모든 마이그레이션 계획에서 보게 되리라고 기대하는 SAP 도구는 다음과 같습니다.

도구	하는 일	사용 시점
SAP Readiness Check	단순화 항목, 애드온, 커스텀 코드, 사이징	경로를 정하기 전
ABAP Test Cockpit (ATC)	깨질 커스텀 코드를 찾음	커스텀 코드 조정
SAP Signavio	프로세스가 문서화된 방식이 아니라 실제로 돌아가는 방식을 보여 줌	설계 동결 전
SAP LeanIX	애플리케이션과 인터페이스를 매핑	통합 설계
Software Update Manager (SUM)	기술적 전환을 실행	브라운필드 전환
SAP S/4HANA Migration Cockpit	마스터 데이터와 트랜잭션 데이터를 적재	그린필드 데이터 마이그레이션

인핸스먼트 패키지 6~8의 SAP ERP 6.0은 2027년 12월 31일에 표준 유지보수가 끝납니다. 선택적 연장 유지보수는 유지보수 기준 금액에 2%포인트의 할증을 얹어 2030년 12월 31일까지 이어집니다. 그보다 이전의 인핸스먼트 패키지는 이미 2025년 말에 표준 유지보수에서 빠졌습니다.

2030년 이후에는 좁은 길이 하나 있습니다. SAP의 SAP ERP 프라이빗 에디션 전환 옵션이 2031~2033년을 다룹니다. 2030년 말 이전에 SAP HANA 기반 SAP ERP 프라이빗 에디션으로 옮긴 대형 시스템에만 적용되며, SAP의 max success plan이 있어야 합니다. 계획이 아니라 예외로 보십시오.

기간으로 보면, 복잡한 시스템의 전체 마이그레이션은 본격적인 테스트에 들어간 뒤 18~24개월 이상으로 늘어날 수 있습니다. 중견에서 대기업이라면 준비가 잘 된 전환에 12~18개월 이상이 현실적입니다. 여러 법인에 걸친 대규모 그린필드 프로그램은 24~36개월이 걸리기도 합니다.

1. 2027ECC 표준 유지보수 종료12월 31일, SAP ERP 6.0 EHP 6~8 기준
2. 2028지금 시작하면 예상되는 Go-Live본격적인 테스트에 들어가면 18~24개월
3. 2030연장 유지보수 종료선택 사항, 두 포인트 할증
4. 2033전환 옵션 종료프라이빗 에디션, 대형 시스템만 해당

출처: SAP News, 2020년 2월 및 2025년 8월

계산은 간단합니다. 복잡한 평가를 오늘 시작하면 Go-Live는 2028년이 됩니다. 연장 유지보수를 예산에 반영하고, 기다리는 대신 그 시간에 데이터를 정리하고 커스텀 코드를 폐기하십시오. 선택지를 시험해 보려면 제 마이그레이션 평가를 써 보십시오.

그린필드와 브라운필드 ECC to S/4HANA 마이그레이션의 차이는 무엇입니까?

그린필드는 신규 구축입니다. 레거시 구성이나 커스텀 코드는 가져오지 않고, 프로세스는 SAP 표준에 맞춰 설계하며, 필요한 데이터만 적재합니다. 브라운필드는 기존 ECC 시스템을 전환하며 구성, 커스텀 코드, 이력을 그대로 유지합니다. 더 빠르고 혼란도 적지만 기술 부채가 함께 따라옵니다. 선택적 데이터 전환은 둘 사이에 있습니다.

SAP ECC에서 S/4HANA로의 마이그레이션 기한은 언제입니까?

인핸스먼트 패키지 6~8의 SAP ERP 6.0은 2027년 12월 31일에 표준 유지보수가 끝납니다. 선택적 연장 유지보수는 유지보수 기준 금액에 2%포인트의 할증을 얹어 2030년 12월 31일까지 이어집니다. 2031~2033년의 전환 옵션은 2030년 말 이전에 SAP HANA 기반 SAP ERP 프라이빗 에디션으로 옮긴 대형 시스템에만 있습니다.

SAP Readiness Check는 무엇을 알려 줍니까?

ECC 시스템을 분석해 구성에 영향을 주는 단순화 항목, 애드온 호환성, 커스텀 코드 영향, 데이터 볼륨, HANA 사이징을 보고합니다. 일찍 실행하면 범위 논의가 달라집니다. 팀이 자신들이 의존하는 줄 몰랐던 애드온과 커스텀 코드를 흔히 발견하기 때문입니다.

ECC에서 S/4HANA로의 마이그레이션에는 얼마나 걸립니까?

중견에서 대기업의 준비가 잘 된 전환은 12~18개월 이상 걸리는 경우가 많습니다. 복잡한 다법인 프로그램은 본격적인 테스트에 들어가면 18~24개월, 대규모 그린필드 프로그램은 24~36개월까지 늘어날 수 있습니다. 일정이 밀리는 가장 흔한 이유는 데이터 정제입니다.

유니버설 저널(ACDOCA)이란 무엇이며 마이그레이션에서 왜 중요합니까?

유니버설 저널은 ECC에서 별도 테이블에 나뉘어 있던 재무회계, 관리회계, 수익성 데이터를 한데 모은 단일 라인 아이템 테이블 ACDOCA입니다. COEP나 수익성 테이블처럼 예전 구조를 읽는 커스텀 코드와 리포트는 검토가 필요합니다. 일부는 작은 수정으로 끝나고, 일부는 재설계가 필요합니다.

ECC를 S/4HANA로 전환하기 위한 기술 전제 조건은 무엇입니까?

전환은 어떤 인핸스먼트 패키지든 SAP ERP 6.0에서 시작할 수 있습니다. 시스템은 유니코드여야 하며, 그렇지 않으면 2단계 방식을 씁니다. 듀얼 스택 시스템은 먼저 분리해야 합니다. 고객 마스터와 공급업체 마스터는 비즈니스 파트너로 변환되어야 합니다. 일정을 확정하기 전에 SAP Readiness Check와 ATC 커스텀 코드 점검을 실행하십시오.

ECC 마이그레이션에는 RISE with SAP과 GROW with SAP 중 무엇을 선택해야 합니까?

중요한 커스텀 코드와 복잡한 프로세스를 가진 대부분의 ECC 고객은 기존 시스템의 전환을 지원하는 RISE with SAP의 S/4HANA Cloud Private Edition으로 갑니다. GROW with SAP은 퍼블릭 에디션을 쓰며, 표준 프로세스와 릴리스된 API 확장만 쓰는 신규 구축입니다. SAP 표준을 받아들일 의향이 있는 기업에 맞습니다.