What SAP S/4HANA Implementations Taught Me About Real Business Transformation
When I joined EY in July 2024 as a Senior Analyst, I expected to spend my days configuring systems and optimizing processes. Instead, I was placed on a large international retail transformation project - a legacy system migration to SAP S/4HANA that would touch business operations across multiple geographies.
By September 2025, I was promoted to Associate Consultant. But the real education happened long before the promotion. It was in the data migration team, where I worked alongside not just the client's data team, but coordinated with SAP module teams (SD, MM, and others), SIT teams, UAT teams across different lines of business. That cross-functional coordination? That's where I saw what actually matters in transformation.
The Real Transformation Isn't Technical
My first realization came when we started mapping master data with our counterparts on the client's data migration team. On paper, migration seemed straightforward: extract legacy data, transform it, load it into S/4HANA. But coordinating between two teams - EY's on the loading side, the client's on the extraction side - taught me something immediate: technology is the enabler, not the transformation itself.
Working alongside the client's migration team, using LSMWs to automate data loads, creating load-ready templates, and running validation cycles together taught me something critical. The code execution is easy. Getting two teams across different organizations, in multiple countries, to understand the same data structures and agree on the migration strategy? That's transformation.
What Actually Matters in Data Migrations (From a Junior Consultant's View)
I'm not going to pretend I understand all the strategic layers of enterprise transformation. I was in a junior role on the data migration side. But I saw three things that mattered:
1. Nobody Works Alone - Data migration wasn't just our team and the client's extraction team. We coordinated with teams from various lines of business preparing for testing, SIT teams running integration tests, UAT teams preparing business users, and ABAP teams building custom programs. When I created a load-ready template, it affected what the testing teams could validate. When the UAT team found data inconsistencies, it came back to our validation cycles. When ABAP teams needed specific data structures for custom programs, we had to adjust our loads accordingly. I realized quickly: you can't understand your piece without understanding how it connects to everyone else's piece.
2. Data Quality Compounds - Small decisions in data migration had ripple effects. A field we thought was optional turned out to be critical for reporting in one of the business lines. A master data structure we didn't fully validate broke processes in another line of business. Data we didn't validate properly caused issues in custom programs built by ABAP teams. I learned that data quality isn't just about technical correctness. It's about whether downstream teams (SIT, UAT, module teams, ABAP developers) can actually use the data to do their jobs.
3. Communication is the Real Work - The technical work is 30% of a transformation. The other 70% is making sure two teams across different organizations, in different countries, with different incentives and pressures, understand each other. I learned this the hard way.
Three Silent Killers of Data Migrations (From What I Saw)
1. Assuming Your Team Works in Isolation
I watched data loads fail because we didn't coordinate with teams from various business lines early enough about master data. We tested things in our environment that broke in theirs. ABAP custom programs didn't work because the data formats weren't what developers expected. The lesson: you're never just loading data. You're feeding downstream teams - SIT teams, UAT teams, teams from different business lines, ABAP developers. If you don't understand their needs, your work will fail in their hands.
2. Underestimating Communication and Documentation
We spent weeks creating technically perfect load programs. But when the UAT team tried to validate the data, they didn't understand why certain transformations happened. That gap - between what we built and what they needed to understand - caused more problems than technical bugs ever did.
3. Treating Data Preparation as "the Technical Team's Problem"
The client's extraction team would prepare data one way. We'd receive it, realize the structure wouldn't work, and it would ping-pong back and forth. The projects that worked had someone (even if junior, like me) sitting in meetings explaining to both teams what the target structure needed to be. Not delegating. Coordinating. Our extraction team needed to understand what S/4HANA demanded. Our loading team needed to understand what the legacy systems could provide.
When data arrived in S/4HANA corrupted or incomplete, it wasn't a failure of one team. It was a failure of collaboration and shared ownership. Data quality is a business and organizational problem, not just a technical one. Own it across teams.
What Successful Data Migrations Actually Look Like
The parts of our transformation that succeeded had these characteristics:
- Coordination across teams - EY and client teams talked regularly, but so did we with SD teams, MM teams, SIT/UAT teams. Nothing was siloed.
What I'm Taking Forward
Enterprise transformation is about collaboration.
I learned more about transformation working alongside the client's extraction team to align on loaded data than I ever would have from SAP documentation. I learned more about adoption watching a team's reaction to an Enable Now video than from implementation timelines.
Enterprise transformation is hard. Especially when you're doing it across organizations. But it's also where real impact happens. Not through flashy new technology or perfect data migration, but through the careful, deliberate work of helping multiple organizations think differently about how they work together.
Have thoughts on this article? I'd love to hear from you.
Connect on LinkedIn