S4hana Migration

S/4HANA Migration Strategy

This skill enforces structured S/4HANA migration decision-making so that no approach recommendation is made without analyzing simplification items, custom code volume, and disruption tolerance — the three inputs that determine whether a migration succeeds or becomes a production crisis.

Iron Laws

1. NEVER RECOMMEND AN APPROACH WITHOUT ANALYZING SIMPLIFICATION ITEMS. Greenfield, brownfield, and selective data transition are not stylistic preferences. The simplification item catalogue for the client's active modules determines feasibility. A recommendation without this analysis is a guess with a logo on it.
2. NEVER ESTIMATE WITHOUT CUSTOM CODE ANALYSIS. Timeline and cost are dominated by custom code remediation. A 500,000-line Z-namespace landscape requires a fundamentally different plan than a 5,000-line landscape. Volume, category, and remediation complexity must be quantified.
3. ALWAYS CONSIDER DISRUPTION TOLERANCE. A technically optimal greenfield approach that requires 18 months of parallel operation may be organizationally impossible for a 24/7 manufacturing business. Disruption tolerance is a constraint, not a preference.
4. READINESS CHECK BEFORE APPROACH DECISION. SAP Readiness Check output (or equivalent assessment) must exist before any migration approach is recommended. Skipping it means recommending without data.
5. TCO COMPARISON IS MANDATORY. Migration approach without a 5-year TCO is incomplete. Cloud vs on-premise, greenfield vs brownfield, licensing model changes — each combination produces a materially different cost profile.

Rationalization Table

Red Flags

Watch for these phrases in your own reasoning — each one signals you are about to violate an Iron Law:

• "The client is a good candidate for greenfield..." → You have not checked simplification items or custom code volume. Stop.
• "We can do a quick brownfield migration and clean up later..." → 'Clean up later' is where migrations go to die. Stop.
• "Timeline is roughly X months..." → Roughly is not a timeline. Decompose by phase and custom code waves. Stop.
• "Custom code impact is probably manageable..." → Probably is not an analysis. Run custom code analysis. Stop.
• "We'll assess the Readiness Check later in Prepare..." → Later means you are recommending without data. Stop.
• "Selective gives them the best of both worlds..." → This phrase signals selective complexity is being understated. Stop.
• "TCO will be similar to current state..." → This claim requires a model. Build one. Stop.

Hard Gates

Checklist

Step 1: Landscape and Business Driver Assessment

Establish the why and the what before the how.

• Business Driver: Deadline (ECC maintenance end), transformation initiative, cloud mandate, or cost optimization?
• Current Landscape: ECC version, support pack level, database type (AnyDB vs HANA), operating system
• Module Footprint: Which SAP modules are active, which are heavily customized, which are lightly used?
• Organizational Scope: Company codes, plants, countries, legal entities, languages
• Integration Map: Count and complexity of inbound/outbound interfaces. EDI, middleware, point-to-point.
• Data Volume: DB size, largest tables, archiving posture, data retention requirements

Evidence: Landscape summary document with all six categories populated. Gate: Business driver is explicitly documented and agreed with the client stakeholder.

Step 2: SAP Readiness Check and Simplification Item Analysis

Run or review SAP Readiness Check output.

• Simplification Item Catalogue: Export from Readiness Check. Group by: Mandatory remediation, Functional change, Performance change, Information only.
• High-Impact Items: Flag items that affect Universal Journal migration, Material Ledger activation, Business Partner migration, House Bank migration, Customer/Vendor Integration.
• Module-Level Impact: Score each module area: Green (minimal impact), Amber (moderate — 2-4 week remediation), Red (significant — 5+ weeks or process redesign required).
• Custom Namespace Review: List all Z/Y objects referenced in simplification items. These are the highest-risk items.

Evidence: Simplification item register with impact classification per module. Gate: No module marked Red proceeds to approach decision without a specific remediation plan.

Step 3: Custom Code Analysis

Quantify and categorize all custom development.

• Total Object Count: Programs, function modules, classes, BAdIs, enhancements, customer exits, SmartForms, Adobe forms, reports
• ABAP Test Cockpit Results: Run ATC with S/4HANA compatibility check profile. Classify findings: Errors (must fix), Warnings (should fix), Info (review)
• Custom Code Volume by Module: Assign objects to business areas. Identifies which workstreams carry the most remediation risk.
• Remediation Effort Estimation: Apply effort per finding category. Errors: 0.5-2 days average. Warnings: 0.25-1 day average. Aggregate by module.
• Candidate for Retirement: Identify objects that duplicate standard functionality now available in S/4HANA. Retirement reduces remediation scope.

Evidence: Custom code analysis report with object counts, ATC results, effort estimates by module, and retirement candidates. Gate: Remediation effort estimate exists in days (not percentages) before timeline is built.

Step 4: Migration Approach Selection

Select and justify the migration approach using all prior inputs.

Greenfield (New Implementation):

• Appropriate when: High simplification item count, high custom code debt, business process transformation desired, organization has capacity for re-implementation
• Risk: Loss of embedded business logic, higher project cost, longer timeline, change management intensity
• Indicator: More than 30% of custom objects are retirement candidates; major process redesign planned

Brownfield (System Conversion):

• Appropriate when: Low-to-medium simplification item count, manageable custom code remediation, business continuity is paramount, process designs are fit-for-purpose
• Risk: Technical debt migrates with the system, clean-core compliance requires post-migration remediation program
• Indicator: ATC error rate under 15% of total objects; organization cannot absorb full reimplementation

Selective Data Transition (Bluefield/Mixed):

• Appropriate when: Partial process redesign required, subset of data should not migrate, merger/demerger scenarios, specific legal entities or company codes need different treatment
• Risk: Most complex approach — requires specialist tooling (SNP, Natuvion, or equivalent), precise data scoping, reconciliation effort
• Prerequisites: Tooling vendor selected, data scope document signed off, reconciliation framework agreed

Evidence: Approach recommendation document with selection rationale mapped to Readiness Check and custom code analysis inputs. Gate: Approach is backed by data from Steps 1-3, not stated as a default preference.

Step 5: Timeline and Phasing Model

Build a phase-level timeline using custom code analysis as the primary variable.

Phase structure aligned to SAP Activate:

• Prepare: Environment setup, team onboarding, custom code freeze, governance
• Explore: Fit-to-Standard workshops, delta design, remediation backlog finalization
• Realize: Custom code remediation (Wave 1: mandatory fixes), configuration, integration build
• Realize Extension: Custom code remediation (Wave 2: warnings), unit testing, integration testing
• UAT and Performance: User acceptance testing, performance testing, cutover rehearsals
• Deploy: Cutover execution, go-live, hypercare

For each phase, provide:

• Duration in weeks (range: optimistic / realistic / pessimistic)
• Key dependencies and critical path items
• Resource requirements (FTE by role)
• Risks that would extend this phase

Evidence: Phase timeline table with week ranges, critical path identified, and at least 2 dry run cutover cycles planned. Gate: Custom code remediation waves are sequenced and capacity-planned against available ABAP developer headcount.

Step 6: TCO and Business Case

Build a 5-year TCO comparison.

• Current State Costs: ECC licensing, infrastructure, support, maintenance, custom code upkeep
• Migration Investment: Project cost (consulting, license, infrastructure, internal effort, change management)
• Future State Costs (per approach): S/4HANA licensing model (on-premise vs RISE/GROW), infrastructure (owned vs cloud), reduced customization maintenance
• Risk-Adjusted Scenarios: What does timeline overrun of 3 months cost? What is the cost of a failed cutover?
• Break-Even Point: When does cumulative benefit exceed migration investment?

Evidence: TCO comparison model with current state, migration investment, and 5-year future state for each migration approach option being considered. Gate: Business case must show a positive NPV scenario within 5 years. If it does not, document why the migration is still required (regulatory, EOM support).

Step 7: Generate Migration Strategy Document

Assemble the deliverable using the template below.

Evidence: Complete migration strategy document. Gate: All Hard Gate conditions met and all six steps have documented evidence.

Deliverable Template

# S/4HANA Migration Strategy
**Client:** [Name]
**Date:** [Date]
**Prepared by:** [Consultant]
**Version:** [1.0]

## Executive Summary
[2-3 sentence summary: current state, recommended approach, headline timeline and investment]

## Landscape Assessment
### Current SAP Environment
| Parameter | Value |
|-----------|-------|
| ECC Version | |
| Database | |
| DB Size | |
| Active Modules | |
| Company Codes / Plants | |
| Integration Count | |

### Business Drivers
[Ranked list of drivers: compliance, transformation, cost, etc.]

## Simplification Item Analysis
| Module Area | Item Count | Mandatory Remediation | Effort Estimate | RAG |
|-------------|-----------|----------------------|-----------------|-----|

### Critical Simplification Items
[Detail the top 5 highest-impact items with remediation approach]

## Custom Code Analysis
| Metric | Value |
|--------|-------|
| Total Custom Objects | |
| ATC Errors (must fix) | |
| ATC Warnings (should fix) | |
| Retirement Candidates | |
| Estimated Remediation Effort | [days] |

### Custom Code by Module
[Table: module, object count, error count, remediation days]

## Migration Approach Recommendation
**Recommended Approach:** [Greenfield / Brownfield / Selective]

### Justification
[Structured rationale referencing simplification item data and custom code analysis]

### Approach Comparison
| Criterion | Greenfield | Brownfield | Selective |
|-----------|-----------|-----------|-----------|
| Timeline | | | |
| Cost | | | |
| Risk | | | |
| Business Disruption | | | |
| Clean Core Alignment | | | |

## Migration Timeline
| Phase | Duration | Key Deliverables | Dependencies |
|-------|----------|-----------------|--------------|
| Prepare | | | |
| Explore | | | |
| Realize (Wave 1) | | | |
| Realize (Wave 2) | | | |
| UAT | | | |
| Deploy | | | |

**Total Timeline:** [range] weeks
**Go-Live Target:** [date]
**Dry Run Cutovers:** [count]

## TCO Comparison
| Scenario | Year 1 | Year 2 | Year 3 | Year 5 | NPV |
|----------|--------|--------|--------|--------|-----|
| Current State (do nothing) | | | | | |
| Brownfield Migration | | | | | |
| Greenfield Migration | | | | | |

## Key Risks
| Risk | Probability | Impact | Mitigation |
|------|------------|--------|------------|

## Assumptions
[Numbered list of all assumptions underpinning this strategy]

## Recommended Next Steps
[3-5 specific actions with owners and deadlines]

Verification

This skill is complete ONLY when ALL of the following are true:

• SAP Readiness Check output reviewed and simplification items classified by module and RAG status
• Custom code analysis completed with object count, ATC results, and remediation effort in days
• Migration approach recommendation is backed by simplification item and custom code data (not stated as a default)
• Timeline is decomposed by phase with week ranges and custom code remediation waves sequenced
• TCO comparison exists for at least two approach options over a 5-year horizon
• Disruption tolerance documented and validated against proposed cutover window
• Migration strategy document generated using the deliverable template above

Evidence required: Migration strategy document with all sections populated, simplification item register, and custom code analysis report.

If any verification item is not met, the skill is NOT complete. Do not claim completion.

Next Skill

After completing this skill, invoke one of:

• activate-methodology — When transitioning from strategy into project execution planning across SAP Activate phases
• clean-core-strategy — When the migration approach is confirmed and custom code remediation needs a long-term clean-core roadmap
• rise-licensing — When the hosting model decision (RISE vs own infrastructure) requires detailed commercial analysis

Conditions for handoff: Migration approach is agreed, timeline is approved by the client, and the project is moving into detailed project planning.

Cross-References

• activate-methodology — For Activate phase gate criteria referenced in the timeline
• clean-core-strategy — For custom code remediation roadmap post-migration
• rise-licensing — For RISE with SAP commercial assessment
• estimation — For detailed effort estimation of individual workstreams
• project-kickoff — For project governance setup once approach is confirmed