ECC에서 S/4HANA로의 마이그레이션: 경로, 단계, SAP ECC 기한

ECC에서 S/4HANA로의 마이그레이션은 SAP ERP 시스템을 SAP ECC 6.0에서 SAP S/4HANA로 옮기면서 데이터베이스, 재무 데이터 모델, 사용자 인터페이스를 새로 바꾸는 작업입니다. 결정해야 할 것은 어떤 경로를 택할지, 그리고 ECC 메인스트림 유지보수가 2027년 12월 31일에 끝나기 전에 가동할 수 있는지입니다.

짧게 답하면, 다른 시스템에서 옮겨 오거나 새 프로세스가 필요하면 그린필드, 프로세스가 정의되어 잘 작동하면 브라운필드, 일부 영역만 재설계가 필요하면 선택적 데이터 전환입니다. 제 경험상 브라운필드는 12~18개월, 그린필드는 18~24개월, 선택적 데이터 전환은 12~18개월이 걸립니다. 어느 쪽이든 확정하기 전에 SAP Readiness Check를 실행하십시오.

ECC에서 S/4HANA로 가는 것은 단순한 업그레이드가 아닙니다. 데이터를 저장하는 방식, 거래가 전기되는 방식, 사용자가 일하는 방식이 바뀝니다.

제가 참여한 한 프로젝트에서는 팀이 수십 개의 커스텀 리포트를 ECC에 있던 그대로 다시 만들었습니다. 그것이 여전히 필요한지 아무도 묻지 않았습니다. 나중에 보니 그 절반은 한 번도 쓰이지 않았습니다.

마이그레이션은 기술적으로 깔끔했습니다. 가치는 그렇지 않았습니다.

SAP ECC는 SAP ERP Central Component의 약자입니다. SAP ERP 6.0의 핵심이자 SAP Business Suite 7의 핵심 애플리케이션 중 하나이며, 사람들이 "SAP ECC"라고 할 때는 거의 항상 ECC 6.0을 뜻합니다. 재무회계, 관리회계, 구매, 판매, 생산을 Oracle부터 SQL Server, Db2까지 SAP가 지원하는 모든 데이터베이스에서 실행합니다.

옮겨야 하는 첫 번째 이유는 유지보수입니다. 인핸스먼트 패키지 6~8의 SAP ERP 6.0은 메인스트림 유지보수가 2027년 12월 31일에 끝납니다. 인핸스먼트 패키지 5 이하의 시스템은 2025년 말에 이미 메인스트림 유지보수가 끝났습니다(SAP).

SAP S/4HANA는 후속 제품이며, SAP는 2040년 말까지 유지보수를 약속했습니다.

두 번째 이유는 시간입니다. 2026년 10월인 오늘 브라운필드 전환을 시작하면 가동은 2027년 말에서 2028년 봄 사이가 됩니다. 오늘 그린필드를 시작하면 2028년에 가동합니다.

따라서 대부분의 ECC 고객에게 질문은 더 이상 옮길지 말지가 아닙니다. 어떤 경로를 택할지, 그리고 옮기는 동안 연장 유지보수 예산을 얼마나 잡을지입니다.

이 주제는 제 YouTube 채널의 영상(영어)에서도 다룹니다.

마이그레이션 공수의 대부분을 좌우하는 차이는 다음과 같습니다.

영역	SAP ECC	SAP S/4HANA
데이터베이스	지원되는 모든 데이터베이스(Oracle, Db2, SQL Server 등)	SAP HANA만
재무 데이터 모델	FI, CO, 수익성 분석 테이블이 분리되어 있고 합계 테이블이 있음	유니버설 저널(테이블 ACDOCA)이 단일 라인 아이템 원천
고객 및 공급업체 마스터	고객과 공급업체 레코드가 분리	비즈니스 파트너가 필수
자재 번호	18자	확장 길이를 켜면 최대 40자
여신 관리	SD 여신 관리	SAP Credit Management(FIN-FSCM)
사용자 인터페이스	SAP GUI	SAP Fiori 앱, 온프레미스와 Private Edition에서는 SAP GUI도 계속 사용 가능
배포 방식	온프레미스	온프레미스, Private Edition(RISE with SAP), Public Edition(GROW with SAP)
확장	Z 프로그램과 수정	Clean Core: 릴리스된 API, 온스택 ABAP Cloud 또는 SAP BTP의 사이드 바이 사이드
유지보수	EHP 6~8은 메인스트림이 2027년 말까지, 연장 시 2030년 말까지	2040년 말까지 약속

SAP는 이 차이 하나하나를 단순화 항목으로 기록하고, S/4HANA 릴리스마다 단순화 목록(Simplification List)으로 공개합니다. 비즈니스 파트너처럼 모든 고객에게 필수인 항목도 있습니다. 해당 기능을 쓸 때만 영향을 주는 항목도 있으며, 어떤 항목이 귀사 시스템에 적용되는지는 SAP Readiness Check가 알려 줍니다.

2023년에 제가 함께 일한 유럽 제조업 고객은 전환 후 커스텀 배치 작업이 왜 더 이상 작동하지 않는지 계속 물었습니다. 그 로직은 S/4HANA에서 바뀐 ECC 테이블 구조에 의존하고 있었습니다. 새 모델에서 그 작업이 여전히 의미가 있는지 아무도 묻지 않았습니다.

마이그레이션은 데이터를 옮깁니다. 진짜 질문은 물려받은 설계 결정을 어떻게 처리하느냐입니다.

제가 고르는 원칙은 간단합니다. 다른 시스템에서 옮겨 오거나 새 프로세스를 정의해야 할 때는 그린필드입니다. 프로세스가 정의되어 잘 작동할 때는 브라운필드, 일부 영역의 프로세스를 다시 정의해야 할 때는 선택적 데이터 전환입니다.

Decide

귀사 상황에 맞는 ECC에서 S/4HANA로의 경로는 무엇인가

→그린필드

다른 시스템에서 옮겨 오거나 새 프로세스를 정의해야 함

→브라운필드

프로세스가 정의되어 잘 작동함

→선택적 데이터 전환

일부 영역만 프로세스를 다시 정의해야 함

그린필드: 신규 구축

S/4HANA를 새로 구축하는 방식입니다. 기존 설정은 가져가지 않고, 프로세스는 SAP 표준에 맞춰 설계하며, 필요한 데이터만 적재합니다.

현재 사업의 일부가 SAP가 아닌 시스템에서 돌아가고 있다면 자연스러운 선택입니다. 그린필드 시스템에서 업무 감각이 얼마나 달라지는지 사용자에게 미리 준비시키지 않아 후회하는 회사를 저는 보았습니다. 정착 계획이 교육 단계에서 시작된다면 이미 늦은 것입니다.

브라운필드: 시스템 전환

브라운필드는 시스템 전환입니다. 기존 ECC 시스템을 그 자리에서 전환하며, 설정, 커스텀 코드, 이력이 함께 옮겨 갑니다. 기술적 전환은 Software Update Manager(SUM)와 그 데이터베이스 마이그레이션 옵션으로 수행합니다.

SAP는 릴리스마다 SAP S/4HANA Conversion Guide를 공개하며, 여기에는 전제 조건과 기술 단계의 순서가 담겨 있습니다. 날짜를 계획하기 전에 목표 릴리스의 가이드를 읽으십시오. 위험은 함께 가져가는 기술 부채입니다. 의도적으로 정리하지 않으면 기존의 복잡성도 그대로 따라옵니다.

선택적 데이터 전환

선택적 데이터 전환은 전부가 아니라 선택한 회사 코드, 사업 단위 또는 데이터의 기간만 옮깁니다. 전문 도구와 이 방식에 경험이 있는 파트너가 필요합니다. 일부 벤더는 이를 "블루필드"라는 이름으로 판매합니다.

재무는 잘 돌아가지만 구매는 재설계가 필요한 그룹, 또는 인수합병과 카브아웃으로 매우 다른 프로세스가 나란히 남아 있는 그룹에 맞습니다. 필요한 영역은 재설계하고, 중요한 곳에서는 이력을 유지할 수 있습니다.

이사회가 흔히 묻는 질문을 기준으로 세 가지를 비교하면 다음과 같습니다.

경로	선택할 때	일반적인 일정	주요 위험
그린필드	다른 시스템에서 옮겨 오거나 새 프로세스를 정의해야 함	18~24개월	사용자의 변화 부담, 남겨 두는 이력
브라운필드	프로세스가 정의되어 잘 작동함	12~18개월	기술 부채와 쓰지 않는 커스텀 코드를 그대로 가져감
선택적 데이터 전환	일부 영역의 프로세스를 다시 정의해야 함	12~18개월	전문 도구와 파트너에 대한 의존, 복잡한 데이터 범위 설정

경로에 따라 세부 사항은 달라지지만 순서는 같습니다. 제가 계획하는 다섯 단계를 순서대로 소개합니다.

마이그레이션 순서

1. 01

   Readiness Check

   SAP Readiness Check를 실행하고 기술적 전제 조건을 확인합니다.

2. 02

   경로 선택과 계획

   경로를 고르고 범위를 정한 뒤, 빌드를 시작하기 전에 프로그램 전체를 계획합니다.

3. 03

   커스텀 코드

   쓰이는 것을 찾고, 나머지는 폐기하고, 남는 것을 조정합니다.

4. 04

   데이터

   무엇이든 옮기기 전에 분류, 정제, 아카이빙합니다.

5. 05

   테스트와 컷오버

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

1. Readiness Check 실행

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

예상하지 못한 문제는 대개 애드온과 커스텀 코드입니다. 제가 함께 일한 일부 고객은 범위 안에 커스텀 오브젝트가 수백 개 있었습니다. 열두 번째 달보다 두 번째 주에 찾는 편이 낫습니다.

브라운필드 전환이라면 다음 전제 조건도 함께 확인하십시오.

1. 릴리스: 전환은 어떤 인핸스먼트 패키지든 SAP ERP 6.0에서 가능합니다.
2. 유니코드: 시스템은 유니코드여야 하며, 그렇지 않으면 2단계 전환을 계획합니다.
3. 듀얼 스택: 듀얼 스택 시스템은 먼저 분리해야 합니다.
4. 비즈니스 파트너: 고객 마스터와 공급업체 마스터는 전환 전에 비즈니스 파트너로 변환해야 합니다. 다른 어떤 항목보다 많은 팀이 여기서 걸립니다.

2. 경로 선택과 프로그램 계획

Readiness Check 결과와 위에서 말한 제 원칙으로 경로를 고릅니다. 그런 다음 누구든 빌드를 시작하기 전에 데이터, 테스트, 컷오버를 포함한 프로그램 전체를 계획합니다.

제가 이끌었거나 회생시킨 21개의 SAP 프로그램을 통틀어, 가장 큰 마이그레이션 실수는 구축 초기에 마이그레이션을 제대로 계획하지 않는 것입니다. 데이터 정제의 책임자가 누구인지, 어떤 커스텀 코드를 폐기할지, 컷오버 리허설을 언제 할지를 처음 몇 주 안에 정하십시오. 이런 결정은 늦게 내릴수록 비용이 큽니다.

3. 커스텀 코드 조정

ABAP Test Cockpit에서 S/4HANA 점검을 실행해 귀사의 코드를 SAP의 단순화 항목과 비교합니다. Custom Code Migration 앱은 같은 결과를 사용 데이터와 함께 보여 주므로, 무엇을 고치기 전에 무엇이 실제로 쓰이는지 볼 수 있습니다.

목표는 작동하는 Z 코드가 아니라 더 적은 Z 코드입니다. 한 프로그램에서는 smartShift 분석으로 커스텀 오브젝트를 18,000개에서 3,200개로 줄였습니다.

가져가는 커스텀 오브젝트 하나하나가 앞으로의 모든 업그레이드에 비용을 더합니다. Clean Core 원칙으로 업그레이드 기간을 40% 줄인 회사를 저는 보았습니다. 남는 것을 분류하는 방법은 제 SAP Clean Core 가이드에서 다룹니다.

4. 데이터 준비와 이관

무엇이든 옮기기 전에 분류, 정제, 아카이빙하십시오. 이 단계는 어떤 계획이 잡아 둔 것보다 오래 걸리므로 아래에 별도 섹션으로 다룹니다.

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

테스트는 단계별로 진행합니다. 단위 테스트, 통합 테스트, 사용자 인수 테스트(UAT), 그리고 최소 한 번의 전체 컷오버 리허설입니다. UAT에는 파워 유저와 가끔 쓰는 사용자를 모두 넣으십시오. 찾아내는 문제가 다르기 때문입니다.

리허설은 선택 사항이 아닙니다. 전체 순서를 실제로 돌려 볼 때만 드러나는 시간 차이, 누락된 검증, 인터페이스 장애를 드러냅니다. 리허설을 건너뛴 팀은 Go-Live 주말에 그 문제를 만납니다.

제 경험상 데이터 마이그레이션은 구축 공수의 30~40%를 차지합니다. 일정이 밀리는 가장 흔한 이유이기도 합니다.

데이터를 옮기는 방법은 경로에 따라 다릅니다. 브라운필드에서는 SUM이 데이터를 그 자리에서 전환합니다. 그린필드에서는 SAP S/4HANA Migration Cockpit으로 마스터 데이터와 미결 항목을 적재하고, 선택적 데이터 전환에서는 전문 도구가 선택한 범위를 옮깁니다.

어떤 경로든 옮기기 전에 데이터를 분류하십시오.

1. 핫: 자주 쓰이며 실시간 처리에 필요한 데이터.
2. 웜: 가끔 조회되며, 관련은 있지만 매일 쓰지는 않는 데이터.
3. 콜드: 과거 데이터나 쓰지 않는 데이터로, 감사 목적으로만 보관하는 것.

콜드 데이터는 S/4HANA에 넣을 필요가 없습니다. 아카이빙하십시오. 중복된 공급업체 레코드, 일관되지 않은 단위, 절반만 채워진 고객 마스터는 모든 ECC 시스템에 있으며, 누군가 먼저 고치지 않으면 그대로 S/4HANA로 옮겨 갑니다.

제가 함께 일한 한 고객은 데이터 정제와 아카이빙에만 5개월을 썼습니다. 이 단계는 SAP 데이터 마이그레이션이 실패하는 이유에 관한 제 글에서 더 깊이 다룹니다.

ECC에서 S/4HANA로 가는 프로그램에서 제가 사용한 다섯 가지 도구입니다. 두 가지는 SAP 자체 도구이고 세 가지는 전문 벤더의 도구입니다.

도구	제공사	기능	쓰는 시점
SAP Readiness Check for SAP S/4HANA	SAP	단순화 항목, 애드온 호환성, 커스텀 코드 영향, 데이터 볼륨, 사이징을 보고	경로를 고르기 전
Custom Code Migration 앱	SAP	S/4HANA ABAP Test Cockpit 점검을 실행하고 사용 데이터로 쓰지 않는 코드를 찾는 SAP Fiori 앱. S/4HANA 또는 SAP BTP ABAP 환경에서 실행	커스텀 코드 범위 설정과 조정
smartShift	smartShift Technologies	S/4HANA용 ABAP 커스텀 코드의 자동 분석과 변환	커스텀 코드 분석과 수정
SNP(Kyano 플랫폼)	SNP Group	SNP의 "Bluefield" 접근 방식으로 판매되는 선택적 데이터 전환용 데이터 변환 소프트웨어	선택적 데이터 전환, 인수합병, 카브아웃
Natuvion	Natuvion Group	S/4HANA 전환을 위한 데이터 변환 소프트웨어와 컷오버 도구	선택적 데이터 전환과 컷오버

SNP와 Natuvion은 모두 SAP의 Selective Data Transition Engagement 커뮤니티 창립 멤버입니다. 그 밖에 만나게 될 SAP 도구는 브라운필드 전환에 쓰는 SUM과 그린필드 데이터 적재에 쓰는 Migration Cockpit입니다.

도구가 결정을 대신하지는 않습니다. 무엇을 폐기할지는 여전히 귀사 쪽 누군가가 합의해야 합니다.

인핸스먼트 패키지 6~8의 SAP ERP 6.0은 메인스트림 유지보수가 2027년 12월 31일에 끝납니다. 선택적 연장 유지보수는 2028년부터 2030년 12월 31일까지이며, 기존 유지보수 기준 금액에 2%p의 할증이 붙습니다(SAP News).

2030년 이후에는 좁은 길이 하나 있습니다. SAP ERP, private edition 전환 옵션입니다. RISE with SAP 아래에서 ECC 시스템을 SAP HANA 기반의 SAP ERP, private edition으로 SAP 프라이빗 클라우드에 옮기는 고객에게 2031~2033년 유지보수를 제공합니다. 시스템은 2030년 12월 31일 이전에 옮겨야 하고, 최소 2 TB 이상이어야 하며, SAP의 max success plan이 필요합니다.

따라서 2033년은 일반적인 기한이 아닙니다. 이미 ECC를 SAP 클라우드로 옮긴 대형 시스템에 적용됩니다. 그 밖의 모든 고객에게 자체 인프라의 ECC는 2027년이 메인스트림 기한이고 2030년이 연장 유지보수 종료입니다.

1. 2027ECC 메인스트림 유지보수 종료12월 31일, SAP ERP 6.0 EHP 6~8 대상
2. 2028지금 시작할 경우 예상 가동 시점브라운필드 12~18개월, 그린필드 18~24개월
3. 2030연장 유지보수 종료선택 사항, 2%p 할증
4. 2033전환 옵션 종료SAP ERP, private edition만 해당, 2 TB 이상 시스템

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

계산은 간단합니다. 최소한 일정 기간의 연장 유지보수 예산을 잡고, 그 시간을 기다리는 데가 아니라 데이터 정제와 커스텀 코드 폐기에 쓰십시오.

비용은 일정과 같은 요인을 따릅니다. 경로, 커스텀 코드의 양, 데이터 상태, 그리고 가동하는 법인의 수입니다. 데이터만으로도 공수의 30~40%를 차지하므로, 깔끔한 데이터 계획은 어떤 단가 협상보다 많은 비용을 아껴 줍니다. 제 S/4HANA 마이그레이션 비용 가이드는 마이그레이션 예산을 좌우하는 요인을 다루고, 제 SAP 구축 비용 가이드는 회사 규모별로 예산을 나누어 설명합니다.

한 프로그램이 실제로 어떻게 진행됐는지는 제 ECC에서 S/4HANA로의 마이그레이션 사례 연구를 읽어 보십시오. 귀사의 선택지를 점검하려면 그린필드와 브라운필드 마이그레이션 평가를 해 보십시오.

이 글은 개요입니다. 아래 가이드는 각각 하나의 질문에 온전히 답합니다.

1. S/4HANA 마이그레이션 일정과 프로젝트 계획: 경로별, 단계별 계획과 모의 전환, 컷오버.
2. S/4HANA 마이그레이션 비용: 시스템 전환, 신규 구축, 선택적 전환에서 예산을 좌우하는 요인.
3. SAP Readiness Check와 마이그레이션 평가: 점검이 알려 주는 것과 놓치는 것.
4. SAP S/4HANA Migration Cockpit 단계별 가이드: 스테이징 테이블 또는 직접 전송으로 데이터를 로드하는 방법.
5. RISE with SAP: 퍼블릭 대 프라이빗 클라우드: 귀사 프로세스에 맞는 에디션.
6. RISE with SAP 계약과 가격: 구독이 다루는 것과 협상할 항목.
7. S/4HANA 마이그레이션 파트너 선택 방법: 물어야 할 질문과 경고 신호.
8. SAP 프로젝트 회복: 궤도를 벗어난 마이그레이션을 구하는 방법.

숫자를 잡는 데는 두 가지 도구가 도움이 됩니다. SAP 구축 비용 계산기와 데이터 마이그레이션 추정 도구입니다.

SAP ECC란 무엇입니까?

SAP ECC(SAP ERP Central Component)는 SAP Business Suite 7의 일부인 SAP ERP 6.0의 핵심입니다. 재무회계, 관리회계, 물류 등 핵심 프로세스를 다루며 여러 데이터베이스에서 실행됩니다. SAP S/4HANA는 그 후속 제품이며 SAP HANA에서만 실행됩니다.

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

제 경험상 브라운필드 전환은 12~18개월, 그린필드 구축은 18~24개월, 선택적 데이터 전환은 12~18개월이 걸립니다. 데이터 마이그레이션이 구축 공수의 30~40%를 차지하기 때문에 데이터 정제가 일정이 밀리는 가장 흔한 이유입니다.

2027년 이후 SAP ECC는 어떻게 됩니까?

인핸스먼트 패키지 6~8의 SAP ERP 6.0은 메인스트림 유지보수가 2027년 12월 31일에 끝납니다. 2%p를 추가로 내면 2030년 12월 31일까지 선택적 연장 유지보수를 구매할 수 있습니다. 2031~2033년 유지보수는 SAP ERP, private edition 전환 옵션을 통해서만 제공되며, 2030년 말 이전에 SAP 프라이빗 클라우드로 옮긴 대형 시스템이 대상입니다.

브라운필드와 그린필드 중 어느 쪽이 더 낫습니까?

일반적으로 어느 쪽이 더 낫다고 할 수는 없습니다. 다른 시스템에서 옮겨 오거나 새 프로세스를 정의해야 하면 그린필드를, 프로세스가 정의되어 잘 작동하면 브라운필드를 고르십시오. 일부 영역만 재설계가 필요하다면 선택적 데이터 전환을 검토하십시오.

SAP의 선택적 데이터 전환이란 무엇입니까?

선택적 데이터 전환은 모든 것을 전환하거나 빈 상태에서 시작하는 대신, 선택한 회사 코드, 사업 단위 또는 데이터의 기간을 S/4HANA로 옮깁니다. 일부 영역은 재설계하면서 다른 영역의 이력은 유지할 수 있습니다. SNP나 Natuvion 같은 전문 도구와 경험 있는 파트너가 필요합니다.

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

전환은 어떤 인핸스먼트 패키지든 SAP ERP 6.0에서 가능합니다. 시스템은 유니코드여야 하며, 그렇지 않으면 2단계 방식을 씁니다. 듀얼 스택 시스템은 먼저 분리해야 합니다. 고객 마스터와 공급업체 마스터는 전환 전에 비즈니스 파트너로 변환해야 합니다.

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

ECC 시스템을 분석해 영향을 주는 단순화 항목, 애드온 호환성, 커스텀 코드 영향, 데이터 볼륨, HANA 사이징을 보고합니다. 일찍 실행하십시오. 팀이 의존하는지도 몰랐던 애드온과 커스텀 코드를 발견하는 일이 흔하기 때문입니다.

ECC 마이그레이션에는 RISE with SAP와 GROW with SAP 중 무엇을 골라야 합니까?

커스텀 코드가 많고 프로세스가 복잡한 ECC 고객 대부분은 RISE with SAP 아래의 S/4HANA Cloud Private Edition으로 갑니다. 이 방식은 기존 시스템의 전환을 지원합니다. GROW with SAP는 Public Edition을 사용하며, 이는 표준 프로세스와 릴리스된 API 확장만 쓰는 신규 구축입니다. SAP 표준을 받아들일 의지가 있는 회사에 맞습니다.