SAP S/4HANA Data Migration Success

blog.masterdataaficionado.com/sap-s-4hana-data-migration-success/

Recently comes this headline: SAP users struggling with data management for S/4HANA
migration.

And the metrics: “According to a survey of 116 SAP user organizations, 61 percent said
that data management challenges have slowed or will slow the automation of their
business processes. Meanwhile, two-thirds (66 percent) state that data management is a
challenge when moving from SAP ECC 6.0 to SAP S/4HANA, the study by the UK and
Ireland SAP User Group (UKISUG) found.”

Is it really surprising that two-thirds of folks seem surprised by the effort required to bring
data into a new system? Or that they struggle to manage data after the fact?

On reading this news, my first reaction was: There’s nothing new here! Implementing SAP
ERP has always been about the data. In particular, it’s all about the master data, because
SAP ERP is a master-data-driven system. Data migration has always been — and will
always be — the highest-risk workstream. If your SAP master data isn’t right and
governed, then woe is you!

But there’s definitely more going on with the move from SAP ECC 6.0 to SAP S/4HANA.
Much more.

For example:

1/12
 The shift to cloud, preconfigured content, and a fit-to-standard mindset all reduce
implementation time, but these also combine to significantly exacerbate data
migration risk. You have to perform data migration and data quality remediation
tasks in … much, much less time? Shortening the runway for data migration
increases risk exponentially.

Many companies have a low data maturity score, with little or no data governance in
place. Or worse, “data governance” is led by IT, which is an illusion of data
governance. Data migration tools and partners can’t compensate for what your
people and organization must quickly bring to the party.

Finally, having plenty of experience with SAP ERP 6.0 tends to inspire
overconfidence, especially when you’re told that SAP S/4HANA Migration Cockpit
provides “.. a comprehensive migration solution with no programming required by
the customer.”

That last bullet should prompt healthy skepticism. I’ll offer two small examples of why:

The adoption of SAP S/4HANA Business Partner to replace ERP Vendors and
Customers requires rethinking and often restructuring master data. It’s a business
problem more than a technical problem, usually requiring compromises. Because
SAP ECC 6.0 experience is insufficient for formulating the new master data design,
it’s typical to underestimate the complexity of this task.

When it comes to loading data, the much-touted Migrate Your Data – Migration
Cockpit replaces Legacy System Migration Workbench (LSMW). Again, your ECC
6.0 experience isn’t very informative; this is a new tool and a new skillset, which
might present a challenge all on its own. But the most common mistake is to focus
on this tool (it’s not a solution) rather than an end-to-end process and consistent
stakeholder experience. Data migration involves far more than the “Load” step, and
believing otherwise inevitably leads to missed expectations.

Excellence in Execution

The risks posed by data migration to SAP S/4HANA and subsequent data management
processes are real and widespread, as recent headlines attest.

What do the successful one-third know that confounds the majority? Mainly, principles
that apply to companies of all sizes!

For this topic, the cliché that “people, process, and technology” combine to produce
excellence in execution has the added benefit of being absolutely true. In my experience,
when data migration success happens, it’s as much about people and culture as it is
about tools and content.

2/12
There are success stories — principles, if you will, or at least common habits — that
stand against the many well-publicized tales of woe. You can observe these to minimize
risk and promote success. That’s today’s story.

People
Who are the resources you’re looking for? Can you spot them in the wild?

Can you identify the unicorns that you need?

At the onset, seek out a few unicorns. You’ll eventually settle for mere mortals, but it’s
important to know key roles, and the desirable characteristics of the folks who will fill
them.

For standard ERP implementations, master data responsibilities may be allocated

amongst various business process functional leads. But if your implementation is SAP
Retail or Fashion, then you’ll definitely need a dedicated SAP Retail Master Data lead,
because Master Data makes SAP Retail special.

In any case, the mission of the Master Data Lead is orchestrating master data, cross-
functionally, for the enterprise. Central orchestration is required because, for example,
SAP S/4HANA Business Partner as one master data represents Suppliers and
Customers across financial, purchasing, logistics, and sales business processes. Material
Master (Article Master) is likewise important cross-functionally. It’s dangerous to split
responsibility for a master data business object.

The dynamic duo: your Master Data Lead (blue) and a Master Data Expert (orange).

3/12
While project size and scope dictate head count in master data and data migration
workstreams, you should begin hunting early for key master data and migration resources
that are required for all SAP ERP implementation projects.

As a starting point, assume a conventional two-in-the-box pairing of your own Master

Data Lead and a Master Data Expert (e.g. consultant). The two-in-the-box approach pairs
functional knowledge of legacy and future state. Together, they uniquely create a bridge,
then a foundation of master data, for every business process. That’s not hyperbole, but
essential truth for taming the highest-risk workstream.

When scouting your organization for a unicorn Master Data Lead, you’re looking for signs
of experience, relationships, and especially an ability to blend into scenery.

This person knows — at least at a business object and systems level — how data flows in
the enterprise. All the better if that person participated in making it so. While the role is
typically staffed from the ranks of IT, the unicorn has solid relationships with business
counterparts, including those who are — or are likely to be — named as data owners.
Telltale signs of a trophy can be observed in meetings with both Business and Technology
folks in the room. Your unicorn is the person cheerfully moving the conversation forward
by deftly translating between business and technology stakeholders, who may be talking
past each other. There’s a distinct scent of “how may I serve you?” as this one moves and
interacts.

Every bit of that description is about people and culture. And every bit is far more
valuable than specific SAP knowledge.

Key SAP S/4HANA Data Management roles.

The same is essentially true for your Data Migration Lead, but with a more technical bent,
of course. This one knows your systems, data sources, and has hands-on experience
using your favorite tools for extracting and moving data (more on that later).

4/12
Experience teaches that a weaker Data Migration Lead can usually be sufficiently
compensated for by a strong Master Data Lead. But I’ve never observed the reverse in
the wild. Choose carefully.

Eventually, the broader data team is realized, and among best-run companies — or those
striving to be — this includes data governance. Introducing data governance warrants full-
length treatment, beyond the scope of this missive. If you’ve already staffed these
business roles (not IT roles) then, “bravo!” If not, then digital transformation either isn’t on
your radar or it’s past time to get started with crawl, walk, run.

Additional Reading:

Process

How and how early should key data folks work together? Have you arranged it properly,
and can you spot trouble?

So far I’ve mainly described your dynamic duo — your Master Data Lead and an SAP
expert counterpart — who are functionally responsible for to-be master data definition and
master data processes. It’s no accident that this pairing uniquely provides a once-in-a-
lifetime opportunity for knowledge transfer as a side-effect of workaday activities.

Now let’s have a look at how you expect these folks work, together, and with data
migration leads, to produce timely success.

I’ll begin by describing the setup for calamity, so that you’ll smartly avoid it. Just imagine
an arrangement that has functional leads writing data migration functional specification
documents as an output of project Explore phase, and then tossing them over a wall to
technical resources for execution during project Realize phase. As if these activities
naturally occur sequentially to produce an output, or can be handed off from one team silo
to the next on a timeline.

We’ve all seen project plans laid out on this basis. In fact, it’s the norm, because it’s the
timing and sequence prescribed by methodology. But your success depends on
deliberately coloring outside of those lines!

Here’s a guiding principle: Plan for and organize an intensely-collaborative, iterative

process that intentionally minimizes complexity by playing to the strengths of each role.
Oh, and plan to start early!

5/12
 Competencies and collaboration result in successful data migration.

Start Early

The SAP Activate Methodology for Transition to SAP S/4HANA prescribes the Data
Migration Design steps that should occur during Explore phase.

Conduct a Data Migration Assessment

Run a data audit in the legacy source systems
Finalize the data migration approach and strategy document
Define specifications for data migration
Set up and configure date migration tools
Perform Data Cleansing Activities

You should diligently work that list. But for some objects, do more, and sooner.

Practical Examples Mitigate or Confirm Risks

As data migration business objects are identified during Data Migration Assessment, your
Master Data Expert and Data Migration Expert should flag those that present risks or
unknowns for loading data into SAP S/4HANA. For some or all of these, create simple
prototypes.

In a sandbox or development data migration client, load a few rows of manually

created sample data.
This can be accomplished far in advance of known requirements.
Success demonstrates prototype load functionality for a business object.
Simple result informally validated by functional resource who will own the
conversion functional specification document for the business object.

6/12
This exercise may seem simplistic, but the value of early-insight can’t be overstated
whenever there’s any unfamiliarity with some aspect of a business object, or with the tool
required for loading data for a business object.

Early Engagement

One all-to-common pitfall involves the rather important Data Migration Approach and
Strategy Document, which is carefully crafted and then read by … almost nobody. Then
it’s set aside. Too often this document is a bit long on the technical and a bit short on
strategy, or practical application.

Consider the essential data migration process steps:

Analysis
Extract
Transform
Validate
Load
Reconcile

From the start, it’s important that everyone who participates in data migration — from
business data owners on down — understand the essential process steps and their role.

Perhaps one level deeper, I rarely see data Validation and Reconciliation steps treated
sufficiently and effectively communicated. It’s a gap that’s both easy to spot and
guaranteed to cause consternation later on.

Business data owners own the data. They’ll be asked to “accept” the results of data
migration. Engage them early on, and coach them on what the data migration “Validate”
and “Reconcile” steps looks like in practice, and especially their role. What the process
“looks like in practice” isn’t a figure of speech. Show them an example of reporting or a
transaction code that they — or their representative — will use as the basis for
“accepting” data migration results.

This exercise will surprise you as questions are asked and expectations are clarified.
Early engagement and agreement with data owners — those who will sign off on data
migration results — is the way to avoid guaranteed upset and correction-under-pressure
at a later date.

Intensely-collaborative, iterative process that intentionally minimizes complexity.

As already suggested by the early collaboration of your Master Data Expert and Data
Migration Expert, silos and handoffs are verboten by design. When detected, relentlessly
tear down those walls, or suffer the consequences.

The structure of collaboration may change depending on choice of tools, but required
competencies and collaboration remain constant.

7/12
 Master Data Master Data Migration Migration
Knowledge / Task Lead Expert Lead Expert

Legacy Data Knowledge XX X

Formulate To-Be Master Data X XX

Design

Formulate To-Be Master Data X XX

Processes

Data Load Method, Define X XX

Structures

Define Simplified Target for X XX

Data Staging

Legacy Systems and Data X XX

Tools Knowledge

Fill Simplified Target XX

Data Migration Step: Validate X X X XX

Data Migration Step: Load X XX

Data Migration Step: X X X XX

Reconcile

In practice, the people in these roles must visibly operate as a tightly-knit team.

The concept of “Minimizes complexity by playing to the strengths of each role” comes to
life by “defining a simplified target for data staging.” What does this mean and how do you
recognize it in action?

The master data structures in SAP S/4HANA are complex and likely unfamiliar to your
Master Data and Migration leads (at least initially). For example, SAP Business Partner
and Material Master are comprised of dozens of tables and thousands of fields. Most of
these tables and fields will be irrelevant for your particular SAP S/4HANA implementation.
Considering them in entirety would be a distracting waste of time and would only add
complexity and confusion.

For this reason, your Data Migration Expert and Master Data Expert closely collaborate to
present relevant (simplified) structures in a data staging area. Mapping from legacy data
to SAP S/4HANA becomes simplified as mapping from legacy data to relevant (simplified)
structures in a data staging area.

The people who understand legacy data are more sharply focused on the objective and
shielded from unnecessary complexity. They focus on moving data from legacy systems
to a data staging area. The people who understand how to load data into SAP S/4HANA
are focused on loading data from the data staging area into SAP S/4HANA.

8/12
This is a highly-productive division of labor, by competence, with end-to-end speed and
accuracy — in particular, iteration speed and accuracy — augmented by constant
collaboration. If this level of collaboration and speed isn’t readily observable, then you’ve
probably got silos to tear down with high priority.

Process (Progress)
Are you asking the right questions? How certain are you that data migration is on track?

Here’s a guiding principle: Understand — and embrace — that data migration is an

iterative process..

The universal question that I hear asked is: “When will the data migration deliverables be
done?”

Project managers diligently — almost comically, but tragically — struggle to answer this
question on nearly every project. For data migration and data management workstreams,
toss out the Gannt charts! They’re worse than misleading because they impossibly
pretend to inform. To the point, it’s pointless to talk about “done.” It’s the wrong question.

Just say no when you see this presented for data migration.

The data migration workstream must accommodate change over time. That means — by
design — an expectation of and readiness to accommodate significant change in the
beginning, and carefully-considered (prudent) change later on.

It then follows that data migration doesn’t fit neatly into a project plan or make for a pretty
Gannt chart. And hammering data migration deliverables into typical “check the box”
reporting with an end date doesn’t provide critically-needed transparency to project
stakeholders.

9/12
The insight-producing question is: “Are we on track for success with data migration
deliverables?”

To produce an informative answer, insist on milestone-based status reporting, for each

data object. That provides essential Data Migration Transparency. It’s not one check-box
or a timeline, but an at-a-glance, experience-based indication of progression that builds
confidence and identifies risks as early as possible.

At the highest level, at least this level of detail is required by business object:

Object Definition / Prototype

Unit Test
Functional Test
Full Load (or … almost)

The data-migration mantra of “Load Early, Load Often” is shorthand for two important
insights. First, it affirms the notion that data migration is an iterative process. Second, it
declares that the only reliable indicators of progress are demonstrated and repeatable
results. Show me the data, in SAP S/4HANA!

Additional Reading:

SAP Data Migration Transparency

Tools
Are you focused on an end-to-end process and consistent stakeholder experience?

Or have you been told a temptingly simplistic data migration story that’s mainly — or only
about — “loading” data? If so, then you’ll wildly underestimate the effort of data
migration. It happens every day. Getting it right begins with understanding the touchpoints
of repeatable process.

Again, because it’s worth repeating, the essential data migration process steps are:

Analysis
Extract
Transform
Validate
Load
Reconcile

Any data migration “solution” must address all six data migration steps to warrant the
name. If you’re responsible for the outcome then you dare not do less.

10/12
Covering the scope of data migration steps requires looking beyond Migrate Your Data –
Migration Cockpit — looking beyond the Load step — for all but the simplest projects.
What’s more, even in SAP S/4HANA 2020, consider that no single tool will enable the
Load step for all data migration objects!

For example, LSMW (more precisely, IDocs or BAPI) remains essential for SAP Retail.
For confirmation of necessity, see SAP Note 2538170 – Migration of Retail Objects to
SAP S/4HANA on-premise. Even outside of SAP Retail, your S/4HANA data migration
architecture not only has to cover the six steps, but has to enable multiple options for the
Load step, with a decision to be taken by data migration object.

Load step options include these tools, and you will need more than one:

SAP Data Services

Migrate Your Data – Migration Cockpit
Legacy System Migration Workbench (LSMW)
Extended Computer Aided Test Tool (eCATT)
Custom Development Object / Load Program

Finally, the scope of every enterprise-grade data migration project includes writing some
code, no matter what the brochure says. Migrate Your Data – Migration Cockpit is no
assurance of avoiding that reality.

SAP S/4HANA Data Migration Architecture

You expect the infrastructure and process conveyed by the above image, because it’s
preferable to have a single flow (or fewest) that accommodates all business objects. That
desire encompasses functional as well as technical steps, and should work similarly
regardless of the technical method chosen for the Load step.

That’s why I believe SAP Data Services (or an equivalent world-class tool) is essential for
all but the simplest data migration projects. It’s uniquely capable to cover all six data
migration steps, and any of the data migration load options fits into the process.

11/12
With that said, here’s a guiding principle: Right-size your tools and resources.

SAP Data Services requires specialized resources and dedicated infrastructure. If that fits
— or can be made to fit — your landscape and staff, then that’s sweet. It’s good because
we know that it will produce good results. But if you have other world-class data tools,
and experienced staff to use the tools, those can work as well.

For medium-size companies with modest data quality concerns, experience teaches that
you could get by with much less, with eyes wide open to risks.

I’ve participated in several ERP implementations where the data staging environment
consisted of a database server and a couple database experts (extract / transform). We
got along just fine, because we covered the six essential data migration process steps,
and acted out many of the habits described above.

Experience substantiates the claim that when data migration success happens, it’s as
much about people and culture as it is about tools and content.

Master Data Governance

Here’s a guiding principle: When it comes to data governance, people and process aren’t
only more important than tools, but success demands that they arrive before tools.

With that said, your migration from ECC 6.0 to S/4HANA represents a rare data
management opportunity to restore order. There are tools to support people and process
to this end, and it’s noteworthy that they’re useful for upfront data preparation, not only for
governance afterward.

If SAP Master Data Governance (MDG) is already existing in — or planned for — your
business process landscape, then it too requires coordination of people, process, and
technology (e.g. customizing, data migration targets). MDG sequencing and capabilities
can play a role in supporting data migration with a mix of master data consolidation,
central governance, and data quality management.

Data governance — considered holistically, as people, process, and tools — should be an

integral part your journey to SAP S/4HANA.

Altogether, this is what transforms your data from a showstopper into a business
accelerator. And that’s the essence of what folks recognize as true digital transformation.

Additional Reading:

Notes and Asides

In this document, I use the term SAP Retail as shorthand to mean both SAP
S/4HANA Retail for Merchandise Management and SAP S/4HANA for Fashion and
Vertical Business.

12/12