Written by Konda — Paddy & Water Inc. / Strategy

S/4HANA Migration Decisions and Pitfalls

— The Big Picture on Maintenance Deadlines, a Comparison of Migration Approaches, Failure Patterns, and the Optimal Actions for 2026 —

June 2026

Chapter 1: What Is the SAP 2027 Problem?

1.1 The Essence of the Problem

The “SAP 2027 Problem” refers to the situation in which, starting from the end of standard maintenance support for SAP’s core ERP system “SAP ERP Central Component (ECC) 6.0” on December 31, 2027, more than approximately 10,000 SAP ECC user companies in Japan and around the world are being forced to either migrate to the successor product, SAP S/4HANA, or take steps to extend support.

The essence of the problem is not simply a “software version upgrade.” Migrating from SAP ECC to S/4HANA involves a fundamental change in database structure (replacement with the in-memory database “SAP HANA”), redesign of business processes, and a complete overhaul of add-ons (proprietary custom-developed functions) accumulated over many years — making it, for some companies, a project spanning several years and costing in the tens of billions of yen.

The Core of the 2027 Problem

“The end of ECC maintenance” is merely the trigger. The real problem is that three things hit companies simultaneously: ① the accumulated burden of years of add-ons and customization, ② a severe shortage of SAP consultants capable of handling the migration, and ③ management decisions forced between three choices — “migrate, prolong the current system, or move away from SAP.”

1.2 The Evolution of SAP Maintenance Deadlines and Where Things Stand Now

The maintenance deadline has been extended multiple times in the past, which is one source of confusion. The timeline is organized below.

Timing	SAP’s Official Announcement / Change	Impact on User Companies
Through 2020	ECC maintenance end announced as “end of 2025” (originally)	Many companies felt “there’s still time” and deprioritized migration
2020	Deadline extended by two years to “end of 2027” (for EhP6–8 users)	Urgency to migrate temporarily eased; procrastination accelerated
2022–2023	Announced an option to extend to 2031–2033 conditional on a “RISE with SAP” contract	Some companies used this as a way to prolong the current system, further complicating migration decisions
February 2025	Officially announced a new option allowing ECC maintenance to be “extended through the end of 2033” (condition: RISE with SAP contract required)	Maintenance extension options became clearer, though at additional cost
2026 (present)	About a year and a half remains until standard maintenance ends; roughly 40% of companies have not yet begun migration	The SAP consultant shortage is worsening, with cases of difficulty securing staff occurring frequently
December 31, 2027	End of standard maintenance for SAP ECC 6.0 (EhP6–8)	Security patches and regulatory-compliance updates stop
2028–2030	Paid Extended Maintenance becomes available (at additional cost)	A temporary lifeline for companies whose migration is delayed
2031–2033	An ultra-long-term extension option for companies under a RISE with SAP contract	A practical grace period, but fundamental migration remains unavoidable

1.3 Why So Many Companies Cannot Move

As of June 2026, an estimated 40% of Japanese companies have still not decided on a migration destination (average across multiple surveys). Behind this lie the following structural factors.

Factor ①: The Optimism Bias of “There Will Be Another Extension, So We’re Fine”

Because the maintenance deadline has repeatedly been pushed back — from 2025 to 2027 to 2030 to 2033 — the field has developed an ingrained optimism that “SAP will extend it again.” This also makes it easy, from an accountability standpoint with senior management, to conclude that “there’s no need to rush because there’s an extension,” creating a structure in which decision-making is easily postponed.

Factor ②: The Weight of Add-ons Makes Migration Estimation Difficult

SAP ECC has often been in operation for more than 20–30 years, and the add-ons (proprietary custom functions) accumulated during that time can number in the hundreds or thousands. Simply taking inventory of all add-ons and investigating S/4HANA compatibility can take several months to a year, delaying the project’s initial kickoff.

Factor ③: Depletion of the Consultant Market

Demand for SAP consultants capable of handling S/4HANA migration far exceeds supply. Since 2024, consultant rates have risen roughly 1.5 times year over year, and utilization rates exceed 90%. Cases have actually been reported in 2026 of companies with budget in hand being turned down by 15 firms (ITmedia Enterprise, April 2026). The last train for starting a migration is effectively approaching its limit around the end of 2026.

Factor ④: Delayed Management Decisions on Project Scale and Cost

The cost of an S/4HANA migration varies greatly depending on company size, number of add-ons, and number of target sites, but can run into the hundreds of millions of yen for mid-sized companies and billions to tens of billions of yen for large enterprises. Because investment decisions of this scale require approval from management meetings and the board of directors, situations frequently arise in which the IT department recognizes the need but “management does not decide.”

Chapter 2: What Happens After 2027 — The Real Impact of the End of Maintenance

2.1 What Is Lost When Standard Maintenance Ends

It is essential to understand concretely what deliverables will be discontinued once SAP ECC standard maintenance ends, and what impact this will have.

Discontinued Service	Specific Content	Business Impact
Suspension of security patches	Even if new security vulnerabilities are discovered, SAP will not provide fixes (Security Notes)	The risk of cyberattacks and unauthorized access continues to rise. If a data breach occurs, management may be held responsible for “leaving a known vulnerability unaddressed”
Suspension of regulatory compliance updates	No programs will be provided to address regulatory changes such as consumption tax rate changes, the Electronic Books Preservation Act, and the invoice system	Risk of legal compliance violations. Errors in accounting and tax processing cannot be addressed using SAP standard functionality
Suspension of bug fixes and technical support	Official SAP support for existing bugs and failures comes to an end	When system failures occur, solutions can no longer be obtained from SAP support. Reliance on in-house resources or third-party maintenance vendors becomes necessary
Suspension of enhancements and new functionality	New features being added to S/4HANA (AI, machine learning, embedded analytics) will not be provided for ECC	Companies fall behind in strengthening DX competitiveness. As competitors improve operational efficiency using S/4HANA’s new features, companies remaining on ECC are placed at a relative disadvantage
Shrinking pool of certified partners	SAP partner companies will stop renewing ECC-related certifications	It becomes harder to receive ECC maintenance and modification support from SI partners

Warning: Problems That “Extended Maintenance (Through 2030)” Does Not Solve

Even if you contract Extended Maintenance through 2030, the following will not be resolved: regulatory compliance updates are limited to “fixes for known issues only” (response to new regulations is excluded); security patches are reduced to limited coverage; none of S/4HANA’s new features (AI, embedded analytics, etc.) can be used at all; and cloud integration with SAP’s surrounding products (SuccessFactors, Ariba, etc.) is constrained. Recognize accurately that this is not “no problem until 2030” but rather “the system can be kept alive until 2030, but challenges remain.”

2.2 Compliance and Audit Risk

The risk most easily overlooked by companies remaining on ECC is “compliance risk.” In Japan, ERP systems are required to support the following regulatory frameworks, and once maintenance ends, SAP will no longer provide official support programs for them.

• Electronic Books Preservation Act: Fully enforced in 2024. Requirements for retaining electronic transaction data directly affect SAP modules (FI/MM)

• Invoice System (Qualified Invoice Retention Method): Already in effect since October 2023. Future system changes will require ongoing response

• International Financial Reporting Standards (IFRS) compliance: Requirements such as IFRS 17 are changing for global listings and subsidiary consolidation

• Cybersecurity standards: The Ministry of Economy, Trade and Industry’s Cybersecurity Management Guidelines explicitly call for “addressing known vulnerabilities”

Since 2025, auditing firms and internal audit functions have increasingly begun to confirm “the state of security response after the end of maintenance.” As part of risk management at the board level, there is also a growing trend toward requiring disclosure of the risks of remaining on ECC.

Chapter 3: Migration Options — Five Approaches

3.1 The Overall Map of Options

There are five broad directions for responding to the SAP 2027 Problem, each with different risk, cost, timeline, and degree of transformation. It is important to make a decision after accurately understanding the option that best fits your company’s situation.

Option	Overview	Advantages	Disadvantages	Suited For
① Greenfield (New Implementation)	A fresh installation of S/4HANA from scratch, redesigning business processes to fit standard functionality	· Sweeps away add-ons and builds a clean system · Maximizes use of S/4HANA’s new features · Can serve as a catalyst for DX	· Takes the most time and cost (18–36 months, tens of billions of yen or more) · Strong resistance from the field to business transformation · Risk of running parallel operations during the migration period	· Companies with hundreds of add-ons where ECC has become a black box · Companies genuinely committed to business process reform · Mid-sized companies within 50 years of founding that can organize their data
② Brownfield (System Conversion)	Converts the existing ECC environment to S/4HANA, carrying over settings, data, and some add-ons	· Reuses existing assets (settings, data) to reduce cost · Maintains business continuity during migration · Shorter than Greenfield (6–18 months)	· Existing complex add-ons are carried over as-is, preserving their risk · Limited use of S/4HANA’s new features · Add-on debt tends to re-accumulate over the long term	· Companies unable to make major changes to business processes · Companies with relatively few add-ons · Companies that prioritize completing the migration in a short period
③ Bluefield (Selective Migration)	A hybrid approach that uses Greenfield or Brownfield selectively by business process or organizational unit	· Achieves “a clean slate where change is needed, and continuity where it isn’t” · High flexibility	· Complex design; requires proficiency with migration tools (such as SNP Transformation) · Cost and duration fall between Greenfield and Brownfield, or higher	· Companies that want to redesign some operations while needing continuity in others · Global companies with multiple sites that want to make site-by-site decisions
④ RISE with SAP (Cloud Migration)	In addition to a migration approach (Greenfield/Brownfield/Bluefield), infrastructure is moved to SAP-managed cloud. A monthly-fee SaaS model	· Outsources infrastructure management to SAP · Minimizes the risk of maintenance ending (SAP continues maintenance) · Continuous delivery of AI/cloud new features	· Ongoing monthly costs · Post-migration customization is constrained to standard APIs · Risk of vendor lock-in during the contract term	· Companies that do not want to run their own infrastructure · Global users and large enterprises
⑤ Third-Party Maintenance (Prolonging the Current System)	Extending the life of ECC through a contract with a non-SAP-certified third-party maintenance vendor such as Rimini Street or SupportPoint	· Can reduce SAP maintenance costs by 50–90% · Lowers the urgency of migration, buying time to plan	· S/4HANA’s new features cannot be used · Migrating back to official SAP support may become difficult · Positioned by SAP as “not recommended”	· Companies that cannot immediately fund migration costs · Companies that want to buy time while formulating a migration plan

3.2 How to Choose Between RISE with SAP and GROW with SAP

Comparison Axis	RISE with SAP	GROW with SAP
Target	Large enterprises and existing ECC users with complex processes	Small-to-mid-sized companies; new ERP implementations
Product content	A bundle of S/4HANA Cloud (Private Edition / Public Cloud), license, and implementation methodology	S/4HANA Public Cloud only (simplified)
Customization	Relatively free if using the Private Edition	Because it is Public Cloud, it follows industry templates with restrictions on add-ons
Infrastructure	SAP-managed private cloud or public cloud	SAP-managed public cloud only
Migration duration	18–36 months (including migration from existing ECC)	12–18 months (assuming standard process)
Maintenance extension option	A maintenance extension through 2031–2033 is possible, conditional on a RISE contract	Not applicable (as this is a new implementation)
Suited For	Global large enterprises with complex customizations of their existing ECC	Mid-sized companies with simple business processes that can operate on SAP standard functionality

Chapter 4: Decision Framework — Choosing the Approach Best Suited to Your Company

4.1 Five Questions for Selecting a Migration Approach

Deciding between Greenfield, Brownfield, and Bluefield can be narrowed down by answering the following five questions.

Question ①: How Many Add-ons Are Currently in Operation?

If the number of add-ons is “100 or fewer,” Brownfield becomes a realistic option. If it is “300 or more,” the cost of modifying add-ons may exceed the cost of redesigning under Greenfield, increasing the rationale for a clean reset. “100–300” is a gray zone, and an importance analysis of add-ons (essential / semi-standard / candidate for retirement) should be conducted first.

Question ②: Does Management Have the Will to Change Business Processes?

Greenfield is premised on the concept of “Fit to Standard” (aligning operations to standard functionality). If management’s stance is that they “don’t want to change business processes and want to suppress resistance from the field,” Greenfield will not work. Conversely, top management commitment is essential to making Greenfield succeed.

Question ③: How Many Years Are Available for the Migration?

Working backward from the end of standard maintenance at the end of 2027, unless you “start right now,” Greenfield (18–36 months) will practically not make it in time for the end of 2027. If choosing Greenfield as of late 2026, you need to design a schedule premised on the maintenance extension (through 2030). Brownfield (6–18 months) may just barely make it in time for the end of 2027.

Question ④: Will You Leverage SAP’s New Features (AI, Embedded Analytics, Fiori) in This Migration?

If you can accept that “this migration’s purpose is simply to move to S/4HANA, and leveraging new features is the next phase,” Brownfield is rational. If you want to “achieve DX in this migration, and use real-time analytics or AI forecasting,” you should choose Greenfield or Bluefield.

Question ⑤: Do You Have a Global Multi-Site Footprint?

Companies with global multi-site operations (10 or more sites) find Bluefield a realistic option. When the maturity of business processes and the number of add-ons differ from site to site, Bluefield — which allows decisions to be made on a site-by-site basis — is more efficient than uniformly applying Greenfield or Brownfield.

4.2 Decision Matrix

Situation	Recommended Approach	Rationale
300+ add-ons × willingness for business transformation	Greenfield	Add-on modification cost exceeds redesign cost. A good opportunity for a clean reset that clears out debt
Fewer than 100 add-ons × short-term migration is the top priority	Brownfield	Leverages existing assets for the fastest possible migration; optimize add-ons after go-live
100–300 add-ons × willingness for transformation × global multi-site	Bluefield (Hybrid)	Use Greenfield/Brownfield selectively by site and business unit; leverage tools such as SNP Transformation
Want to hand off infrastructure management × large enterprise	RISE with SAP (Cloud) + Greenfield/Brownfield	Solves infrastructure challenges while migrating to S/4HANA; consider whether monthly costs and lock-in are acceptable
Cannot fund migration costs right now × want 5 years of grace	Third-party maintenance + migration planning	Buy time while proceeding with add-on inventory and business-process redesign; carry out the full migration in five years
A review of the ERP itself is under discussion	Also consider moving away from SAP (migrating to another ERP)	For mid-sized companies where SAP Public Cloud is not a good fit, options such as Oracle or Dynamics also come into play

Chapter 5: Pitfalls of S/4HANA Migration — Dissecting the Anatomy of Failure

According to ISG (2026 survey), approximately 60% of S/4HANA migration projects experience budget overruns or schedule delays. This chapter explains in detail the structural failure patterns behind this.

5.1 Pitfall ①: The “Iceberg” Problem of Add-ons

The add-on problem is the greatest obstacle in S/4HANA migration. It is likened to an “iceberg” because the real problem lies not in the visible portion (the count) but below the surface — interdependencies, undocumented logic, and the absence of the original developers.

Why Add-on Remediation Balloons Beyond Expectations

• Interdependencies among add-ons (functions chained as A→B→C exist, so modifying A requires cascading modifications to B and C as well)

• Absence of developers (specifications for add-ons built 10–20 years ago no longer exist, and the developers have already left the company)

• Changes to SAP standard table structures (in S/4HANA, the FI/CO table structure is consolidated into the Universal Journal, fundamentally changing table references within ECC ABAP code)

• Indirect dependencies that the Simplification Item Check cannot detect (SAP’s provided check tool reveals surface-level incompatibilities, but issues stemming from dynamic SQL or custom frameworks only become apparent at runtime)

How to Address It

• Always conduct an “add-on inventory assessment” before making the migration decision. Beyond just counting, classify add-ons into three categories: “can be retired,” “can be replaced with standard functionality,” or “requires modification”

• Delete or disable retirement-candidate add-ons in advance of conversion to minimize the scope requiring remediation

• Always build a 30–40% contingency into the cost estimate for add-on remediation

5.2 Pitfall ②: Add-ons That Pile Up in the Name of “Fit to Standard”

Even when Greenfield is chosen, many cases have been reported where demands from business departments to “make it work the same way as in the ECC era” pour in, resulting in a large number of new add-ons being created.

A Typical Failure Pattern

Policy: Start Greenfield under “Fit to Standard (zero add-ons target)” ↓ Fit/Gap analysis reveals gap after gap. Business departments insist “please keep it the way it is now” ↓ Approvals for add-ons pile up under “just this once” or “because it’s an important function” ↓ Result: The new S/4HANA environment is reborn with as many add-ons as in the ECC era ↓ The same problem recurs at the next S/4HANA version upgrade

Preventing this requires a mechanism in which Fit/Gap decisions are approved not by “the discretion of business departments” but by a “management-led governance committee.” Build a structure in which management, not business departments, makes the final call on whether an add-on is permitted.

5.3 Pitfall ③: The Structural Problem of Consultant Shortages

As of 2026, the supply-demand gap for SAP consultants needed for S/4HANA migration has reached a critical point.

• S/4HANA consultant rates have risen roughly 1.5 times compared to 2024

• Top consultants are operating at over 90% utilization, effectively fully booked

• A growing number of companies report “we have the budget, we’ve made the decision — but vendors won’t take us on”

• An actual case reported in 2026: one company issued an RFP for a migration project, and 15 SI vendors declined to bid, one after another (ITmedia Enterprise, April 2026)

Even if a decision is made in the latter half of 2026, the project may not actually start until 2027 or later. In that case, it becomes necessary to design a schedule that accepts the risk of still being mid-migration after standard maintenance ends.

5.4 Pitfall ④: “Pickled SAP” in the Cloud

There are cases in which, despite migrating to the cloud via RISE with SAP, a massive number of add-ons are carried over unchanged, creating “in-cloud legacy” that fails to realize the benefits of the cloud. An ITmedia survey (June 2026) refers to this state as “pickled SAP” — a situation described as: “We spent 1 billion yen migrating to the cloud, but the business departments haven’t changed and still demand the old way of operating, so we’re not using any of S/4HANA’s new features at all.”

• Problem: While RISE with SAP’s primary purpose is to reduce infrastructure costs, as long as add-ons remain, infrastructure usage fees (driven by increased processing load from add-ons) stay elevated

• Problem: SAP’s new SaaS features (Joule AI, Business AI, etc.) assume a clean standard environment, and there are cases where operation is not guaranteed in environments with excessive add-ons

• Remedy: Run an “add-on cleanup project” in parallel with the RISE migration, incorporating both infrastructure migration and process transformation into a single project

5.5 Pitfall ⑤: Scope Creep and Prolonged Projects

The single biggest cause of schedule delays and budget overruns in migration projects is “scope creep” — the addition of requirements not originally anticipated.

Scope-Expansion Pattern	Specific Example	Preventive Measure
Additional requirements from business departments	“Please automate this report too” / “Please add back the function we had in the ECC era”	Set a requirements-freeze gate (a Go/No-Go checkpoint). Push additional requirements to the next phase
Addition of global sites	“Originally only the Japan head office was in scope, but overseas subsidiaries were added midway”	Document sites and target systems explicitly when defining scope, and require management approval for any changes
Expansion of data-migration scope	“We want to migrate ten years of past data” / “We want to bring in data from related systems too”	Finalize the data migration policy (scope, period, quality standards) before migration begins
Increase in integrated systems	“Please integrate this system with S/4HANA too”	Finalize interface design documents before migration; handle additions in the next phase
Repeated cutover attempts	Pressured to go live with insufficient test results, resulting in a flood of defects after go-live	Define cutover criteria in advance (zero bugs, zero critical risks, etc.) and decide to postpone if criteria are not met

Chapter 6: Industry Migration Case Studies — Lessons from Success and Failure

6.1 Premise of the Case Analysis

The cases introduced in this chapter organize industry, challenges, and lessons based on publicly available information (Nikkei BP, ITmedia, company press releases, SAP Community). Company names are recorded based on publicly available information. For security-policy reasons, when using this material internally for internal review purposes, please replace company-name references with industry descriptions.

6.2 Case ①: Escaping from Over 1,000 Add-ons (Food and Beverage Industry)

Case Overview (Major Food Company)

Industry: Food manufacturing and sales. Challenge: After more than 20 years of operation, the number of active add-ons had swollen to over 1,000, turning the system into a black box; every version upgrade incurred enormous remediation costs. Approach chosen: Greenfield (thorough Fit to Standard). Migration duration: approximately 3 years. Outcome: Reduced the number of add-ons to under 100 and achieved 46,000 hours of annual operational efficiency gains (based on SAP Community and public press releases).

• Lesson ①: Explicitly stating “add-on reduction” as one of the migration’s objectives increased the field’s willingness to accept change

• Lesson ②: As a matter of “selection and concentration,” operations not directly tied to competitive advantage (accounting, procurement) were aligned to SAP standard, while development resources were concentrated on differentiating areas such as sales and logistics

• Lesson ③: Greenfield began not with “making the migration succeed” but with “designing the post-migration state first”

6.3 Case ②: The Price of a 2-Year Schedule Overrun and 1.6x Cost (Food Manufacturing)

Case Overview (Food Manufacturing, Anonymous)

Industry: Food manufacturing. Migration start: 2019. Original planned completion: 2022 (a 3-year plan). Actual completion: March 2024 (5 years). Original investment: 21.5 billion yen. Final investment: approximately 34.2 billion yen (ballooned to 1.6 times). Cause: unexpected expansion of add-on remediation, requirement changes, and testing effort overruns (based on public reporting).

• Failure factor ①: Because the add-on inventory assessment was started at the same time as the migration project itself, the scope of remediation kept expanding throughout the migration

• Failure factor ②: Business departments strongly resisted process changes, and the Fit to Standard policy became a formality; add-ons were reproduced in the new environment

• Failure factor ③: The initial effort estimate did not include a contingency, so additional costs had to be re-approved at every management meeting, delaying decision-making

6.4 Case ③: Achieving a Short-Term Migration with Brownfield (Chemicals and Materials Industry)

Case Overview (Chemicals and Materials Manufacturer, Anonymous)

Industry: Chemicals and materials manufacturing. Challenge: Meeting the 2027 deadline was the top priority; major changes to business processes were ruled out. Approach chosen: Brownfield (system conversion). Migration duration: 14 months. Outcome: Migration completed in March 2027. Number of add-ons reduced by about 20% from the start. Challenge: Maintenance costs for add-ons continue after migration; a medium-term additional optimization phase is being planned.

• Lesson ①: Clearly defining “making it in time for 2027” as the top priority tightened the scope and helped the project converge

• Lesson ②: Add-ons that could be retired were thoroughly sorted out before migration. Even with a large count, removing “unused add-ons” first reduced the remediation scope by 20%

• Lesson ③: A “Phase 2 (optimizing remaining add-ons, leveraging AI features)” following migration was built into the plan from the start of the project and had already secured management approval

6.5 Case ④: Three Failed RFPs Due to Consultant Shortages (Manufacturing, Anonymous)

Case Overview (Manufacturing, Anonymous)

Industry: Industrial equipment manufacturing. Situation: Secured a migration budget in 2025 and issued an RFP to 7 companies. Result: All companies declined, citing an inability to secure staff. Second RFP: Reissued to 6 companies at the end of 2025 → 4 declined, 2 submitted proposals. Current status: Contracted with one company in 2026; the project will start in the second half of 2026, with the schedule revised on the assumption of the 2030 maintenance extension.

• Lesson: The consultant market is no longer an era where “you can move as long as you have budget”

• Lesson: Before issuing an RFP, first gauge the prospects of securing staff through informal contact with partners (advance market research)

• Lesson: Bearing in mind that it typically takes 6–12 months from RFP issuance to contract, begin taking action by working backward from the decision date

Chapter 7: Optimal Actions as of 2026

7.1 Timeline for Starting the Migration

Working backward from the end of standard maintenance at the end of 2027, the migration project timeline looks as follows.

Timing	What to Do	Decision Branch Point
June–September 2026 (right now)	① Begin add-on inventory and assessment ② Run a simplification check on the current system (SAP Readiness Check) ③ Begin management discussion on the migration approach (Greenfield/Brownfield/Bluefield)	If no action is taken at this stage, either “still migrating” or “prolonging the current system” will be locked in by the end of 2027
October–December 2026	① Decide on the migration approach and scope ② Conduct advance market research and bid preparation with SI partners ③ Obtain management approval for the migration budget (incorporate into the budget for the fiscal year ending March 2027)	If the decision is not completed within 2026, switch to a plan premised on the 2030 maintenance extension
January–June 2027	① Select and contract with an SI partner ② Build the project organization (appoint a project manager and business-department representatives) ③ Finalize requirements and the add-on remediation policy	For Brownfield, this is the last chance to aim for completion by the end of 2027
July–December 2027	Brownfield teams: final testing through cutover. Greenfield teams: continue detailed design and development (targeting go-live in 2028–2029)	December 31, 2027: End of SAP ECC standard maintenance
2028–2030	Continue migration while using paid Extended Maintenance in parallel	Paid Extended Maintenance also ends in 2030 (can be extended through 2033 with a separate RISE with SAP contract)

7.2 Three Things to Do Right Now

Action ①: Run the SAP Readiness Check (Free, Provided by SAP)

Running SAP’s free “Readiness Check for SAP S/4HANA” tool allows you to automatically diagnose how well your current ECC environment fits S/4HANA — covering simplification items, add-on compatibility, and data quality. This report becomes the starting point for your assessment. Results are available within a few hours to a day. Start here first.

Action ②: Begin the Add-on Inventory (Within 3 Months)

Based on the Readiness Check results, classify add-ons — in-house or together with a partner — into three categories: “① retire,” “② replace with standard functionality,” or “③ requires modification.” The results of this inventory greatly influence the migration approach, cost, and duration estimates. Even when the add-on count is high, in many cases only 30–40% of add-ons are actually “in use,” so identifying retirement candidates is the single most cost-effective measure.

Action ③: Informal Contact with Partners (Market Research Before the RFP)

Before issuing a formal RFP, hold “informal preliminary discussions” with 3–5 leading SI partners. Confirm whether staffing would be possible if you “wanted to start in Q3 2026.” If there is no prospect of securing staff, design a Plan B premised on the 2030 extension in parallel. Be sure to include “track record in S/4HANA migrations, industry-specific expertise, and a track record of add-on reduction” as evaluation criteria when selecting a partner.

7.3 Escalating to Management: Four Messages the IT Department Must Convey

Message	What Management Tends to Misunderstand	The Fact That Must Be Conveyed Correctly
“It ends at the end of 2027”	“There’s an extension through 2030, so we’re fine”	The 2030 extension is paid (incurring additional cost) and functionality is frozen. Security risk continues. The extension is merely a grace period, not a solution
“We can’t secure consultants”	“If we have the budget, we can get it moving”	In the 2026 market, you can be turned down even with budget in hand. The sooner you decide, the more options you have. The situation will grow even tighter after 2027
“The migration costs billions of yen”	“We can’t make that big an investment right now”	Adding up the cost of not migrating — extension-maintenance costs (paid maintenance × years) plus security-incident risk plus the cost of competitive disadvantage — can exceed the cost of migrating
“If we don’t act now, it will be too late”	“Won’t the deadline be extended again?”	It should be assumed that SAP will not push the deadline back any further. The 2033 extension available under a RISE with SAP contract is the final grace period; migration is the only real solution

7.4 The Organizational Structure for a Successful Migration

• Executive Sponsor (C-Level): One of the CIO, CFO, or COO is involved as the final decision-maker holding “authority to approve additional add-ons.” This role allows top management to hold back the field’s pressure of “we don’t want to change”

Chapter 8: Migration Difficulty Map by Functional Area

The fact that S/4HANA migration difficulty “varies greatly by module” is extremely important for improving the precision of a migration plan. Estimating all modules with the same level of effort leads to significant errors in an actual project. The difficulty ratings below combine three axes: the magnitude of data-structure change, the degree of add-on impact, and the necessity of business-process transformation.

Module	Difficulty	Overview of Key Changes	Key Migration Considerations
FI (Financial Accounting)	★★★★☆	Consolidation into the Universal Journal (ACDOCA). Any add-on directly referencing the FAGLFLEXA or FBLXXN tables requires modification	① Old GL → New GL (has this already been completed?) ② Migration to the new depreciation engine for Fixed Assets (AA) ③ Discontinuation of open-item management ④ Investigate the extent to which add-ons depend on FI tables
CO (Management Accounting)	★★★★★	The most difficult area. Consolidation into the Universal Journal means costing-based CO-PA is recommended for retirement. ECC’s COEP, COSS, and COSP disappear and are consolidated into ACDOCA	① Redesign from costing-based CO-PA to account-based CO-PA ② A complete overhaul of existing management-accounting reports ③ Confirm Material Ledger (MLCC) integration for cost calculation (CO-PC) ④ Inventory of add-ons dependent on CO-PA
SD (Sales and Distribution)	★★★☆☆	Introduction of Business Partner (BP) consolidates the Customer master (KNA1). If revenue recognition (IFRS 15 compliance) is required, separate large-scale modification is needed	① BP migration (consolidated migration of existing customer data into BP) ② Determine whether IFRS 15 compliance is required ③ The basic order-to-cash flow (order, shipment, billing) can generally continue unchanged (relatively low impact)
MM (Procurement and Inventory Management)	★★★☆☆	Introduction of Business Partner consolidates the Vendor master (LFA1). MRP functionality can continue via MRP Live	① BP migration (consolidation of vendor data into BP) ② Migration settings for MRP Live (largely can continue unchanged) ③ Consider activating Material Ledger (actual costing) ④ Review add-ons related to invoice verification (MIRO)
WM → eWM (Warehouse Management)	★★★★★	ECC’s WM (Warehouse Management) is discontinued in S/4HANA. Its successor, eWM (Extended Warehouse Management), represents a fundamentally different functional concept	① Full investigation of the functional differences between eWM and WM ② Redesign business processes from transfer orders to warehouse tasks ③ eWM requires a redesign effort closer to Greenfield ④ Redesign of interfaces with WM-dependent add-ons and RFID systems
PP (Production Planning)	★★☆☆☆	The basic concepts of planning and actuals remain unchanged. MRP functionality is supported via MRP Live	① Migration to MRP Live (configuration changes are minor) ② Consider newly adopting APS (PP-DS) ③ Review add-ons related to production orders ④ For process manufacturing (PP-PI), verify the Resource master configuration
PP/DS / APO	★★★★☆	If SAP APO was used in the ECC era, migration to S/4HANA IBP/PP-DS is required	① Functional mapping from APO to IBP/PP-DS (essentially a different system) ② Complete redesign of APO-specific planning logic and macros ③ Retraining of planners is required
QM (Quality Management)	★★☆☆☆	Basic functionality continues. Shift to Fiori apps and Business Partner integration	① Confirm continuity of inspection plans and characteristics masters (no change) ② Migration to new UIs such as Fiori QE51N and user training ③ Confirm continuity of SPC and CoA functions
PM (Plant Maintenance)	★★☆☆☆	Basic functionality continues. Migration to a Fiori-based new UI	① Confirm equipment and functional location masters (no change) ② Additional effort if newly considering integration with SAP DM ③ Fiori support for maintenance notifications and work orders
PS (Project Systems)	★★★☆☆	Basic functionality continues. CO reports change to support the Universal Journal	① CO-PS reports change to support ACDOCA ② Consider integration with Commercial Project Management (CPM) ③ Cost-aggregation logic is affected by CO changes
HR/HCM	★★★★★	The most difficult, and in a different direction entirely. HCM is not integrated into S/4HANA. Cloud migration to SuccessFactors is required as a separate project	① ECC’s HR (PA/PY/OM) is not bundled with S/4HANA ② SuccessFactors migration runs in parallel with the S/4HANA migration but as a separate project ③ Japanese payroll: choose between continuing ECC HR temporarily until SuccessFactors support is ready, or switching to third-party payroll (Yayoi, COMPANY, etc.) ④ Japan-specific requirements such as union rules, company housing, and commuting allowances are particularly difficult
BW / BW/4HANA (Analytics)	★★★★☆	Moving from ECC + BW (legacy) to S/4HANA + BW/4HANA. A fundamental change in data sourcing (via the Virtual Data Model)	① Design the migration destination for existing BW InfoCubes and DataStores ② Consider migrating to S/4HANA Embedded Analytics (SAC integration) ③ Migrate existing BEx reports to Analysis for Office/SAC

8.1 The Most Difficult Module: A Detailed Look at CO (Management Accounting)

The CO area involves the largest design changes in an S/4HANA migration and has the greatest business impact. In particular, “the retirement of costing-based CO-PA” forces many companies into a complete redesign of their management-accounting reports.

What Is the Universal Journal? Why Is CO the Hardest?

In the ECC era, FI journal entries were recorded in the FI ledger (BKPF/BSEG), while CO costs were recorded separately in other ledgers (COEP/COSS/COSP/COPA, etc.). In S/4HANA, all financial and management-accounting data is consolidated into a single journal table called the “Universal Journal (ACDOCA).”

• Before the change (ECC): The FI ledger and CO ledger were separate, requiring monthly ledger reconciliation and FI-CO variance adjustments

• After the change (S/4HANA): FI, CO, special ledgers, assets, cost centers, profit centers, and CO-PA are all unified into ACDOCA, making “instant profit and loss by cost center” and “real-time profitability analysis” possible

This is a “conceptual transformation” of accounting, and it fundamentally changes the data structures that existing management-accounting reports, costing logic, and add-ons assume.

Migrating from Costing-Based CO-PA to Account-Based CO-PA

ECC’s CO-PA (Profitability Analysis) had two types: “account-based” and “costing-based.” In S/4HANA, “account-based” becomes the default, and retiring “costing-based” is recommended.

• Impact: Profitability reports built solely on costing-based CO-PA need to be redesigned on an account basis

• Impact: The logic for “valuation” and “condition-based allocation,” which are specific to costing-based CO-PA, must be reproduced on an account basis

• Impact: If BI/BW systems or internal reporting systems reference CO-PA data, all of them must be redesigned

Designing and testing this migration alone can take 6–12 months in some cases. If there is no in-house staff capable of designing the CO area, an external management-accounting specialist consultant is essential.

8.2 The Reality of Migrating from WM to eWM

Warehouse management migration is the module with the strongest character of “discontinuation and replacement.” WM (conventional Warehouse Management) is discontinued in S/4HANA, and eWM (Extended Warehouse Management) takes over all successor functionality.

• WM and eWM differ in their “management concept”: WM’s “Transfer Order” becomes eWM’s “Warehouse Task.” The way the movement of goods itself is captured changes

• Settings cannot be migrated: WM’s warehouse numbers, storage types, bin locations, and control parameters cannot be automatically converted to eWM and generally must be reconfigured from scratch

• Complete redesign of interfaces: Because the interfaces connecting WM with PP, MM, and SD (the flow of transport requests) change under eWM, all add-ons and external system integrations surrounding WM must be reviewed

• Recommendation for WM users: Even in a Brownfield migration, understand that eWM will require Greenfield-like design work

8.3 The Special Nature of HR/HCM: A Project Separate from S/4HANA Migration

HR/HCM is the module most often misunderstood in the context of S/4HANA migration. SAP’s stated policy is that “HR functionality moves to SuccessFactors (cloud HCM),” and HR functionality is not integrated into S/4HANA.

Functional Area	ECC HCM	Options After Migrating to S/4HANA	Japan-Specific Considerations
Personnel Master (PA)	Management of organizational and personal information	Migrate to SuccessFactors Employee Central	Complex management requirements for Japanese employment types (temporary staffing, secondment, contract employment, etc.)
Payroll	Standard Japanese payroll calculation	① Continue ECC Payroll in a “side-car” configuration ② SuccessFactors Employee Central Payroll (Japan-localized version) ③ Migrate to third-party payroll (COMPANY, SmartHR, etc.)	Japan-specific rules for overtime calculation, late-night premiums, and social insurance. Full Japan payroll support in SuccessFactors is still evolving even beyond 2025
Talent Management	Limited functionality	Move to SuccessFactors Performance/Succession and other cloud modules	Japanese-language support and alignment with Japanese-style evaluation processes
Time Management (TM)	ECC time-management functionality	SuccessFactors Time or a third party (KING OF TIME, etc.)	Japan-specific requirements such as Article 36 labor-management agreements, variable working-hour systems, and paid-leave management

It is strongly recommended that HR migration be organized as a separate “HR transformation team” from the S/4HANA migration team, advancing in parallel. Combining it into a single project causes the scope to become unmanageable.

Chapter 9: “Version Upgrade” or “The Next Business”? — The Strategic Value of S/4HANA Migration

Whether S/4HANA migration is viewed as “the cost of responding to the end of SAP maintenance” or as “an investment in digital management transformation” fundamentally changes the character, scope, and value obtained from the project. Even with the same migration expenditure, companies split into two groups after migration: those for whom “nothing is different from the old SAP” and those who “gain a competitive advantage.” This chapter explains what makes the difference.

9.1 Two Migration Mindsets

Perspective	Obligatory Migration (Prolonging the Status Quo)	Transformative Migration (Toward the Next Business)
Project purpose	“Respond to the end of maintenance in 2027”	“Evolve the business model on the foundation of S/4HANA”
Migration approach	Brownfield preferred	Choose Greenfield/Bluefield and redesign business processes
Add-on policy	Carry over existing add-ons as much as possible	Reduce add-ons as much as possible and rely on standard functionality
Definition of success	“Went live without incident”	“Business KPIs improved after migration”
Degree of management involvement	IT-department-led; management acts only as approver	C-level executives serve as sponsors, involved in the project every month
Post-migration outlook	“That’s done for now” → search for the next issue	Phase 2 (AI adoption, IBP integration, MES integration) is already planned
Typical outcome	“Pickled SAP” in the cloud. Costs are incurred with no transformation	Investment recouped within 3 years of migration; differentiation from competitors achieved

9.2 New Technical Capabilities Unlocked by S/4HANA

S/4HANA is not a “successor version” of ECC — it is a platform with a fundamentally different architecture. Correctly understanding its new capabilities is the first step toward turning the migration investment from a “cost” into an “asset.”

① Real-Time Integrated Management (Universal Journal)

In ECC, there was a time lag: “after FI’s monthly close, entries are posted to CO, and then the monthly report is created.” With the Universal Journal, all financial and management-accounting data is recorded in a single ledger at the moment it occurs.

• What becomes possible: A fundamental transformation in the speed of management decision-making — being able to see profitability by cost center, product, and region in real time, as of today

• What becomes possible: Faster monthly closing (in some cases, a provisional close can be done by the end of the day on the last day of the month, with the formal close completed the next business day)

• What becomes possible: Tracing “why this cost occurred” in a single screen, without moving back and forth between FI and CO

② Embedded Analytics

In ECC, the mainstream architecture was a “data warehouse” model, in which analytical data was extracted into BW and accumulated before reporting. S/4HANA has built-in “Embedded Analytics,” which analyzes ERP data in real time.

• Integration with SAC (SAP Analytics Cloud): Leverages S/4HANA’s real-time data directly in SAC dashboards and predictive analytics

• Smart Business Cockpit: A Fiori-based real-time management dashboard provided as standard

• BW/4HANA integration: When historical data is needed, integration with BW/4HANA enables combined real-time-plus-historical analysis

③ SAP Joule / Business AI

SAP has positioned “Business AI” as a core strategy for S/4HANA, embedding a large volume of AI functionality as standard between 2024 and 2026. These AI features are only guaranteed to work in a clean S/4HANA environment (one without excessive add-ons).

AI Feature	Overview	Business Impact
Joule (AI Assistant)	Talk to S/4HANA in natural language to retrieve relevant information and execute processes — for example, “list this month’s unpaid invoices”	Information gathering and processing without screen navigation. Boosts productivity for general users
AI Automated Journal Entry (Journal Entry AI)	Reads transaction documents and PDF invoices and automatically proposes journal entries; humans only confirm and approve	Automates AP/AR processing. Cases have reduced data-entry effort by up to 80%
AI Inventory Optimization	Learns demand forecasts and lead-time variability to dynamically optimize safety stock and reorder points	Simultaneously achieves inventory reduction (10–20%) and lower stockout rates
Predictive Payment Management	Uses AI to learn customers’ payment behavior patterns, automatically optimizing cash-inflow forecasts and collection timing	Shortens Days Sales Outstanding (DSO) and enables earlier detection of bad-debt risk
AI Supply Chain (IBP Integration)	Integrating S/4HANA with SAP IBP (Integrated Business Planning) achieves AI demand forecasting → automatic ordering → inventory optimization	Improves planning accuracy, reduces inventory costs, and reduces manual planning effort

④ Expanding into the Next Business with SAP BTP (Business Technology Platform)

SAP BTP is a “DX platform” built around S/4HANA as its core, not merely a peripheral tool for S/4HANA. Using BTP, you can build new business applications that integrate S/4HANA data with external systems, AI, and IoT.

• SAP Build (low-code development): Business departments can create apps and workflows that leverage S/4HANA data without programming

• Integration Suite: Integrates SAP SuccessFactors, Ariba, IBP, and DM with S/4HANA via APIs, realizing an end-to-end “One SAP” business flow

• Integration with external systems: Real-time data integration with non-SAP systems such as Salesforce or Workday via BTP

9.3 Concrete Value Cases That Captured “The Next Business”

The following cases represent companies that treated S/4HANA migration not as a “maintenance response cost” but as a “catalyst for business transformation.” Pay particular attention to the cases that tackled “chronic inefficiency that wasn’t even recognized as a problem.”

Value Case ①: A Company That Escaped a State Where “Excel Was Treated as the Official Management Report”

Background — This Had Become “Normal”

Industry: Diversified chemicals manufacturer (consolidated revenue of roughly 300 billion yen). In the ECC era: SAP ECC functioned merely as a “data-entry device” — data went in, but Excel is what came “out.” The monthly management-reporting workflow was: ① the accounting department extracts CSVs from FBL3N, FS10N, and similar transactions (at month-end, a combined 4 people × 3 days); ② paste into Excel by business unit → aggregate via pivot tables → create charts; ③ corporate planning consolidates these → manually pastes into PowerPoint → becomes the board meeting material; ④ executives only see the numbers “12–15 business days” after month-end. No one considered this a “problem” — the attitude was “we’ve always done it this way,” “Excel gives us more flexibility,” and “we can’t trust SAP’s numbers (because add-ons distort some data).” The add-on problem: 15 years’ worth of add-ons had piled up on ECC, resulting in multiple chart-of-accounts masters, a proliferation of company codes, and numbers that didn’t reconcile between reports — reinforcing a vicious cycle in which distrust of “we can’t use SAP’s numbers as-is” strengthened dependence on Excel.

What the Migration Project Did

[Migration policy: make the data “something you can trust”] Step 1: Consolidate the company code, chart of accounts, and profit center masters → the top priority was creating a state where “the same number appears no matter where you look.” Step 2: Redesign CO under Greenfield → consolidate FI, CO, and CO-PA into the Universal Journal (ACDOCA) → real-time visibility into “today’s costs and revenue” without a monthly closing process. Step 3: Build an SAC (SAP Analytics Cloud) dashboard → train corporate planning staff to build SAC models themselves, achieving internalization → executives now access it directly from tablets; PowerPoint distribution was discontinued. Step 4: Institutionalize a rule that “reporting via Excel is prohibited” → the CIO and the head of corporate planning declared they would “abolish Excel-based management reporting within 6 months of go-live” → this declaration created an environment where the field had no choice but to use SAP.

Results

Lead time for monthly management reporting: 15 business days → the next business day (real-time dashboard). Effort for preparing management reports: a combined 4 people × 3 days per month → zero (eliminated). Change in the quality of board meetings: from “a meeting to confirm last month’s numbers” to “a meeting to discuss next month’s and next quarter’s actions.” In-house SAC modeling: corporate planning staff can now design and update their own KPIs. Secondary effect: the restoration of trust — “SAP’s numbers can be believed” — was the biggest change of all.

The essence of this case lies in a cultural shift where “SAP, not Excel, is the source of truth.” Beyond the technical migration, the behavioral change of “executives looking directly at SAC” moved the entire organization.

Value Case ②: A Migration Whose Primary Purpose Was Rebuilding a “Data Foundation That Could Withstand the AI Era”

Background — Realizing “The Data Can’t Be Used” When Trying to Introduce AI

Industry: Industrial equipment manufacturing (4,500 employees). How the problem came to light: In 2024, management launched an internal pilot to leverage ChatGPT, kicking off a project to “build AI that automatically detects abnormalities in manufacturing costs.” However, once they tried to analyze the data, problems surfaced: ① Data was scattered across “SAP,” “Excel,” “Access,” and handwritten ledgers, making it impossible to determine which was correct; ② SAP data could only be retrieved as “numbers after add-on processing,” meaning the raw journal-entry data was contaminated and unusable as AI training data; ③ The item master was not maintained, and the same part had up to three different codes, so AI could not recognize it as “the same part”; ④ Ten years of historical data was fragmented across multiple databases, making it unusable for time-series machine learning. Conclusion: “Nothing will work until the data foundation is put in order before introducing AI.” This became the primary motivation for the S/4HANA migration.

What the Migration Project Did

[Migration policy: design S/4HANA as “the fuel tank for AI”] ① Establish master-data governance (MDG: Master Data Governance) → centrally manage item, business partner, and cost-center masters → enforce the rule “the same part gets the same code” at the system level. ② Accumulate clean transactional data via the Universal Journal (ACDOCA) → design so that “raw source data” — not numbers already processed by add-ons — is recorded in ACDOCA → data can be retrieved at the granularity of product, cost center, and process. ③ Integrate with SAP BTP (Business Technology Platform) → connect S/4HANA data to BTP’s data lake → analytics tools such as Python/R can reference S/4HANA data directly via BTP. ④ Establish data-quality scores → define the standard for “data quality usable for AI training” (completeness, consistency, accuracy) → make meeting this standard through data cleansing during migration a condition of migration completion.

What Was Achieved One Year After Migration

[Achievement ①: AI for detecting manufacturing-cost anomalies (the original goal)] AI trained on S/4HANA manufacturing-performance data accumulated in BTP now automatically detects when “this cost center’s results this month deviate from the pattern of the past three months.” Early warning of cost anomalies moved from monthly checks to real-time alerts. [Achievement ②: Detecting equipment-failure precursors (an unanticipated application)] By integrating with S/4HANA DM and ingesting PLC data, AI became able to detect “three days before failure” from patterns in equipment current readings. [Achievement ③: Predicting order-to-shipment delays (new customer value)] AI cross-analyzes SAP’s PP, MM, and SD data to automatically judge “there is a 73% chance this order will experience a manufacturing delay” at the time of order confirmation, allowing sales staff to proactively discuss delivery-date changes with customers. [Message to management] “The S/4HANA migration was not about ‘solving the 2027 problem’ — it was about ‘building a data foundation that AI could use.’ One year after migration, three AI projects are up and running. Before the migration, we couldn’t get even one off the ground.” (Comment from the IT executive in charge)

Value Case ③: The Disappearance of “Month-End Overtime Hell” Through Accelerated Closing (Retail and Distribution)

Background and Change

Industry: Retail and distribution (200 stores, 3,500 employees). In the ECC era: for 10 days spanning month-end to the start of the new month, 30 accounting staff were fully occupied with monthly closing work — routine late-night overtime and weekend work, with month-end referred to as “the battlefield.” Cause: the entire flow of FI/CO posting, cost allocation, special-ledger reconciliation, BW extraction, and Excel aggregation had to be advanced manually, step by step, by hand. After S/4HANA migration: with the Universal Journal, CO postings are completed the instant journal entries occur (eliminating the posting step); cost allocation runs automatically via CO’s automatic allocation cycle in an overnight batch; and profit and loss by store and product category is displayed in real time in SAC. Quantitative effects: days required for monthly closing went from 12 days to 3 days; accounting-department month-end overtime fell from a combined 500 hours/month to 80 hours/month (an 84% reduction); 8 of the 30 accounting staff were redeployed to “store profitability improvement analysis” work; a secondary benefit is that faster numbers now enable substantive discussion of action plans at management meetings. In the words of one staff member: “Month-end isn’t scary anymore. I can hardly believe what we used to spend all that time doing. It’s less that SAP changed, and more that the way we work changed.”

Value Case ④: Solving the “Veteran Staff Retirement Problem” with AI-Automated Journal Entries (Mid-Sized Manufacturing)

Background and Change

Industry: Precision parts manufacturing (700 employees). The essence of the problem: two veteran accounting staff (with 25 and 28 years of tenure) were scheduled to retire between 2026 and 2027; only these two knew the “complex journal-entry rules, how to use different accounts, and the quirks of the add-ons”; attempts at knowledge transfer struggled because “years of intuition and experience” were hard to put into words; this created a management crisis of “accounting won’t function once these two leave.” Response through the S/4HANA migration: redesigned FI/CO under Greenfield, centering on Joule and AI-automated journal entries. ① Systematizing journal-entry rules: the veterans’ tacit knowledge was fully encoded into the system as FI automatic posting rules (substitution/validation) before migration (a 3-month “knowledge transfer → configuration” effort). ② Introducing AI-automated journal entries (SAP Business AI): AI scans vendor invoices and expense reports, automatically proposing the account and cost center, with staff only confirming and approving. ③ Querying via Joule: asking “tell me last month’s manufacturing cost by cost center” prompts Joule to reference ACDOCA and answer immediately — the behavior of “searching through Excel” has disappeared. Quantitative effects: journal-entry effort fell from 400 hours/month to 60 hours/month (an 85% reduction); accounting operations are now maintained by two staff members in their third year after the veterans’ retirement; the key-person risk of “we’re in trouble once the veterans leave” has largely been eliminated; annual hiring and training cost savings: approximately 15 million yen.

Value Case ⑤: Eliminating the “Black Box of Factory Costing” (Automotive Parts Manufacturer)

Background and Change

Industry: Automotive parts manufacturing (3 plants, 2,000 employees). Problems in the ECC era: for more than 10 years, the company had been unable to determine the “true cost” of each product. Reason ①: the costing add-ons were so complex that even the responsible staff could not explain the calculation logic. Reason ②: manufacturing-performance data was manually keyed into SAP from the MES, with delays, omissions, and errors becoming routine. Reason ③: process-level time data was managed on paper work-logs, entered into SAP only in monthly batches, turning cost calculation into a “month-end estimate.” As a result, the most basic question — “is this product actually profitable?” — could not be answered, and sales staff negotiated prices based on “gut feel and past custom.” Response through the S/4HANA migration: ① Integrated MES (SAP Digital Manufacturing) with S/4HANA → manufacturing performance, labor hours, and equipment utilization now flow into S/4HANA’s PP in real time → costs are posted the instant a process step is completed. ② Fully leveraged Material Ledger (actual costing) → real-time calculation of actual manufacturing cost by product and lot → visibility into “the cost of the lot being manufactured right now is XX yen, as of this moment.” ③ Visualized cost variances in SAC → real-time dashboards showing the variance between standard and actual cost (material-price variance, processing-cost variance, efficiency variance) at the granularity of product × process × plant. Quantitative effects: answering “is this product profitable?” went from a month-end estimate to real-time visibility; the cycle for grasping cost variances went from monthly to daily; low-profitability products were identified and repriced — 4 products had their prices revised within 6 months of migration; annual profitability improvement: approximately 230 million yen (from price revisions). Change among sales staff: “Before, we had to check with the costing department every time to find out how much of a discount we could offer. Now we can negotiate with customers on a tablet while looking at real-time product costs.”

Value Case ⑥: Migrating to Become “A Company That Can Use AI” (As a Precondition for Digital Transformation)

Between 2025 and 2026, a growing number of companies have decided to migrate to S/4HANA after discovering, in the course of seriously pursuing AI adoption, that “SAP’s data cannot actually be used.” Below is the logical structure of cases in which migration secured management approval as a “precondition for AI adoption.”

What They Wanted to Do with AI	Barrier in the ECC Era	What Becomes Possible After S/4HANA Migration
Build a demand-forecasting AI	Order, inventory, and sales data was scattered across SAP, Excel, Access, and non-core systems; no clean data existed that AI could be trained on	AI can access a single, integrated data model (Universal Journal + BTP) combining S/4HANA’s SD, MM, and PP data
Automatic detection of cost anomalies	CO add-ons were so complex that the data structure was opaque; even people could not explain why a given figure came out the way it did	FI, CO, and CO-PA are unified via the Universal Journal; AI trains on clean ACDOCA transaction data and automatically detects pattern deviations
Early detection of supplier risk	Supplier data was scattered across SAP and Excel; history of payment delays, quality issues, and lead-time variability could not be tracked	Integrating SAP Ariba with S/4HANA allows AI to learn supplier quality, payment, and lead-time data and automatically calculate a risk score
Early signs of customer churn or lost sales	Order, shipment, billing, and complaint data was scattered across SD and Excel, making it impossible to capture changes in customer behavior	Integrating SD and CRM data lets AI combine patterns such as “declining order frequency, rising complaints, and payment delays” to predict churn risk
Detecting expense fraud or anomalies	Even when anomalous values existed in FB60/MIRO input data, only numbers after add-on processing were visible	Joule/Business AI detects “unusual patterns” in real time at the moment of journal entry, with a complete audit trail preserved in ACDOCA

These AI use cases are not necessarily impossible without migrating to S/4HANA. In reality, however, “contaminated data, scattered data, and the opacity caused by add-ons from the ECC era” have been the biggest barriers to AI projects. Framing the S/4HANA migration as an advance payment on AI investment makes it easier for management to understand the “meaning” behind the migration cost.

9.4 The Two-Tier Structure of ROI

Evaluating the ROI of an S/4HANA migration “based on cost reduction alone” is a half-measure. A true ROI evaluation must incorporate both cost reduction (Tier 1) and the creation of revenue opportunity (Tier 2).

ROI Tier	Type of Benefit	Specific Example	Timeframe
Tier 1: Cost Reduction	Reduced IT operating costs	Savings on ECC maintenance fees and paid extended-maintenance fees	Realized immediately after migration completes
Tier 1: Cost Reduction	Paperless operations and automation	Reduced labor costs from automated invoice processing and journal-entry automation	6–12 months after migration
Tier 1: Cost Reduction	Infrastructure consolidation	Server and data-center cost reduction from RISE migration	Immediately after migration
Tier 1: Cost Reduction	Reduced add-on maintenance cost	Lower internal IT and external maintenance costs from add-on reduction	Immediately after migration
Tier 2: Revenue Opportunity	Faster decision-making	Early problem detection and loss avoidance through real-time management dashboards	3–6 months after migration (once adopted)
Tier 2: Revenue Opportunity	Inventory optimization	Improved cash flow from AI-driven inventory reduction	6–18 months after migration
Tier 2: Revenue Opportunity	New products and services	Development of new digital services on BTP and reinvention of customer experience	2–5 years after migration
Tier 2: Revenue Opportunity	Shift of talent to higher-value work	Automation reduces routine work, shifting staff into analytical and strategic roles	1–3 years after migration

9.5 Criteria for Avoiding a Merely “Obligatory Migration”

Below are warning signs that a migration project will end up as “a mere version upgrade” (an obligatory migration), along with prescriptions for avoiding that outcome.

Warning Sign	Risk Implied	Prescription
Requirements defined as “as long as it can do what our current ERP does, that’s fine”	S/4HANA’s new features end up completely unused	Adopt Fit to Standard, and design the “use cases” for new features before starting the migration
The project’s success criterion is only “going live”	No one measures the business value delivered after go-live	Set success KPIs (closing days, inventory reduction rate, journal-entry automation rate, etc.) before migration and agree on them with management
Management’s involvement in the project is limited to “approval”	Top-level commitment to business transformation is absent; resistance from the field prevails	Appoint a C-level executive as “champion of transformation”; review project progress and transformation outcomes at monthly management meetings
The project plan contains no plan for leveraging AI or analytics	After migration, saying “let’s use AI features” finds the environment unprepared	Build a PoC (proof of concept) for Joule, Business AI, and SAC integration into the migration design phase
There is no Phase 2 plan after migration	Migration completion is treated as the end of the project, with no plan for ongoing value creation	Create a roadmap of “Phase 1 (migration) → Phase 2 (AI/analytics adoption) → Phase 3 (BTP expansion)” at the start of the migration project

9.6 Three Principles for Making S/4HANA Migration a “Catalyst for Management Transformation”

Principle ①: Define It as a “Business Transformation,” Not an “IT Project”

Position and agree, at the management-meeting level, that the project is not “upgrading SAP’s version” but “a business transformation to make management decision-making real-time and build competitive advantage.” This difference in language significantly affects management’s degree of involvement, the speed of budget approval, and the field’s willingness to accept change.

Principle ②: Draw the “One-Page Vision” of the Post-Migration State First

The first priority is to express “what the company looks like three years after the S/4HANA migration (the To-Be state)” in a single diagram and gain agreement from all stakeholders. A vision accompanied by concrete figures — such as “complete monthly closing within 3 business days and review real-time P&L at a weekly management meeting” or “achieve a 70% AI journal-automation rate and shift accounting staff into analytical work” — becomes the compass for transformation.

Principle ③: Position Add-on Reduction as a “Precondition for Using New Features,” Not Merely a “Cost-Cutting Measure”

When add-ons are numerous, S/4HANA’s AI features, Embedded Analytics, and Business AI may fail to operate normally. Reframing add-on reduction not as “the hardship of cutting costs” but as “preparing the environment needed to use AI and analytics features” increases the field’s willingness to accept the change. An appeal along the lines of “eliminating this add-on lets us use this exciting new feature” is effective.

Chapter 10: Why Costs Balloon Absurdly — The Anatomy of Cost Explosion and the Fate of Migrations Without Business Reform

Many S/4HANA migration projects report that “the initial estimate ballooned to 1.5–3 times the original figure.” There are also no shortage of cases where, due to the difficulty of explaining ROI to management, a project gets approved but ends up as “we don’t know what it was all for” once complete. This chapter explains, with concrete cases, the mechanics of cost explosion, the pitfalls of explaining ROI, and just how different the outcomes are between a migration that includes business reform and one that does not.

10.1 Anatomy of Cost Explosion — Why Estimates Balloon to 2–3 Times

The structure behind massive cost overruns in S/4HANA migration projects can be explained by a fairly consistent set of combined factors. The preconception “our company will be fine” is the most dangerous of all.

Cost Explosion Factor	Typical Scenario	Typical Magnitude of Overrun	Preventive Measure
Underestimating add-on remediation	Estimating “there are 200 add-ons, but only 50 will need remediation,” when in fact dependencies mean 150 actually require remediation. At an average of 5 million yen per add-on, that is an additional 500 million yen	×1.5–×3	Conduct a detailed “add-on impact assessment” before migration. Always build a 30–40% contingency into the estimate
Collapse of Fit to Standard	The project declares a “zero add-ons” goal at the outset, but strong demands from business departments lead to approvals piling up under “just this one function,” ultimately resulting in more add-ons in the new environment than before migration	Cases where a zero-add-on goal ended up at 120% of the pre-migration count	Concentrate approval authority for new add-ons with management (CIO/COO); establish a governance committee to prevent “just this once” requests from both the field and the SI vendor
Rising SI consultant rates	An S/4HANA consultant who cost 5 million yen/month in 2024 rose to 7.5–9 million yen/month by 2026. With a team of 10 on a 12-month project, rate inflation alone can create a discrepancy of around 300 million yen	+20–50% per year	Start the project earlier. Lock in consultant rates with multi-year contracts. Increase the share of in-house SAP talent
Explosion in testing effort	The combined effort for unit testing, integration testing, regression testing, and UAT (user acceptance testing) more than doubles the original plan; preparing the test environment and cycling through defect fixes ends up taking three times the planned effort	×1.5–×2.5	Introduce test-automation tools (such as SAP Test Automation by Tricentis). Clearly define cutover criteria before migration to prevent an endless cycle of fixes
Unforeseen data-migration issues	The volume of contaminated ECC data (duplicate masters, inconsistent lots, unclosed documents) is greater than expected, requiring months of data cleansing; effort balloons due to the sheer number of exception cases	×2–×4 (for the data-migration workstream alone)	Conduct data-quality investigation (data profiling) early. Decide “what will not be migrated.” Exclude historical data older than a certain number of years from the migration scope
Scope expansion (creep)	What was originally “Japan headquarters only” changes midway to “also include three overseas subsidiaries.” Additions late in the project cause effort and duration to spike	An additional 30–50% of total project cost	Establish a Change Control Board for scope changes. Require that every scope addition come with an estimate of additional cost and duration, and mandate management approval
Post-go-live defect response	Under a “go live now, fix it later” policy, confusion in the field is maximized, and emergency response, night-shift work, and additional development generate unplanned costs for the six months following go-live	Post-go-live additional cost: 20–40% of the original estimate	Strictly set cutover criteria (zero critical bugs, 100% pass rate on business-scenario testing). Establish a structure where management can decide to postpone go-live if criteria are not met

Actual Scale of Cost Overruns (from Public Information)

[Large-scale food manufacturing migration] Original plan: 21.5 billion yen over 3 years → Final actual: 34.2 billion yen over 5 years (1.59 times the cost, 2 years longer). [Typical pattern for mid-sized manufacturing migrations] Original estimate: 500 million yen (including SI consulting fees) → Final: 900 million to 1.2 billion yen (more than double, due to accumulating add-on remediation, data migration, and testing effort). [Aggregated data from an IT research firm (ISG, 2026)] About 60% of S/4HANA migration projects experience budget overruns or schedule delays. Average overrun: +35% of budget, +8 months of schedule. “Never trust the initial estimate” — this is the iron rule of S/4HANA migration.

10.2 The Difficulty of Explaining ROI — The Structure Behind Being Unable to Answer “How Much Will This Make Us?”

The biggest obstacle in the management approval process for S/4HANA migration is “explaining the benefits.” Costs can be calculated clearly, but most of the benefits carry the fundamental problem of being “difficult to quantify.”

Why Is ROI Hard to Explain?

Type of Benefit	Difficulty of Quantification	Gap with What Management Wants to Hear
Avoiding security risk	You can calculate “if a data breach occurred, the loss would be X billion yen,” but whether it occurs is probabilistic; the “value of it not happening” is hard to explain	Gets stuck on the counterargument, “wouldn’t nothing change if there’s no breach?”
Faster decision-making	“Monthly closing shortened from 5 business days to 2” is measurable, but “how much extra revenue does that generate” cannot be calculated directly	The IT department gets stuck when management asks, “so what’s the benefit of it being 3 days faster?”
Regulatory compliance	Compliance has value as “avoiding the penalty of non-compliance,” but if no penalty has actually occurred, it isn’t recognized as having value	Tends to devolve into the argument, “can’t we comply with the Electronic Books Preservation Act using paper anyway?”
Improved operational quality	Quality improvements such as fewer posting errors or fewer missed inventory entries are indirect and hard to measure	Easily dismissed as “fewer mistakes doesn’t directly translate to profit”
Future flexibility and extensibility	“Being able to use AI and new features on S/4HANA” is future value, but it doesn’t show up in this period’s numbers	Loses to the deferral argument, “we can think about the future when the future comes”

Failure Patterns in ROI Explanation (Real Examples)

Failure Pattern ①: A Case Where Approval Was Sought on Cost Reduction Alone

The IT department calculated that “the S/4HANA migration will reduce annual IT operating costs by 30 million yen” and sought management approval on that basis. Migration cost: 800 million yen → payback period: 27 years. Management’s reaction: “If it takes 27 years, there’s no point — there are better uses for the money.” ↓ The project was not approved; the company chose to prolong the current system (paid extended maintenance) instead. ↓ Three years later: the accumulated cost of paid maintenance ended up roughly equal to what the migration would have cost. Meanwhile, the worsening consultant shortage pushed the eventual migration cost 40% higher than the original estimate.

Failure Pattern ②: A Case Where No One Could Tell What Had Actually Changed After Migration

Because no benefit KPIs were set before migration, the company ended up, after go-live, in a state where “operations are nearly the same as in the ECC era, add-ons increased, and costs increased” — prompting management to ask “what was that investment for?” The IT department answers that “the foundation has been strengthened and maintenance risk has been reduced,” but management keeps asking, “so how much did profit increase?” No answer is ever given, and time simply passes.

Three Techniques for Making a Successful ROI Case

Technique ①: Calculate the “Status Quo Cost” of Not Migrating

The approach that resonates most with management is to add up the cost of not migrating and compare it against the migration cost. Summing paid extended-maintenance fees, the risk of rising consultant costs, the expected loss from security incidents, the manual-labor cost of regulatory compliance, and the opportunity cost of competitive disadvantage often results in a total that exceeds the migration cost.

Cumulative Cost of “Not Migrating” (Illustrative)	Approximate Amount	Notes
Paid Extended Maintenance (2028–2030; an additional 20–30% of the annual maintenance fee)	+200–500 million yen over 3 years	Varies significantly by contract terms and scale
Consultant market inflation (rates rise further if migrating in 2028–2030)	+20–40% of the migration cost	Compared with starting before 2027
Expected loss from security incidents (probability × loss amount)	Equivalent to 50–200 million yen annually (probability-adjusted)	Average data-breach loss in manufacturing: several billion yen × probability of occurrence
Manual-labor cost of regulatory compliance (case-by-case handling of tax reform and accounting-standard changes)	10–50 million yen annually	Custom handling is required each time once maintenance has ended
3-year cumulative total	500 million to 1.5 billion yen	Varies by industry, scale, and number of add-ons

Technique ②: Define a “Quick Win” and Prove It First

Trying to prove the “ROI of the entire migration” tends to spark endless debate. Instead, define “a single, concrete benefit achievable soon after migration” and demonstrate the numbers through a PoC (proof of concept) or an early pilot. Small but demonstrable results — such as “raise journal-automation rate to 60% in Division A within 3 months” or “shorten the procurement department’s payment cycle by 3 days” — earn management’s trust.

Technique ③: Set and Measure KPIs “Before Migration” and Compare “After Migration”

To be able to measure “what changed” after migration, it is necessary to record baseline (As-Is) figures before migration begins. Agree, “at the start of the migration project,” on indicators that can measure improvement after migration — such as days to close the books, inventory turnover days, journal-entry volume and processing effort, procurement lead time, and defect rate. Without this, no one will be able to tell what actually changed after migration.

10.3 The Fate of Migration Without Business Reform — “Pickled SAP in the Cloud”

What kind of outcome does “migration without business reform” produce? The following is a typical pattern synthesized from multiple real cases.

A Typical Failure Scenario: “The Technical Migration Succeeded, but Nothing Changed”

[Background] Manufacturing; 3,000 employees. ECC had been running for 15 years, with 470 add-ons. [Migration policy] “The fastest possible Brownfield migration. Don’t change the business.” [Project progress] Add-on impact assessment: 350 add-ons turned out to require remediation (original estimate: 200). Additional requirements from business departments: mid-project requests for 80 new add-ons. Without management approval, the field and the SI vendor agreed “this feature is necessary” and approved it → scope expanded. [Result] Original cost: 700 million yen → final cost: 1.4 billion yen (double); original duration: 18 months → final duration: 30 months (1.67 times); number of add-ons after migration: 530 (60 more than before migration); use of “real-time analytics” and “AI-automated journal entries” was pushed to “consider in the next phase” — and three years later, that “next phase” still had not started. [Current state (4 years after migration)] Add-on maintenance cost: 200 million yen per year (1.4 times the ECC-era level); as the next S/4HANA major upgrade approaches, the same problem is resurfacing. Comment from the field: “I can’t really tell what changed with SAP — the screens are just different.” Comment from management: “We spent 1.4 billion yen — what actually changed?”

Why “Migration Without Business Reform” Keeps Repeating

• The SI vendor’s revenue structure: designing, developing, and maintaining add-ons is a revenue source for SI vendors. A structure exists in which vendors say “let’s align to standard” while still accepting add-on development orders without turning down business-department requests

• Resistance from business departments: field-level pressure to “not change the way we currently do things” will always win out in a project with insufficient change management. Unless management explains “why we are changing,” the field will not change

• The IT department’s priorities: once “getting to go-live” becomes the ultimate success criterion, business transformation becomes secondary. In the run-up to go-live, decisions to defer transformation “in order to just get it running” become widespread

• Management “leaving it entirely to others”: when the migration project is treated as purely an IT matter and business-side stakeholders do not participate, no one ends up fundamentally reviewing the business processes

10.4 Success Cases of Migration with Business Reform — Fundamentally Changing How Work Gets Done

What successful migration projects have in common is a perspective of “using SAP’s data to fundamentally change how work is done.” The important sequence is not “adapting to SAP,” but “redesigning the business starting from what can be done with SAP’s data.”

Success Case ①: Abolishing Weekly Excel Reports and a Revolution in Decision-Making (Manufacturing)

Case Overview

Industry: Consumer goods manufacturing (1,500 employees). Migration approach: Greenfield (thorough Fit to Standard). Theme: “Completely eliminate the Excel-based work that was taken for granted in the ECC era.” [Business process in the ECC era (As-Is)] Every month-end: each department extracted CSVs from SAP → aggregated in Excel → submitted to the management-accounting department. The management-accounting department consolidated company-wide: 3–4 staff spent 2–3 days merging and formatting in Excel. Management meeting (monthly): numbers were finally ready 10–12 business days after month-end. Because “the numbers were old,” decisions at the meeting amounted to “discussing last month.” [After S/4HANA migration (To-Be)] With the Universal Journal + SAC (SAP Analytics Cloud), company-wide P&L is displayed in real time on SAC screens. Every morning at 9 a.m., the management dashboard refreshes automatically, showing the previous day’s sales, cost, and profit. Weekly management meetings (once a week): decisions are made while checking the latest numbers on the spot. [Effects] Excel report-compilation work: 60 combined hours per month → zero (eliminated). Freshness of information at management meetings: 10–12 days old → 0 days (real time). Speed of decision-making: shortened from monthly to weekly. Two of the four management-accounting staff were redeployed to “data analysis and forecasting” work. [Success factor] A concrete goal of “abolishing Excel” was set before migration, and the management-accounting department itself participated in designing its elimination — converting “resistance to abolition” into “anticipation of new ways of working.”

Success Case ②: Automating Purchase-Order Decisions in Procurement (Chemicals Manufacturer)

Case Overview

Industry: Chemicals and materials manufacturing (800 employees). Migration approach: Bluefield (Greenfield for the procurement and inventory departments). Theme: “Transform procurement staff from ‘order-placement clerks’ into ‘supplier-strategy specialists.'” [Business process in the ECC era (As-Is)] Every day, 5 procurement staff checked inventory → checked reorder points → created purchase orders → requested approval → sent them out. Judgment was based on “experience and gut feel,” with reorder timing varying by staff member. Month-end inventory built up because of a habitual practice of “ordering a bit extra just in case.” [After S/4HANA migration (To-Be)] With MRP Live and Material Ledger, the system generates automatic order recommendations based on demand forecasts. Procurement staff’s role shifted to “reviewing and approving AI order recommendations” (an assistive judgment role). Exception-focused management: the system automatically orders standard items, while staff concentrate on exceptions, new suppliers, and price negotiations. [Effects] Inventory reduction rate: 18% (compression of excess inventory). Purchase-processing time: fell from an average of 45 minutes to 8 minutes per order. Two of the five procurement staff were redeployed to “supplier development and cost-reduction negotiation.” Annual procurement cost savings: approximately 80 million yen. [Success factor] Reframed the anxiety of “our jobs will disappear” as the opportunity of “we can focus on higher-value work” — a change design that let staff feel they could “concentrate on work that leverages their own experience.”

Success Case ③: Cutting Off “Future Costs” Through Add-on Reduction (Industrial Equipment Manufacturer)

Case Overview

Industry: Industrial equipment manufacturing (2,200 employees). Initial number of add-ons: 380. Migration policy: “Treat add-on reduction as the single greatest source of ROI.” [Add-on reduction process] ① Inventory: evaluated all 380 add-ons on “frequency of use,” “potential for replacement,” and “remediation cost” (3 months). ② Classification: retire (unused or replaceable with standard functionality) — 140 (37%), retired immediately; replace with standard functionality — 95 (25%), addressed via business-process change; simplify (reduce functionality to bring closer to standard) — 80 (21%), simplified with reduced remediation; must be remediated (directly tied to competitive advantage) — 65 (17%), remediated. ③ Post-migration add-on count: 65 (an 83% reduction from before migration). [Cost impact] Add-on remediation cost (at migration): reduced by roughly 700 million yen compared with the norm (no remediation cost incurred for retired/replaced add-ons). Annual add-on maintenance cost: fell from 120 million yen to 20 million yen per year (a reduction of 100 million yen/year). Five-year cumulative impact: approximately 1.2 billion yen (combining reduced migration cost and reduced ongoing maintenance cost). [Secondary effects] Aligning with standard functionality made S/4HANA’s new features (Joule, Embedded Analytics) usable. The scope requiring remediation at the next SAP version upgrade fell sharply to 65 items (17% of the 380 in the ECC era). [Success factor] Business departments voluntarily participated in the search for retirable add-ons. Resistance to retirement was minimized by offering a trade-off: “if we eliminate this add-on, we gain access to this standard feature instead.”

10.5 A Practical Framework for “Rethinking Work by Leveraging SAP Data”

Making a migration with business reform succeed requires shifting from the mindset of “porting the current business flow onto S/4HANA” to “first understanding what S/4HANA makes possible, then redesigning the business flow from scratch.” A practical framework is presented below.

Step 1: Inventory “Who Is Making What Decisions, for What Purpose”

Classify the tasks on which people currently spend time into “judgment-based” and “task-based” work. “Judgment-based” work (what to order, which cost center to allocate to, how to judge pass/fail on quality) has the potential to be supported or automated using SAP data. “Task-based” work (manually entering data, transcribing PDFs into Excel, routing approvals by email) can be replaced by S/4HANA’s automation and workflow capabilities.

Type of Work	Specific Example	Direction for Replacement with S/4HANA
Manual entry and aggregation in Excel	Each department submits Excel files at month-end → consolidated by hand	Real-time automatic aggregation via the Universal Journal + SAC dashboard. Excel eliminated
Handling PDFs and paper	FI staff visually enter suppliers’ paper invoices into SAP	AI OCR + automated journal-entry proposals (Joule/AI-automated journal entries). Staff only confirm and approve
Confirmation and approval by email or phone	Confirming “is it OK to proceed with this order?” by email	Fiori workflow: push notifications to approvers, approved from a smartphone. Email eliminated
Order and inventory decisions based on experience and gut feel	“Let’s order a bit extra this month, just in case (gut feel)”	MRP Live + AI inventory optimization: data-driven automatic order recommendations, with people judging only exceptions
Preparing monthly reports	Aggregating in Excel, creating charts, formatting into PowerPoint	Automatically generated SAC dashboards; executives check directly on a tablet. Report-creation work eliminated
Manual cost allocation	Manually calculating and allocating cost-center expenses in Excel each month	The system automatically executes CO’s automatic allocation rules (OKS7); monthly work shrinks to a matter of seconds

Step 2: Separate “What SAP Does Automatically” from “Where People Create Value”

The purpose of migration is not “replacing people with a system,” but “building a structure where the system handles routine processing, freeing people to concentrate on judgment, creativity, and relationship-building.”

• Leave to SAP: data entry, posting, aggregation, routine reports, order recommendations, routing workflows, automated journal entries, inventory calculations

• Reserve for people: judgment on exceptions, negotiating relationships with suppliers, proposals to customers, planning new initiatives, business analysis using SAP data, developing team members

Agreeing on this “division-of-roles design” with business departments before migration is the single most important point for making business reform succeed. The only way to prevent the outcome of “nobody’s job changes even after introducing SAP” is for business departments to draw their own To-Be picture of “who will be doing what after migration.”

Step 3: Design Change Management as “Participation,” Not “Training”

A passive approach of “let’s take S/4HANA training and learn the operations” will not bring about business reform. The key is for business departments to be involved in the migration project as “the designers of their own work.”

• Business-department representatives (key users) design the business processes themselves: rather than IT staff or SI consultants proposing “let’s change it this way,” field key users draw “our own new way of working”

• Talk about “the value created,” not “the task eliminated”: avoid the framing “this task will disappear,” and instead frame the change as “you can now use this time for such-and-such”

• Stage early success experiences (quick wins): create opportunities, in a sandbox environment before go-live, for business departments to feel “this is convenient” firsthand. This gives rise to self-motivated change champions from within the field

Conclusion: The Real Answer to the “SAP 2027 Problem”

The real answer to the 2027 Problem is not “migrating to S/4HANA.” It is: “using the opportunity of migrating to S/4HANA to settle the inefficiencies accumulated over the years, the debt of add-ons, and the culture of Excel and paper — and to achieve fast, precise management that runs on SAP’s real-time data.” Between a migration that achieves this and one that merely “switches from ECC to S/4HANA,” the investment amount may be the same, but the difference in competitive strength five years later is night and day. Ultimately, the difference between a migration that becomes absurdly expensive and one that creates value comes down to one thing: whether management has the genuine resolve to actually change the way the business operates.

End