WHITE PAPER

Implementing or Upgrading SAP? Dont Forget the Data

Addressing the Challenges and Risks of Data Migration

This document contains Confidential, Proprietary and Trade Secret Information (Confidential Information) of
Informatica Corporation and may not be copied, distributed, duplicated, or otherwise reproduced in any manner
without the prior written consent of Informatica.
While every attempt has been made to ensure that the information in this document is accurate and complete,
some typographical errors or technical inaccuracies may exist. Informatica does not accept responsibility for any
kind of loss resulting from the use of information contained in this document. The information contained in this
document is subject to change without notice.
The incorporation of the product attributes discussed in these materials into any release or upgrade of any
Informatica software productas well as the timing of any such release or upgradeis at the sole discretion of
Informatica.
Protected by one or more of the following U.S. Patents: 6,032,158; 5,794,246; 6,014,670; 6,339,775;
6,044,374; 6,208,990; 6,208,990; 6,850,947; 6,895,471; or by the following pending U.S. Patents:
09/644,280; 10/966,046; 10/727,700.
This edition published January 2006

White Paper

Table of Contents

Executive Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2
Data Migration Challenges in SAP Implementations . . . . . . . . . . . . . . . . . .4
Identifying and Analyzing Source Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4
Accessing Source Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5
Addressing Data Quality of Legacy Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6
Preparing and Loading Data into SAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7
Supporting the Data Migration Lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9

Using a Single, Unified Enterprise Data Integration Platform to

Address SAP Data Migration Challenges . . . . . . . . . . . . . . . . . . . . . . . . .10
Data Profiling Capabilities for Identifying and Analyzing Source Data . . . . . . . . . . . . . .10
Universal Data Access Capabilities for Accessing Source Data . . . . . . . . . . . . . . . . . . .12
Built-In Data Transformation and Correction Capabilities to Address
Data Quality in Legacy Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14
Certified Connectivity SAP to Prepare and Load Data into SAP . . . . . . . . . . . . . . . . . . .14
Single, Unified, Metadata-Based Data Integration Platform to Support
the Data Migration Lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17

Informatica and SAP: Working Together for Joint Customer Success . . . .18
Powered By NetWeaver Certification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18
Master Relationship Agreement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19
Track Record of Joint Customer Success . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19

Conclusion and Next Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20

Implementing or Upgrading SAP

Executive Summary
Forrester Research recently conducted a survey showing investment in enterprise resource
applications (ERP) and enterprise applications in general remains the top IT spending priority for
2005. A major driver for many large companies is regulatory compliance initiatives, such as
Sarbanes-Oxley for public companies, Basel II in the banking industry, and FDA Part 11 for
biotechnology and pharmaceutical organizations.1
Other business drivers behind the decision to purchase and implement ERP applications like SAP
include:
Retirement of legacy systems to support new regulatory requirements such as Sarbanes-Oxley,
Basel II, and the Patriot Act
Standardization of enterprise business applications to support and unify business processes
that are changing and evolving
Need for providing accountability through operational transparency
Upgrade or consolidation of existing SAP systems due to new functionality or a company
merger or acquisition
Creation of a single view of the customer to cut order costs and increase customer satisfaction
ERP applications like SAP have an impact on business processes; therefore, the decision to
purchase and implement them is approached with considerable due diligence. While the vendor
selection and implementation decision gets much of the spotlight, there are critical project
phases upon which the success of an SAP implementation hinges. These project phases are not
always considered with the same degree of detail as the purchase and implementation decision.
Examples of such project phases include:
Business process reengineering. Software that touches and drives processes across the
enterprise cannot simply be installed and turned on. Current as is processes must be
understood and methodically mapped to the new SAP system and its to be capabilities.
Invariably, gaps are uncovered during business process reengineering which must be
considered and planned for.
Change management and user adoption. SAP implementations cannot rely on an if we build
it, they will come approach. The success of a new business application is ultimately
measured by its adoption by business users. Careful consideration must be given to executive
sponsorship and to business as well as technical user training.

Hamerman, Paul and R Ray Wang. ERP ApplicationsThe Technology And Industry Battle Heats Up.
Forrester Market Overview, June 9, 2005

White Paper

Data Migration Poses Unique Challenges

While business processes evolve and are enhanced during these aforementioned project phases,
no data is migrated directly from one system to another during these phases. Data migration is
different.
Data migration is the only phase during which data is actually moved from legacy applications to
SAP. Effective data migration directly affects business user adoption rates. Data migration is
therefore a critical component of an SAP implementation.

Mission-Critical Enterprise Applications Require a Mission-Critical

Approach to Data Migration
While data migration is essential to the success of an SAP implementation, its role in the project
often overlooked and underestimated. The common assumption is that tools exist to extract and
move the data into SAP, or that data migration is something a consulting partner will handle.
Often project teams tasked with data migration focus solely on the timely conversion and
movement of data between systems. But data migration is not just about moving the data into
SAP; its about making the data work once within SAP. This means that the data in the SAP
application must be accurate and trustworthy for business users to readily transition from their
legacy applications to adopt SAP applications.

Data migration is about more than moving

data into SAP; its about making data work
once within SAP.

Research has shown that software implementations are put at risk when data migration is not
thoroughly considered and planned. According to recent research, more than 80 percent of
software implementation projects fail or overrun their budgets and schedules. Of the projects
that are overrun, half exceed timescales by 75 percent and two-thirds exceed the overall project
budgets. A major reason why these failure rates are so high is because data migration is
considered a minor, one-time event during the overall implementation.
The successful implementation of mission-critical SAP enterprise applications requires a missioncritical approach to data migration.
This white paper examines five common data migration challenges associated with SAP
implementations. It discusses the value of using a single, unified enterprise data integration
platform to address these challenges.

Implementing or Upgrading SAP

Data Migration Challenges in SAP Implementations

This section examines the challenges of data migration in the context of an SAP implementation.
Five common challenges are:
1. Identifying and analyzing source data
2. Accessing source data
3. Addressing data quality in legacy applications
4. Preparing and loading data into SAP
5. Supporting the data migration lifecycle

Identifying and Analyzing Source Data

Most teams tasked with migrating data into SAP to have experience with the legacy systems. But
these teams are often new to SAP and the requirements corresponding to migrating data into
SAP. Data migration project teams often may not give sufficient attention to the identification
and analysis of the source data to be required by SAP.
Data migration project teams need to consider and answer fundamental questions about their
enterprise data. These questions include:
Does the data exist?
Where does the data exist?
What kinds of business rules or context are associated with the data?
Business logic can be embedded in the data itself. For example, consider the following order
number from a legacy application: POUNE55289. Without proper context, it is impossible to tell
whether this number is a sales order, purchase order, or purchase requisition. It is impossible to
know which system generated the order, or if it is an active or historic order. Such insight can
only be achieved by identifying and analyzing the context of the data. As shown in Figure 1,
valuable details that are critical to data migration are exposed when the context of the data is
analyzed.

Figure 1: True Context of Data Revealed Only with Proper Analysis of Data

White Paper

Common Misconceptions About Legacy Data

It is common for teams, especially those that are new to SAP and data migration projects in
general, to harbor misconceptions about the source data in the legacy applications. These
misconceptions include:
Acquiring legacy data is easy. What about data spread across mainframes, proprietary legacy
applications, other packaged applications? What about data residing with a business partner
or remote data center across the firewall?
Existing data will fit the new system. How will XML/hierarchical data structures or nonrelational database (NRDB) data formats be reconciled in SAP?
Existing data is of good quality. Without proper data analysis, how can the data migration
team be sure?
Existing data and business processes are understood. Does the SAP project team include the
business and technical experts who understand the legacy data and business rules? Are these
experts even still with the company?
Good, or even adequate, documentation exists. Is the documentation complete? Is it reliable?
Does documentation even exist?
The reality is that source data to be migrated into SAP will typically be spread across numerous
existing applications, databases, spreadsheets, or documents. The data may even be orphaned
or not stored anywhere in the company although this data is still essential to business
operations. Sometimes a critical piece of data exists not in any database, application, or system
but in someones head or notebook. Sourcing legacy data to be migrated into SAP is a complex
process that requires careful consideration.

Accessing Source Data

According to a recent survey of more than 350 firms, the typical organization relies on more than
50 core business applications, and companies with more than $1 billion annual revenue have as
many as 500 systems. Regardless of whether there are five, 50, or 500 source systems to
migrate, the question needs to be answered as to how this will be accomplished.
SAP project teams usually expect that another team will deliver data from required legacy
systems. However, simple extraction and upload often proves to be unrealistic due to the volume
of source systems and the availability of legacy application resources.

Volume of Source Systems

Moving data into SAP is rarely a simplistic 1:1 mapping between the legacy application and the
new SAP solution. Legacy systems migration requires multiple business applications to be
migrated into SAP.
Lets look at an example. Company A runs its financials across five separate financial
applicationsone per division. Company A is acquired by Company B. All of Company As
financial departments are to be consolidated into Company Bs standard financial application,
which is mySAP ERP Financials. Estimating conservatively, each of Company As five divisions
have 10 financial data sources (e.g., tables, spreadsheets, files, etc.) must be handled to
migrate Company As chart of accounts into Company Bs mySAP ERP Financials solution.

Implementing or Upgrading SAP

This means the migration team is faced with the reality of data extraction across 50 sources.
Given the volume of source systems, the Migrating Chart of Accounts line item in the project
plan does not accurately reflect the amount of data migration work required. It is not a single
data migration unit of work. Moreover, the basic count of sourcing requirements does not take
into consideration the joining and reconciling of data between at the source application.
The diversity and volume of source systems can complicate and jeopardize the overall success of
the migration.

Dependency and Availability of Legacy Application Resources

The type of legacy applications and the corresponding skill sets and resources required to extract
the data are often overlooked during high-level planning of the SAP implementation.
Legacy applications often run in disparate systems on multiple platforms such as:
Mainframe
Mid-range (AS/400)
Home grown client/server .Net applications
Relational databases in conjunction with Excel spreadsheets
Not only do the number of sources required for extraction need to be identified, but how the
data will be extracted and by whom also needs to be addressed. The data migration team must
have resources to extract data from the legacy applications, and these resources need to be
reliable and trustworthy in providing high quality and timely data extracts.
Tension between the data migration and legacy application teams is common because their
goals are often at odds with one another. After all, once the SAP solution goes live, the
applications that the legacy teams have built and have supported for years may be deemed
obsolete and eventually shut off.
Aside from the politics associated with the access and ownership of legacy data, the legacy
resources with the experience and skill sets essential to providing data extracts are likely busy
and in-demand resources within their organizations. Between maintaining and enhancing the
legacy applications, they may not have the bandwidth to dedicate the proper attention to the
SAP data migration effort.

Addressing Data Quality of Legacy Applications

The quality of the data across heterogeneous legacy applications is directly proportional to the
effort required to convert, or transform, the data into the format required for entry into SAP.
Data quality can be compromised as a result of how the data has been:
Entered. Fields are left blank or filled in incorrectly. Users may enter cross-sell response codes
in a purchase date field because there is no other place for this particular type of data.
Customers may mistype their names or addresses when placing an order using a Web site.
Maintained. Application maintenance, such as enhancements or a version upgrades, may
have unpredictable consequences. For example, after an upgrade, a field that was once
optional now is mandatory, invalidating previously valid data.
Processed. When incorrect data enters the application, it may be propagated across multiple
systems. For example, a system of record for material master information feeds data to
downstream applications, such as supply chain management or purchasing applications. Data
quality issues are replicated and may multiply as data is fed downstream to constituent
applications.

White Paper

Stored. Storing data across multiple business applications often leads to redundant and
inconsistent data. For example, various attributes of customer master entity information are
frequently stored in multiple business applications, such as customer relationship
management, sales force automation, and sales and marketing applications. Customer
information, such as names, titles, addresses, and purchase history, may be stored in different
formats or duplicated across different systems, preventing a single view of the customer.
Data migration teams need to understand and accept that there may be dirty data. To address
data quality issues when migrating legacy applications into SAP, data migration teams should
consider the datas:
Existence. Does the required data for the SAP solution exist? Does it exist within the
enterprise, or possibly in a partners or outsourcing vendors environment? If it doesnt exist,
what is the business rule to populate the required information in SAP?
Validity. Do data values fall within an acceptable range or domain? For example, if the legacy
applications have 73 U.S. state codes instead of 50, is this valid?
Consistency. Is the same data stored in multiple applications in a common format? For
example, is John Doe from Company XYZ the same as Mr. Jon Doe from the same
company?
Timeliness. Is the data that is required to support the SAP business processes available at the
optimal time?
Accuracy. Does the data correctly describe the properties of the object it is meant to model?
Relevance. Does the data meet and support the SAP business processes?
Data migration project teams commonly leverage custom code to support the data conversion
process required to address data quality issues. Custom code can initially offer some degree of
flexibility. However, as the number and complexity of integration touch points increase, custom
coding limitations in scale and maintenance are exposed.

Preparing and Loading Data into SAP

Beyond analyzing, sourcing, and addressing data quality issues in the legacy data, actually
understanding and selecting the appropriate techniques to prepare and load data into SAP can
be challenging. One of the top reasons organizations choose to implement SAP is that it helps to
centralize business processes and data within a consistent application. With the mature and
growing list of mySAP business applications, SAP boasts more than 30,000 interrelated tables
driving business across more than 25 industry verticals.
While the SAP application platform provides mature interfaces to upload data into SAP, these
application program interfaces (APIs) typically require the data in a specific format to be properly
validated and accepted by the SAP application layer. Data typically is not loaded directly into the
database layer of any SAP system, but instead must pass through strict validation checks based
on SAP business rules within the application layer.
Figure 2 presents the various interface and loading techniques available for SAP data migration.
This table serves as a high-level glossary data migration terms and options.

Implementing or Upgrading SAP

SAP Interface
Technique

Read

Write

Description
SAP certified interface tailored for SAP data migration

Data Migration
Interface
(DMI)

Includes SAP delivered programs for the most common

master and transactional data needed in any SAP data
migration project
Programs require data in a valid and well-formed flat file
Programs support a combination of batch and direct
input of data into SAP
Common method of moving data into SAP

Batch Input
Processing

Programmatically automates and mimics processing

data in the same fields and screens an online user
would step through in a given SAP transaction
SAP supported technique of writing data directly to the
database layer of an SAP system

Direct Input
Processing

Unlike Batch Input, does not walk through the entire

SAP transaction logic
Contains SAP application validation checks
Should be considered if throughput from Batch Input is
not sufficient
Standard SAP data structures for common business
entities, such as material master or purchase order

Intermediate
Document
(IDOC)

Business
Application
Programming
Interface (BAPI)

Supports integration of both transactional and master

data
Although based on asynchronous data integration, IDOC,
via SAPs Application Link Enabling (ALE) protocol, can
support near real time data movement as well as larger
batches of data

Library of standard SAP interfaces that are Remote

Function Call (RFC) enabled
Able to move data into and out of SAP
Useful in data migration scenarios to do pre-validation,
or look-ups, of legacy data against the SAP application

Computer Aided
Testing Tool
(CATT)
Legacy System
Migration
Workbench
(LSMW)

Tool that supports the testing of an SAP business

process
While designed for recording and automating QA test
scenarios, it can be used to load data into an SAP
production environment
SAP tool that helps migration teams orchestrate data
migration processes
Able to schedule and run techniques listed above, such
as BAPI, IDOC, or DMI processes to load data into SAP
Supports both Batch Input as well as Direct Input
techniques

Figure 2: Interface Techniques Available for SAP Data Migration

White Paper

In most cases, if just a portion of the data being loaded into SAP does not pass the SAP
application validation, then SAP will reject the entire record. Examples of data validation
performed at the SAP application layer include:
Syntactical. Is the field length and data type of the material master number valid?
Semantic. What is the context of the data? Does this number identify a customer or vendor?
Structural. Does the purchase order header and line item meet proper parent/child
relationships or cardinality rules?
Dependency. Is this bill of material valid even if one of the referenced material master records
has not yet been created in SAP?

Supporting the Data Migration Lifecycle

Data migration may be approached as a discrete activity that happens only once during an SAP
implementation. However, data migration requirements commonly surface after the initial
migration is complete. Subsequent data migration may be required beyond the initial SAP
implementation due to such factors as:
Data synchronization. SAP implementation teams do not always simply turn off their legacy
systems immediately after data has been migrated to SAP. If the decision is made to maintain
both legacy applications and SAP in parallel, data will need to flow in a bidirectional manner
to synchronize the systems.
Implementation approach. While a big bang or single cutover approach to an SAP
implementation is not unheard of, it is considered aggressive. Phased implementations can
offer benefits including a more manageable and controlled scope to cutover to new business
process and applications. Examples of how or when data migrations are implemented in a
phased approach include implementations by:
- Region or country
- Legacy system
- mySAP solutions (e.g., FI, SD, MM, etc.)
Treating data migration as a one-time event can be shortsighted and place a burden on
subsequent migration phases. Without properly considering the full lifecycle of the SAP
implementation, organizations risk duplicating efforts already invested in initial migration phase.

Audits and Data Lineage

The ability to audit and track the end-to-end migration logic, especially across multiple legacy
systems, is often overlooked in data migration projects. Whether driven by the need to complete
the user acceptance testing phase of a data migration project, or by the need to support audit
and compliance requirements, the ability to prove the data was migrated properly can be just as
critical as moving the data itself.
Conducting audits and establishing data lineage is particularly challenging when data migration
teams use traditional custom coding, which may require tens or even hundreds of individual
programs. Whether required to extract, prepare, or load data into SAP, each program contains
logic to validate and support business rules about the data. Creating and maintaining these
programs is challenging. Auditing and tracking the business logic embedded within and across
the programs is even more challenging and is often not fully considered by data migration
teams.

Implementing or Upgrading SAP

Data auditing has an enormous impact on data migration projects. Consider this example: A
developer is responsible for converting material master data. Despite assurance that a
conversion program reconciled and consolidated legacy material master data, an audit report
shows that the data loaded into SAP still contains duplicate material master data. Identifying
problems caused by the legacy extraction or the SAP conversion program requires cumbersome
and time-consuming code review sessions and exhaustive testing.
Often migration teams try to address auditing requirements by creating custom reports or spotchecking the data being migrated into SAP. These approaches are incomplete and do not identify
the root cause of any issues with the data conversion logic.

Using a Single, Unified Enterprise Data Integration

Platform to Address SAP Data Migration Challenges
SAP NetWeaver, the application platform for
all SAP application modules, includes data
integration functionality with its established
ABAP/Basis layer, interfaces such as SAP XI
(Exchange Infrastructure) and Enterprise
Services Architecture. PowerCenter
complements NetWeavers capabilities with
the ability to migrate non-SAP data.
It is important to note that data migration
teams do not have to choose between
NetWeaver and PowerCenterits not an
either/or proposition. NetWeaver and
PowerCenters complementary capabilities
help organizations significantly reduce risks
and improve productivity during the data
migration effort in any SAP implementation.

This section examines the role of a single, unified enterprise data integration platform in
addressing the challenges associated with migrating data into SAP.
The solution to address the challenges of migrating all enterprise data into an SAP solution is
Informatica PowerCenter. PowerCenter is a single, unified enterprise data integration platform
that enables companies and government organizations of all sizes to access, discover, and
integrate data from virtually any business system, in any format, and deliver that data throughout
the enterprise at any speed.
PowerCenter provides powerful capabilities to help overcome data migration challenges
associated with SAP implementations. These capabilities include:
Data profiling capabilities for identifying and analyzing source data
Universal data access capabilities for accessing source data
Built-in transformation and correction capabilities for addressing the quality of data in legacy
applications
Certified connectivity to SAP to prepare and load data into SAP
Single, unified data integration platform to support the data migration lifecycle

Data Profiling Capabilities for Identifying and Analyzing Source Data

While the objective of moving data from legacy systems to SAP seems straightforward,
complications arise when legacy migration translates to n number of distinct business
applications running on different platforms and data stores, and the context and relationship of
the data may not meet or match SAP requirements.
Data profiling is the analysis of data to understand its content, structure, quality, and
dependencies. During SAP implementations, data migration teams typically try to profile legacy
data manually. Manual data profiling ranges from spot inspections of actual legacy applications
or sample data extracts, to analysis via custom-coded reports or elaborate and intertwined
spreadsheets. These data profiling methods typically sample data in a few key fields to get a
sense of what the data is like in these columns, but the results are often inaccurate and
incomplete.
An inadequate toolset and manual approach to profiling often leads to a data migration project
which underestimates the scope, schedule, and resources required to properly analysis source
data systems. Figure 3 shows how a much more even distribution of project resources over the
key project phases (e.g., analysis, build, and test) can promote savings. Relying on the build or
development phase to identify and fix data issues can increase the cost by ten times.

10

White Paper

Typical Project Effort

Analysis
10%

Test
30%

Build
60%

Ideal Project Effort

Analysis

Test
30%

Analysis
40%

Build
Test

Build
30%

Figure 3: Proactive Analysis of Source Data Saves Both Time and Money

PowerCenters data profiling capabilities provide comprehensive, accurate information about the
content, quality, and structure of data in virtually any operational system. Organizations can
automatically assess the initial and ongoing quality of data regardless of its location or type.
With its comprehensive data profiling capabilities, PowerCenter:
Reduces data quality assessment time with easy-to-use wizards and pre-built metric-driven
reports that comprise a single interface for the entire profiling process
Addresses ongoing data quality in legacy applications with Web-based dashboards and
reports that illustrate changes in data content, quality, structure, and values over time

PowerCenters data profiling reports help

migration teams determine if the legacy data
has quality issues and how to properly
address them.

Ensures end user data confidence by automatically and accurately profiling any data
accessible to PowerCentervirtually any and all enterprise data formats
Figure 4 shows an example of a PowerCenter data profiling report. The report shows how
PowerCenter automatically infers the primary and foreign key relationships across three tables in
a legacy application.

Figure 4: PowerCenter Profiling Report Inferring Primary Key and Foreign Key Relationships between
Multiple Legacy Application Data Sources

Implementing or Upgrading SAP

11

PowerCenters data profiling capabilities enable migration teams to do much more thorough
analysis than manual profiling of the legacy systems. The platform provides the tools to
automatically scan all records across all columns and tables in a source system and dynamically
generate reports that make it easy to understand the true state of the data. These reports help
the migration teams help migration teams determine if the legacy data has quality issues and
how to properly address them.

Universal Data Access Capabilities for Accessing Source Data

Analysis of legacy data is essential for creating accurate data migration mapping specifications
with relevant data conversion requirements. However, a complex, inefficient migration process
still lies ahead if the data migration team relies exclusively on manually extracting data from
each legacy data source. According to a report from The Data Warehousing Institute (TDWI), on
average, organizations extract data from at least 12 distinct data sources. This average will
inexorably increase over time as organizations expand their enterprise application landscape to
support more subject areas and groups in the organization2.
Furthermore, while most IT organizations have experience extracting data from relational
databases, flat files, and legacy systems, a significant percentage of data required for an SAP
data migration project comes from formats not traditionally considered to be a part of a legacy
business application.
While many of todays modern business applications are based on a relational database, many
mature and established applications are still maintained on mainframe platforms. A significant
percentage of data for an SAP migration will need to be extracted from these systems, but the
fact that much of the mainframe data is not stored in a relational format leaves the migration
teams relying exclusively on mainframe developers to extract and replicate data.
Based on a 2003 TDWI survey of the types of data sources that ETL programs process, enterprise
data may reside in XML files, Web-based data sources, payloads from message queues, as well
as unstructured data formats such as Microsoft Excel and Adobe .pdf files3, as shown in
Figure 5. The ability to readily access all enterprise datastructured, unstructured, and semistructuredis vital to successful data migration.

Data Sources
Relational databases

89%

Flat files

81%

Mainframe/legacy systems

65%

Packaged application

39%

Replication or change data capture utilities

15%

EAI/messaging software

12%

Web

15%

XML

15%

Other

4%

20

40

60

80

100

Figure 5: Enterprise Data Resides in a Variety of Sources and Formats

2
3

12

Eckerson, Wayne and Colin White. Evaluating ETL and Data Integration Platforms. TDWI Report Series, 2003
Ibid

White Paper

PowerCenter provides universal data access, allowing the data migration team to source virtually
any and all enterprise data formats, including:
Mainframe data
Structured data
Unstructured data (e.g., Microsoft Word documents and Excel spreadsheets, email, binary
files, .pdf files, etc.)
Semi-structured data (e.g., industry-specific formats such as HL7, ACORD, FIXML, SWIFT, etc.)
Relational data (e.g., DB2, Oracle, Microsoft SQL Server, etc.)
ERP (e.g., SAP, PeopleSoft, Siebel, etc.) and file data
Message queues (e.g., Tibco, IBM MQ Series, JMS, MS MQ, etc.)
Figure 6 shows the breadth of PowerCenters data access capabilities.
Enterprise
Software Sources

Real-Time Data Sources

TIBCO IBM WebSphere MQ
JMS SAP MSMQ WEBM
Web Services

Mainframe AS/400 JDE

PeopleSoft Siebel SAP
SAS Essbase Lotus Notes

Unstructured Data
PDF Word Excel
Vertical Standards
(e.g., HL7, SWIFT, ACORD)
Print Stream BLOBs
Any proprietary data
format/standard

Informatica
PowerCenter

Sources of data for SAP implementations

tend to be dynamic. Extracting data from a
relational database-based legacy application
today does not preclude SAP data migration
teams from having to meet future sourcing
requirements, such as mainframe or midrange applications.

Across the Firewall/WAN

Open and Relational

Data Sources
Oracle IBM Microsoft
Sybase Informatix Teradata
Flat Files XML Web Logs

Remote Data Access

Remote or Outsourced
Business Applications

Figure 6: PowerCenter Provides Universal Data Access

With PowerCenter, SAP data migration teams can source directly from a mainframe application
as if it were a relational database. PowerCenters data access capabilities offer SAP migration
teams the flexibility to source these softer forms of data which traditionally would be left up to
manually interpretation and processingor worse, left unaccounted for in the migration process.
The flexibility to access all types of enterprise data in a single data integration platform offers
significant advantages over hand-coded data migration approaches, including:
Increased productivity. With the ability to centralize data access and management,
PowerCenter frees data migration teams from having to maintain and be dependent on a
cumbersome, time-consuming process where programs are developed to extract and stage
data for each source of legacy data.
Reduced risk. Sources of data for SAP implementations tend to be dynamic. Extracting data
from a client/server-based legacy application today does not insulate the team from future
requirementsfor example, having to migrate over mainframe and mid-range applications from
applications resulting from a corporate merger or acquisition. PowerCenter reduces the risk of
both current and future data migration efforts by providing access to a broad range of
enterprise data formats.

Implementing or Upgrading SAP

13

Built-In Data Transformation and Correction Capabilities to Address

Data Quality in Legacy Applications
Despite the diverse types of business entities being migrated (e.g., master or transactional,
financial, or manufacturing-related), there are common requirements for converting the data from
the context of legacy applications to SAP. In SAP implementations, this process is often referred
to as data conversions. Examples of data conversion tasks include:
Filtering data for subset processing (e.g., only move European customer data, or material
masters for specific company codes)
Doing lookups to translate values ($ to USD)
Aggregating data for sum and averages
Routing data for branching and case logic
Calling custom functions or stored procedures
Joining disparate tables and files
Name and address standardization
While a custom coding approach to data migration initially offers some flexibility, this approach
has its limitations. For example, if 100 programs are required to convert data across 10 legacy
data sources (a conservative number of sources), custom coding becomes complicated,
inefficient, and a challenge to scale. Developers working on different platforms and development
tools may add to the complexity, and sharing and reusing the coding effort across the migration
team, even with the best intentions, is unrealistic.
PowerCenter helps SAP data migration teams by enabling the team to focus on the data and not
code. PowerCenter was originally developed to address data transformation and conversion
requirements associated with data warehousing. That core capability has evolved into a single,
unified, scalable enterprise data integration platform with a robust library of transformation and
data services capable of handling all data conversion on any SAP data migration project. By
leveraging PowerCenters codeless and wizard-driven approach for SAP data conversion, teams
can focus more on the business rules and data, and less on the code.

Certified Connectivity SAP to Prepare and Load Data into SAP

SAP data migration teams can realize significant benefits from using PowerCenter to prepare
legacy data to be loaded into SAP applications vs. the combination of custom code.

Native Connectivity to SAP NetWeaver

PowerCenter offers tight integration with SAP at both the data and metadata level. PowerCenter
provides broad, metadata-driven, high performance data interchange capabilities for SAP
NetWeaver. More than 600 SAP customers have leveraged this native extension to the
PowerCenter data integration platform to enable bi-directional data integration with the SAP
NetWeaver platform.
PowerCenters SAP connectivity features include:
Import of metadata for any SAP data dictionary object, including transparent and clustered
tables, as well as IDOC, BAPI and DMI object types
Bi-directional data integration support for BAPI interface
Bi-directional data integration support for ALE/IDOC interface
Flexibility to source or target IDOC data in real-time or in batch
Ability to prepare legacy data into well formed and valid DMI files, ready for upload with the
SAP NetWeaver LSMW utility
14

White Paper

Figure 7 shows a simple PowerCenter data migration mapping in which the customer master
data from multiple mainframe sources are being sourced and prepared in a valid SAP DMI
format.

Figure 7: PowerCenter Preparing SAP DMI File for Data Migration

Note how a single PowerCenter transformation within the mapping replaces the traditionally
coding-intensive effort for preparing a well-formed and valid file ready for loading into SAP. All of
the detail shown in the DMI customer master object is entirely imported directly from the SAP
application layer.

Implementing or Upgrading SAP

15

The ability to access and manage metadata makes PowerCenter unique. When using
PowerCenter for SAP data migration, the SAP metadata is automatically interpreted within the
transformation to validate all legacy data. This means that as the legacy data flows through the
DMI transformation, it is validated against rules inherent within the SAP metadata such as:
Mandatory vs. option segments
Cardinality
Minimum and maximum occurrence of segments
Field level data type and precision requirements

PowerCenter Complements SAP NetWeaver

As both PowerCenter and SAP NetWeaver offer data integration capabilities, a logical question
SAP customers and implementation partners may have is which product to use and when? A
good rule of thumb is this:
Leverage SAP XI for business process integration
Leverage Informatica PowerCenter for data migration
According to a 2005 TDWI report, broadly speaking, enterprise business integration can occur at
four different levels in an IT system: data, application, business process, and user interaction.4
Figure 8 shows how the four layers of an integrated enterprise are jointly supported by the
combination of PowerCenter and NetWeaver.

SAP NetWeaver
people integration

Informatica

Multi-channel access

Data cleansing
Mappings
Complex transformations

Application
integration
+
Businees
process
management

Data
integration

Business Process
User
Interaction

Business
portal
+
Collaboration

Portal

Collaboration

information integration
Bus. intelligence

Knowledge mgmt.

Master data mgmt.

process integration
Integration
broker

Business
Process mgmt.

Lifecycle Management

PowerExchange

Source data profiling

Application

Composite Application Framework

Data

PowerCenter

application platform
J2EE

ABAP

DB and OS abstraction

Figure 8: Complementary Data Integration between SAP NetWeaver and Informatica PowerCenter

PowerCenter can access all non-SAP types of enterprise and legacy application data. It also
provides the application integration to prepare and move all non-SAP data in a bi-directional
manner with SAP.
SAP NetWeaver enables transactional based data integration requirements with the capabilities
offered with SAP XI. SAP XI also orchestrates all data integration related to business process
integration requirements, including SAP-to-SAP data integration (e.g., mySAP ERP to my SAP
APO). Finally, from an end user perspective, SAP Portals provides a proven front-end platform for
business intelligence and visibility across the enterprise.

White, Colin. Data Integration: using ETL, EAI, and EII Tools to Create an Integrated Enterprise TDWI Report
Series, November 2005

16

White Paper

Single, Unified, Metadata-Based Data Integration Platform to Support

the Data Migration Lifecycle
When data migrations projects are driven by teams that are focused exclusively on the target
system, not in the end-to-end data migration process, a common outcome is the code, load,
and explode phenomenon5. This occurs when developers code the extraction and conversion
logic thought to be required for migration, then attempt to load it to the target business
application, only to discover an unacceptably large number of errors due to unanticipated values
in the source data files. They fix the errors and rerun the conversion process, only to find more
errors, and so on. This ugly scenario repeats itself until the project deadlines and budgets
become imperiled and angry business sponsors halt the project.
PowerCenter breaks this code, load, and explode cycle. PowerCenter provides all the
capabilities that are essential for the lifecycle of SAP implementations from a single, unified
platform based on a metadata-driven architecture.
The foundation for all of PowerCenters data integration components is the shared metadata.
When changes are made anywhere in the profiling, data access, data conversion, or SAP loading
process, PowerCenter enables immediate visibility into those changes. With its metadata-driven
architecture, PowerCenter promotes faster and more flexible iterations in the data migration
lifecycle.
Figure 9 shows how PowerCenter is used for migrating data.

FIREWALL

XML, Messaging,
and Web Services

Reusability/Team
Productivity

Analyze/
Profile

Extract/
Transform

Validate/
Lead

Packaged
Applications

Iterate

Relational and
Flat Files

Access source
systems/data

Access target/data
Execute
Migration

Target Application
9

Synchronize

Mainframe and
Midrange

10

Audit/Lineage

Informatica Data Integration Platform

Figure 9: PowerCenter Is the Ideal Platform for Migrating Data

PowerCenters metadata management capabilities provide visibility across the entire data
migration processfrom sourcing legacy applications and cleansing the legacy data, to preparing
it in the format required for upload by SAP. PowerCenter enables data lineage problems to be
traced at a metadata level.

Eckerson, Wayne and Colin White. Evaluating ETL and Data Integration Platforms. TDWI Report Series, 2003

Implementing or Upgrading SAP

17

Figure 10 shows a PowerCenter data lineage diagram spanning multiple data migration
mappings, as well as each component responsible for sourcing, converting or targeting the
required data for SAP. This diagram shows the flow of migration logic. Once the suspect area of
data migration logic has been identified, users can drill into the object and make the appropriate
changes to the relevant data mapping object.

Figure 10: PowerCenter Data Lineage Diagram enables tracking and auditing of end-to-end migration from legacy applications to SAP

PowerCenter helps data migration teams trace and prove how data has been converted and
moved. The enhanced data visibility and tracking helps organizations comply with reporting
requirements. These capabilities also help with user adoption, instilling new SAP application
users with confidence that legacy application data has in fact been converted and moved.

PowerCenter has been awarded Powered By

SAP NetWeaver status by porting the
PowerCenter platform and PowerCenter Web
Service Hub to the SAP J2EE platform. SAP
users can access PowerCenters Web Services
capabilities directly through SAP NetWeavers
own Portals front-end.

Furthermore, PowerCenter alleviates the politics associated with data migration projects. Data
migration activities, whether related to legacy applications or the target SAP application, can be
centralized within a single, unified data integration platform. This promotes effective and
productive communication between legacy and SAP resources, and between technical and
functional resources.

Informatica and SAP: Working Together for Joint

Customer Success
Informatica and SAP are in partnership to ensure organizations successfully implement SAP
applications. Evidence of this strong partnership is demonstrated through:
PowerCenters Powered By NetWeaver certification
Informatica and SAPs Master Relationship Agreement

The global Master Relationship Agreement

between Informatica and SAP underscores
and validates how PowerCenter offers a
certified and proven solution for SAP data
migration projects.

18

A long track record of proven joint customer success

Powered By NetWeaver Certification

Informatica is a preferred vendor in SAPs partner ecosystem and has achieved a level of
certification unequalled by any other data integration platform provider. In addition to developing
a growing library of SAP certified interfaces, PowerCenter is a certified member of the Powered
By NetWeaver program, which is a certification level above typical software vendor
certifications. Powered By NetWeaver is a program where partners develop solutions directly on
the NetWeaver application platform.

White Paper

Master Relationship Agreement

On October 20, 2005, Informatica signed a global Master Relationship Agreement with SAP AG
and a Go-to-Market Agreement with SAP America focused on accelerating the time-to-value of
SAP data migrations and other strategic data integration initiatives for SAP customers. This threeyear agreement provides a framework for the execution of local go-to-market agreements piloted
by SAP. Informatica is working with SAP customers to mitigate the risks and increase the
effectiveness of data migration, system consolidation, and other strategic data integration-driven
projects.

Track Record of Joint Customer Success

Perhaps the strongest indicator of partnership that works to the benefit of customers is a robust
track record of joint customer success. Informatica and SAP have more than 600 joint
customers. These customers have relied PowerCenter to consolidate instances of SAP, to migrate
data into SAP, and to successfully implement SAP applications in their environments. Examples
of joint SAP and Informatica data migration customer success include:

Major Utilities/Energy Company

Challenge
Stovepipe application architecture across 15 legacy systems due to internal growth and
growth via M&A
Need to migrate 15,000 human resource records and 2.5 million customer data records
into SAP
Data quality across heterogeneous legacy applications not meeting SAP standards
and requirements
Solution
Leverage PowerCenters rich legacy and SAP integration
Single, unified platform to meet end-to-end data migration requirements
Reuse migration components through multiple phases in project
Results
Delivered project on time and on budget
Reused more than 50 percent of PowerCenter components for data migration

Military Defense Organization

Challenge
Multitude of mainframe legacy applications managing logistics
Available migration project team inexperienced in SAP and Informatica
Unsure of how to identify what legacy data required for SAP
Solution
Standardize on PowerCenter for data migration, including extraction, conversion, and
preparation of data for SAP
Leverage PowerCenters built-in data cleansing capabilities to improve data quality
and validation
Results
Compressed SAP implementation projects overall timeline by 66 percent
Delivered expanded scope of original implementation with 80 percent less effort

Implementing or Upgrading SAP

19

Large Reinsurance Enterprise:

Challenge
Need to meet finance-related reporting requirements to ensure compliance
Need to reconcile financial business processes across disparate legacy systems (including
multiple SAP instances), leading to close periods of more than 30 days
Solution
Centralize sourcing of legacy and existing SAP systems within PowerCenter
Consolidate application instances on PowerCenter
Results
Reduced financial close cycle from more than 30 days to fewer than five days
Simplified financial master data75 percent fewer master journal entries in consolidated
SAP instance
Reduced chart of accounts from 34,000 to less than 2,000 entries

Conclusion and Next Steps

SAP implementations are complex. Data migration is critical to the success of SAP
implementations. But data migration should not be approached as singular event. There are data
migration challenges to be met throughout an SAP implementation. The five main data migration
challenges are:
1. Identifying and analyzing source data
2. Accessing source data
3. Addressing the quality of the data within the legacy applications
4. Preparing and loading data into SAP
5. Supporting the data migration lifecycle
The best way to overcome these challenges is to rely on Information PowerCenter, a single,
unified enterprise data integration platform based on a metadata-driven architecture.
PowerCenter offers data migration teams powerful capabilities to meet each of the five data
migration challenges. The capabilities include:
Data profiling
Universal data access
Built-in data transformation and correction
Certified connectivity to SAP
Furthermore, PowerCenter allows data migration teams to leverage all these capabilities from a
single, unified data integration platform. This increases productivity, ensures scalability, and
reduces risk.
Now that you have a solid understanding of the challenges around SAP data migration and how
PowerCenter can help you overcome them, what is your next step? Informatica has developed an
offering to show you how you can make your next data migration project a success. This offering
is called the Data Migration Readiness Assessment.
The Data Migration Readiness Assessment demonstrates the value of leveraging Informatica for
SAP data migrations. It also serves to jump start any SAP data migration project.

20

White Paper

The Data Migration Readiness Assessment is designed to help any SAP customer understanding
the challenges and risk in a data migration project:
1. Identify data risks early
2. Scope and plan migrations effectively
3. Deliver SAP implementation on time, on budget, and in scope
Figure 11 shows how the Data Migration Readiness Assessment works.

2
Identify candidate sources
Source
System
1

1
3

Identify 1-2 SAP entities

e.g., ItemMaster,
CustomerMaster

Extract source data

Analyze source data
Identify risks in source data

Identify 3-5 attributes

Source
System
2

SAP
Stage

Legacy
Stage
Source
System
3

SAP

4
Create mappings to SAP
Identify risks in mapping

Source
System
4

Figure 11: The Data Migration Readiness Assessment Jump Starts Data Migration Projects

To find out more, please visit us at www.informatica.com or call us at (800) 653-3871

Implementing or Upgrading SAP

21

Worldwide Headquarters, 100 Cardinal Way, Redwood City, CA 94063, USA

phone: 650.385.5000 fax: 650.385.5500 toll-free in the US: 1.800.653.3871 www.informatica.com
Informatica Offices Around The Globe: Australia Belgium Canada China France Germany Japan Korea the Netherlands Singapore Switzerland United Kingdom USA
2006 Informatica Corporation. All rights reserved. Printed in the U.S.A. Informatica, the Informatica logo, and, PowerCenter are trademarks or registered trademarks of Informatica Corporation in the United States and in jurisdictions
throughout the world. All other company and product names may be tradenames or trademarks of their respective owners.

J50760 6665 (01/11/06)