Common pitfalls of SAP S/4HANA migration: lessons from an 8-month project

A larger Hungarian company's SAP ECC to S/4HANA brownfield migration, where we took part as a subcontractor. An 8-month project, with a 4-person core team on the client side and 2 people on ours. This article covers the 5 most important lessons learned, which may be useful to others. Plus the actual project timeline, the challenges, and what we would have done differently.

With SAP ECC end-of-mainstream-support approaching in 2027, 2026-2027 will see many similar brownfield migrations. This article offers concrete lessons to help with the preparation.

The client and the project

Anonymized: a mid-sized Hungarian company (250+ employees, over HUF 40 billion in annual revenue) had been running SAP ECC 6.0 for years. With ECC end-of-support arriving in 2027, it needed to migrate to S/4HANA — using a brownfield (in-place upgrade) approach so the existing customizing and data would be preserved.

Project scope

• From: ECC 6.0 EHP7
• To: S/4HANA 2023 (later updated to 2024 mid-project)
• Modules: FI/CO/MM/SD
• Custom codebase: 80+ Z programs
• Integrations: 12 external interfaces (banking, webshop, partner, EDI)
• User base: 180 named users
• Master data: ~30,000 materials, ~5,000 customers, ~2,000 vendors

The team

• Client: 4-person core team (1 PM, 1 functional lead, 1 ABAP developer, 1 BASIS admin)
• Us: 2 people as subcontractors (1 senior functional consultant, 1 ABAP developer)
• SAP consulting partner: 3 external consultants (Premium support partner)

The three-tier architecture

Production (PRD)  — live SAP ECC system
                   ↓ brownfield upgrade weekend
Production (PRD)  — live SAP S/4HANA system

Quality Assurance (QAS) — UAT, regression testing
Development (DEV)       — customizing, transport
Sandbox (SBX)           — experiments, proof-of-concept

The difference between brownfield and greenfield: with brownfield, the existing customizing, master data and transaction history are all preserved. Greenfield means a new tenant plus a separate data migration.

The real 9-month timeline (8 months plus a 1-month slip)

Month	Phase	Client side	Our side
1	Discovery	Audit, scope, sign-off	Audit support
2	Plan	High-level technical plan	Z-object audit
3-5	Master data cleanup	3 people full-time	1 person part-time
6	Custom code migration	2 people (ABAP + functional)	1 ABAP developer full-time
7	Integration testing	3 people	1 person part-time
8	UAT	8 key users	UAT support
9	Cutover + hyper-care	All hands	2 people full-time

The original plan called for 8 months; the actual project took 9 (a one-month slip, mainly due to master data and Z-object rewrites — see lessons 1 and 2).

Lesson 1: Master data cleanup takes longer than expected

The problem

Original estimate: 4 weeks. Actual: 11 weeks. That is a 177% overrun on this workstream.

The "dirty" data that had accumulated in ECC 6.0 over the years:

• Duplicate vendors — the same company spread across 3-4 different records (different spelling, city, IBAN)
• Inactive customers — created in 2010, unused since 2018; nobody had ever deleted them
• Incorrect material category — a partner export had been mismapped, leaving 2,000+ materials in the wrong category
• Formatting inconsistencies — IBAN numbers in 4 different formats
• Missing values — mandatory fields left NULL, which ECC tolerated but S/4HANA does not

Why this is more critical in S/4HANA

S/4HANA's Business Partner concept is stricter: the old customer, vendor and employee records all merge into a single "Business Partner" entity. Where a company was both a customer and a vendor (intermediary companies), ECC held 2 separate records; S/4HANA needs 1 — so they had to be harmonized.

On top of that, S/4HANA enforces stricter validation (mandatory fields, formats) that the legacy data loaded into ECC could not satisfy.

What we did

1. Master data audit script (ABAP)
   → output: 12,000 anomalies (duplicates, inconsistencies, missing values)

2. Categorizing the anomalies:
   - High priority (customers, vendors, critical materials): 3,000 records
   - Medium (inactive, rarely used): 6,000 records
   - Low (irrelevant historic data): 3,000 records

3. Cleanup execution:
   - High priority: manual, dedicated 3-person team (client's finance +
     logistics + IT)
   - Medium: script-with-human-review
   - Low: anonymization and archiving

4. Test migration on the sandbox:
   - 3 iterations, a new cleanup batch after each

Lesson

Plan for brownfield master data cleanup to take 2-3 times longer than your initial estimate. If discovery gives you "4 weeks," plan for 10-12.

Lesson 2: We underestimated the cost of migrating custom Z objects

The problem

80 custom Z programs. According to the SAP Custom Code Migration App's assessment:

SAP App's original estimate	Actual outcome
60 "green" (smooth)	35 green
15 "yellow" (minor changes)	30 yellow
5 "red" (major rewrite)	15 red

In the yellow and red bands, actual effort came out three times higher. The SAP App detects syntax-level breaking changes, but runtime semantics and side effects were consistently underestimated.

What we did

1. Prioritization
   → 5 most business-critical Z programs identified (e.g. a custom
     invoicing flow, a customs-clearance report)
   → these became release-blocker priority

2. Handling the remaining 75 Z programs:
   - 15 old Z programs decommissioned (unused, confirmed by the business
     owner)
   - 30 yellow Z programs rewritten (4-8 hours each on average)
   - 15 red Z programs rewritten from scratch (40-80 hours each on average)
   - 15 green Z programs handled by automatic adaptation

3. Tech debt backlog
   → the remaining 25 lower-priority Z programs moved to a post-go-live
     phase

4. Regression test framework
   → unit tests plus UAT-level regression testing for every Z program

The 5 critical Z programs

Z program	Function	Estimated → Actual
Z_VAT_REPORT_HU	Hungarian VAT return export	16h → 24h
Z_BANK_SFTP_INTEGRATION	Bank transaction import	24h → 48h (new OData flow)
Z_CUSTOMS_DECLARATION	Customs clearance report	32h → 60h
Z_INVENTORY_BARCODE	Barcode-based inventory	40h → 56h
Z_PRICING_LOGIC	Custom pricing rules	56h → 88h (the biggest rewrite)

Lesson

The SAP Custom Code Migration App gives you a directional estimate, but it underestimates low-level (yellow/red) code rewrites. Budget an extra 50% for Z-object rewrite effort.

Lesson 3: Integration mapping is a critical point — it deserves far more time than we expected

The problem

12 external interfaces:

• Banking SFTP (Mastercard, OTP, K&H, Erste — different formats)
• Webshop REST (Magento → SAP)
• Partner SOAP (3 major partner companies, EDI)
• Supplier EDI (ENGDAT, X12)
• Mobile app webhook (CRM integration)
• 3rd-party logistics (DHL, GLS)
• Payroll integration (Nexon CSV export)
• HR portal (SuccessFactors → ECC → S/4HANA)

According to the assessment, all of them were compatible. In reality: ECC used proprietary RFC modules on 4 interfaces, and those are deprecated in S/4HANA.

The 4 problematic interfaces

Interface	Issue	Solution
Magento webshop	RFC-based custom BAPI	Rewritten as an OData service
K&H banking	Proprietary IDoc	XML-REST endpoint
Supplier EDI	Z-module RFC	SAP Integration Suite
HR portal (legacy)	Custom RFC destination	RESTful endpoint

What we did

1. Discovery (after the fact): end-to-end test scenarios for all 12
   interfaces
2. Replaced the 4 problematic ones with OData/REST (modernizing them at
   the same time)
3. Added 3 weeks of scope, but it was worth it — the old RFCs had no
   long-term roadmap

Lesson

Integration mapping cannot be done on paper alone — every interface needs to be tested in a test environment, on the sandbox S/4HANA system, during discovery. "Fine on paper" often turns into "uncertain at runtime."

Lesson 4: A 36-hour cutover weekend does not work without a documented runbook

The problem

Many small steps (35+), each in a strict sequence. Miss one and it means a rollback. The first dry run (test cutover) took 42 hours; that would not fit into the 36-hour production window.

Cutover runbook iterations

Dry run 1 (sandbox):     42 hours
  Optimization 1:
  - 6 steps parallelized
  - 3 steps converted into scripts

Dry run 2 (sandbox):     35 hours
  Optimization 2:
  - Master data cache pre-warmed
  - Index rebuilds parallelized
  - Cutover cache invalidation scripted

Dry run 3 (sandbox):     31 hours

Production cutover:      28 hours
  (Friday 16:00 → Sunday 20:00)

The main groups within the 35 steps

Phase 1: Pre-cutover (Friday 16:00 → 20:00)
  - Old system frozen, user communication
  - Final data extracts
  - Sandbox validation

Phase 2: Database upgrade (Friday 20:00 → Saturday 12:00)
  - HANA migration prep
  - Schema conversion
  - Index rebuild (parallelized where possible)
  - Custom code activation

Phase 3: Master data load (Saturday 12:00 → 20:00)
  - Business Partner harmonization
  - Cleansed master data load
  - Validation scripts

Phase 4: Integration test (Saturday 20:00 → Sunday 08:00)
  - Each of the 12 interfaces tested end-to-end
  - Print queue and batch jobs verified

Phase 5: UAT sign-off (Sunday 08:00 → 14:00)
  - Verification by 8 key users
  - Walkthrough of critical scenarios

Phase 6: Go-live (Sunday 14:00 → 20:00)
  - User access enabled
  - Hyper-care war room active
  - Monitoring dashboard live

Lesson

Run the test cutover at least twice, keep a documented runbook committed to git, and analyze what can run in parallel. The 35-step runbook itself lived as a Notion doc plus git-versioned SQL/ABAP scripts.

Lesson 5: 30 days of hyper-care was not enough — we planned for 60

The problem

In the first 30 days, we typically saw 5-10 tickets a day. From day 31 onward, it was still running at 4-5 tickets a day. The scope only included 30 days of hyper-care — we had to request an extension.

What we did

Hyper-care timeline:
Day 1-30:  hyper-care phase 1 (full team, 5-10 tickets/day)
Day 31-60: hyper-care phase 2 (reduced team, 4-5 tickets/day)
Day 61-90: warm support (1 person part-time, on-call)
Day 91+:   standard maintenance contract

We held a post-go-live retro call every Friday — reviewing the tickets that had come in, categorizing them by priority, and writing runbooks for the 20 most common ticket types (for the client's support team to take over afterward).

Top 10 hyper-care ticket types

Rank	Issue	Resolution
1	"Old transaction code not found"	User training doc updated
2	"Understanding the new report format"	New training session
3	"Financial posting error on a custom flow"	Customizing fine-tuned
4	"Print form is wrong"	Form template updated
5	"Workflow approval is slow"	Performance tuning
6	"Banking integration is stuck"	Interface monitoring
7	"Duplicate stock write-off"	Master data fix
8	"Report export formatting in Excel"	XLS template fix
9	"RBAC: no access to X"	Authorization update
10	"Incorrect vendor data on invoice"	Master data correction

Lesson

Plan for 60 days of hyper-care on an S/4HANA brownfield migration. For an SME-sized project, 30 days may be enough — for an enterprise one, it is not.

Results — 6 months after go-live

Metric	Before (ECC)	6 months later (S/4HANA)
Critical incidents (P1)	1-2 / month	0
High incidents (P2)	5-8 / month	1-2 / month
Report generation time (financial month-end close)	4-5 days	1-2 days
Performance (critical transactions, p95)	3-5s	0.8-1.5s
User satisfaction (internal NPS)	5.2 / 10	7.2 / 10
Master data accuracy	~85%	~98%
Audit findings (ISO 9001)	12 findings	3 findings

The performance gains come from the HANA in-memory database (critical transactions run 30-50% faster). The improvement in user satisfaction comes from the new Fiori UI.

Concrete business impact

• Financial month-end close, 4-5 days → 1-2 days. That gives management an extra 3 days for decision-making.
• Audit findings, 12 → 3. The ISO 9001 audit process is 50% shorter.
• Real-time reporting — the weekly management dashboard is now live.

What would we do differently?

1. A longer discovery phase

The 1-month discovery phase should have been 2 months. The assessments for master data, Z objects and integrations were all underestimated.

2. Starting the master data team a month earlier

The 3-person master data cleanup team only started in month 3. Had it started in month 1, the entire project slip could have been avoided.

3. A dedicated sprint for integration testing

Testing all 12 interfaces happened at the end of the build phase — a dedicated 1-week sprint in month 5 would have helped.

4. A communication plan for users

The 180 users received their training invitations 30 days before go-live. That should have gone out 2 months earlier — actual training only started 1 month before go-live.

5. A stronger "no-customizing" stance

Of the 25 yellow and 15 red Z programs, 8-10 could probably have been solved with a standard best-practice flow instead. The argument "but this is how we've always done it" was sometimes accepted too readily.

What to watch out for if you're starting an S/4HANA brownfield project now

Pre-flight checklist

• Discovery planned for 2 months (not 1)
• Master data audit script run, anomalies categorized
• Custom code audit done with the SAP App plus manual review
• All integration interfaces tested on the sandbox
• Cutover runbook drafted (yes, already during discovery)
• Hyper-care budget set for 60 days
• Test cutover run at least twice
• User communication plan in place 8 weeks before go-live

Budget contingency

• +15% time contingency for master data cleanup
• +25% effort contingency for Z-object rewrites
• +1 week contingency for integration testing

Official documentation and further reading

• SAP S/4HANA Conversion Guide — official
• SAP Custom Code Migration App — code-readiness analysis
• SAP Readiness Check — pre-migration audit
• SAP Activate methodology — implementation framework
• Hungarian SAP User Group — community

Related articles from us: From Excel to SAP for SMEs — a greenfield implementation roadmap. AI implementation at Hungarian SMEs — ERP plus AI pipeline integration. How we work remotely — project management.

Closing thoughts

An S/4HANA brownfield migration is not a simple project. The name "in-place upgrade" is misleading — data migration and custom code refactoring can account for up to 50% of the total project effort.

The most important lesson from this anonymized project experience: build in buffer across all three critical areas — master data, custom code, integration. None of them can be estimated precisely during discovery, and all three tend to take 2-3 times longer than SAP's own tools predict.

If you're planning an SAP S/4HANA migration, let's start with a discovery call — the first month is exactly about identifying those buffer areas. A discovery cost of HUF 200,000-400,000 often saves you from HUF 20-50 million in scope creep later on.