Migration Guide

Preparing for SAP ECC 6.0 to SAP S/4HANA Migration: System Assessment & Hardware Sizing

By PythonMate Engineering Team•January 2025•15 min read

In this comprehensive guide, we'll break down the key steps you need to take, including hardware sizing using SAP Quick Sizer Tool, custom code analysis with SAP Custom Code Migration App, and data volume management for optimal system efficiency.

The S/4HANA migration process is one of the most critical phases for any SAP ECC 6.0 system. The hardware sizing, custom code analysis, and data volume management are crucial to ensure smooth performance and compliance with SAP HANA database requirements.

Hardware Sizing with SAP Quick Sizer Tool

The SAP Quick Sizer is your first stop in determining your HANA hardware requirements. It helps calculate the required memory and CPU specifications based on your current ECC landscape data.

Why Traditional Sizing Often Falls Short

Many organizations rely on Quick Sizer alone, but this approach often misses critical data issues:

  • ⚠️Quick Sizer calculates based on DB02 tables, but doesn't distinguish between hot/cold data
  • ⚠️SOFFCONT1 bloat can cause 30-70% inflation in memory requirements
  • ⚠️Broken attachment links can cause performance degradation after migration

Standard Quick Sizer Approach

  • Calculates based on total table sizes only
  • Doesn't account for cold data in SOFFCONT1
  • May recommend oversized HANA tier

PythonMate Enhanced Sizing

  • Distinguishes hot vs cold data volumes
  • Identifies TB-scale content for external archiving
  • Optimizes HANA tier to minimize costs

Step-by-Step Hardware Sizing Process

  1. 1.
    Export Current System Data - Extract DB02 statistics, table sizes, and growth trends from your ECC system
  2. 2.
    Run SAP Quick Sizer - Input current data into SAP's sizing tool to get baseline HANA requirements
  3. 3.
    Analyze SOFFCONT1 Content - Deep analysis to identify cold data that can be moved to external storage
  4. 4.
    Calculate Optimized Requirements - Adjust Quick Sizer results based on removable content
  5. 5.
    Validate with Python Tools - Use our parallel processing engine to validate sizing assumptions against real data

Custom Code Analysis with SAP Custom Code Migration App

The SAP Custom Code Migration app (SCMTA) is essential for identifying custom developments that need adaptation when moving to S/4HANA. This application helps you analyze and prepare your custom code for the new environment.

Common Pitfalls in Custom Code Analysis

Many organizations underestimate the impact of custom code changes during migration. Here are the typical issues:

  • ⚠️ABAP code using deprecated database views may fail
  • ⚠️Custom code accessing removed or modified tables will break
  • ⚠️Performance of custom programs may degrade on HANA
🔍

Code Analysis

Identify all custom developments

🔧

Adaptation

Modify code for S/4HANA compatibility

✅

Validation

Test functionality in new environment

PythonMate's Approach to Custom Code Assessment

While the SAP Custom Code Migration app is essential for functional code, we go deeper into content layer analysis using Python tools to identify issues with:

  • •SRGBTBREL table integrity and broken links
  • •SOFFCONT1 bloat with orphaned attachments
  • •ArchiveLink repository ID mismatches
  • •GOS object-internal attachment validation

Data Volume Management for Optimal Efficiency

Managing data volume is critical to achieving optimal performance in S/4HANA with HANA database. This involves identifying and handling "cold" data that doesn't need to be migrated along with active business data.

The "HANA Tax" Reality

The Problem

  • •HANA RAM costs 100x more than disk storage
  • •2TB cold attachments → jump from 2TB to 4TB HANA tier
  • •Result: $200k+ annual licensing cost increase

The Solution

  • ✓Identify & remove cold content before migration
  • ✓Move attachments to cloud storage (S3, Azure)
  • ✓Reduce HANA footprint by 30-70%

Python-Based Data Volume Assessment Process

Phase 1: Content Audit (Days 1-3)

Using Python parallel processing to scan TB-scale SOFFCONT1 tables efficiently

  • •Count total attachment records
  • •Identify orphaned files (no business object association)
  • •Profile age distribution (1-year, 5-year, etc.)
  • •Map SRGBTBREL link integrity

Phase 2: Cold Data Identification (Days 4-5)

Using Python pandas to analyze access patterns and retention requirements

  • •Apply retention policies (7-year for pharma, 5-year for finance)
  • •Identify documents not accessed in >2 years
  • •Create archive candidate list
  • •Calculate HANA cost savings potential

Phase 3: Migration Preparation (Days 6-7)

Prepare for safe extraction and external archiving

  • •Validate document checksums (SHA256)
  • •Map new repository locations (S3, Azure)
  • •Generate repair scripts for broken links
  • •Create reconciliation reports

Python-Based Solutions for Content Layer Challenges

The "ABAP Memory Trap" prevents standard tools from efficiently processing TB-scale content. Python bypasses these limitations by operating externally to SAP.

The Hidden Risks (Why SIs Avoid This)

  • •SRGBTBREL broken links during GOS → SFSOBJ transition
  • •SOFFCONT1 orphaned records after data aging
  • •ArchiveLink repository ID mismatches in parallel systems
  • •GOS object-internal attachment corruption

PythonMate's Python-First Approach

  • •Parallel pyrfc workers for TB-scale processing
  • •Read-only access, no ABAP modifications
  • •100x faster than standard ABAP batch programs
  • •SHA256 validation for 100% integrity

Content Layer Assessment Checklist

Pre-Migration Validation

  • Scan SOFFCONT1 for orphaned records
  • Validate SRGBTBREL link integrity
  • Check ArchiveLink repository consistency
  • Verify GOS attachment accessibility

Post-Migration Verification

  • Reconcile document counts before/after
  • Validate link integrity post-migration
  • Confirm archive connections work
  • Run checksum verification

Python-Based Solutions for Content Layer Challenges

The "ABAP Memory Trap" prevents standard tools from efficiently processing TB-scale content. Python bypasses these limitations by operating externally to SAP.

The Hidden Risks (Why SIs Avoid This)

  • SRGBTBREL broken links during GOS → SFSOBJ transition
  • SOFFCONT1 orphaned records after data aging
  • ArchiveLink repository ID mismatches in parallel systems
  • GOS object-internal attachment corruption

PythonMate's Python-First Approach

  • Parallel pyrfc workers for TB-scale processing
  • Read-only access, no ABAP modifications
  • 100x faster than standard ABAP batch programs
  • SHA256 validation for 100% integrity

Content Layer Assessment Checklist

Pre-Migration Validation

  • Scan SOFFCONT1 for orphaned records
  • Validate SRGBTBREL link integrity
  • Check ArchiveLink repository consistency
  • Verify GOS attachment accessibility

Post-Migration Verification

  • Reconcile document counts before/after
  • Validate link integrity post-migration
  • Confirm archive connections work
  • Run checksum verification

Python vs ABAP Performance Comparison

TB-scale processing comparison - Python never slows down your SAP

/* ABAP Memory-Limited */
REPORT Z_ATTACHMENT_MIGRATION.
SELECT * FROM SOFFCONT1 INTO TABLE lt_data UP TO 2000000 ROWS.
// SYSTEM_NO_ROLL dump on TB-scale data
// Crashes after 2M records - memory exhaustion
/* Python Parallel Streaming (pyrfc) */
from pyrfc import Connection
from multiprocessing.pool import Pool
conn = Connection(dest='SAP_SYSTEM')
with Pool(processes=15) as pool:
results = pool.map(extract_batch, batch_list)
// TB-scale streams externally
// Unlimited RAM on external server

PythonMate's 7-Day Health Check Process

Days 1-3

Passive Scan

No ABAP. Use pyrfc/OData to scan SOFFCONT1, SRGBTBREL, GOS

Day 4

Findings

Technical findings & CFO one-pager with HANA TCO calculation

Day 5

Scope

Fixed-price remediation plan with per-TB pricing

Days 6-7

Delivery

Final health check report + sales handoff

What We Guarantee vs What We Don't

✓ We Guarantee

  • Attachment integrity (SOFFCONT1 + SRGBTBREL)
  • Data validation & checksum accuracy
  • Migration readiness of content layer

✗ We Don't Guarantee

  • Full migration success (functional/process layers)
  • Third-party tool compatibility
  • Other SIs' deliverables

Python Technical Moat: Why Only Python?

Three technical advantages that make Python 100x faster and safer than ABAP for TB-scale processing:

The ABAP Memory Trap (S_S31, S_S32, S_S35)

Standard ABAP programs run inside SAP application server. Limited by SAP memory parameters (Heap/Stack). Processing 2TB of attachments causes SYSTEM_NO_ROLL dumps.

Python External Processing

Runs outside SAP. Uses external RAM. Processes TB-scale data without impacting core system.

ABAP vs Python Performance Comparison

ABAP Limitations
  • Memory-limited (crash on TB-scale)
  • Risk of core modifications
  • Sequential processing (slow)
  • Security gate delays
Python Advantages
  • External memory (no limits)
  • No core changes (zero risk)
  • Parallel streaming (100x faster)
  • IT Security approved

Client Targeting: The "Bleeding Neck" Market

Primary: ECC → S/4HANA Migration

Moving to S/4 forces expensive HANA RAM purchases

  • Trigger: Moving to S/4HANA forces HANA RAM purchase
  • HANA RAM costs 100x more than disk storage
  • 2TB cold attachments → Jump from 2TB to 4TB HANA tier
  • Result: $200k/year in extra licensing

Secondary: Post S/4HANA Clients

Already shocked by monthly HANA bills

  • Want to downgrade their "T-Shirt" HANA licensing tier
  • Move cold data to cloud storage (S3, Azure)
  • ROI quantification dashboard
  • "Pay $50k once → Save $200k/year forever"

Ready for Your 7-Day Health Check?

Fixed-price 7-Day Assessment • CFO-grade ROI calculation • Limited liability • Milestone payments • No ABAP, Zero Downtime

Start Your Free Health Check

Strict NDA • No ABAP required • Guaranteed impact