SAP Community - SAP S/4HANA migration cockpit

Data Migration Cockpit in SAP S/4HANA public cloud.

2025-05-22T10:35:12.861000+02:00

The SAP S/4HANA Migration Cockpit provides a user-friendly interface to migrate master and transactional data, such as initial stock, into an SAP S/4HANA system. This document outlines the step-by-step process to upload initial stock using the Migration Cockpit with the "Staging Table" approach.

Prerequisite:

Scope ID to be activate: 2Q2 - Data Migration to SAP S/4HANA from Staging

Business role activation: SAP_BR_BPC_EXPERT- Configuration Expert - Business Process Configuration.

Create a Project
- Navigate to App: Migrate Your Data. App ID: F3473

- Click on Create to start a new project and select Migrate data using staging table.

- Enter the project name (e.g., Initial_Stock_Upload).

Enter the project name, and mass transfer ID is system generated ID for each project and it is used to differentiate the projects across the system. When working on the extension template, fill in the mass transfer ID in the run ID column for identification.

In the database connection, select the local SAP S/4HANA database since this is not a remote migration. Click on this and proceed to step 2. Select the relevant template based on your project activity. Here, you need to pick the material inventory balance template for Initial Stack Upload project.

On the left side, you will see a list of available templates. Choose the template you want and move it to the right side. Then, click on review and create the project.

The project has been created, but it hasn't started yet. When you start the project, the status changes to in progress. After you finish the project, you mark it as finished and choose how long to keep the data. Once this period ends, the project disappears from the list. However, the data you uploaded will still be available in the system.

After you create the project, there are some important details to know before starting.

First, there are stage-wise data validations. In this migration object how many tables are involving and how many instances going to create in the system.

Next mapping tasks table you can get the information during mapping task process, like errors and successful same you will get during simulation and migration.

Download the template
Upload the prepared (data filled) template
Prepare the data
Mapping tasks
Simulation
Migration
Correction file

The above the steps involved in the migration process. If you completed the each process next process with move automatically you need to just execute the process. Incase any error in the current process it won't proceed to next process you need to resolve the error and move to next process. Correction file will not generate for all the process. Incase migration completed with error you need to generate correction file and in that file only failed line items are available. You should correct it and reupload and reprocess the steps again.

Download & Upload.

Download the Template in XML format, file the relevant data, and upload the template.

Prepare.

The staging tables need to be prepared before they can be used to transfer data to SAP S/4HANA.

You can also run a consistency check for the data in the staging tables. All records need to be associated with records at a higher level in the hierarchy of staging tables. The consistency check checks whether these associations exist.

Note that if you have transferred data to the staging tables using template files, the system has already performed the consistency check.

However, if you have transferred data to the staging tables using your preferred tools, we recommend performing the consistency check now.
Mapping Task.

Mapping tasks are essential for ensuring accurate data transfer by specifying how source fields in a legacy system are related to target fields in the SAP system.

Mapping tasks help the system understand how to connect the values in your upload file with the values already defined in SAP.

For example, in your file, you might write the full state name like "Karnataka", but SAP uses a short code like "KA". Instead of changing all values in the file, you can simply create a mapping that tells SAP:

"Whenever you see Karnataka, use KA."

This is important for fields like:

Document Type (e.g., "Standard" → "NB")

Country (e.g., "India" → "IN")

Region (e.g., "Tamil Nadu" → "TN")

These values are fixed in SAP and can’t be overwritten. Mapping helps make sure your data fits SAP’s format without changing your original template.

Simulation.

Run Simulation to validate consistency and completeness.
Check logs for errors or warnings.
Migration.
After a successful simulation, start the Migration.
SAP creates Material Documents using movement type 561.
Migration Result.
Review Log Files for confirmation.
Verify stocks using Display Material Document, Stock Overview (MMBE), or Monitor Material Stocks.
If errors occur, refer to the logs, create the correction file and correct the data, then reprocess.
This completes the initial stock upload using the SAP S/4HANA Migration Cockpit in public cloud.

Note: upload file template should be below 100MB

And this activity is only for material stock upload. There is no option to maintain posting period in the migration template. For this use “Define Settings for Legacy Data Transfer” and maintain the posting period and keep the status as ongoing once activity completed switch to in preparation or completed. SAP Note: 2914088 - Migration Error: Posting period &1 YYYY is not open. - SAP for Me

Step-by-Step Guide to Data Migration Cockpit in SAP S/4HANA Public Cloud

2025-05-25T16:04:54.093000+02:00

What is the Data Migration Cockpit?

The Data Migration Cockpit is an SAP Fiori-based application designed to simplify and manage the migration of both master data and transactional data into SAP S/4HANA Public Cloud during system implementation.

It provides a structured, user-friendly interface with the following key capabilities:

Predefined Migration Objects – such as Profit center, cost center, Customer, Vendor, G/L Accounts, Asset Master, etc.
SAP-Provided Excel Templates – for easy data input and mapping
Built-in Validation & Error Checking – helps identify and correct data issues before posting
Step-by-Step Guided Process – ensures consistent and accurate data migration

With the Data Migration Cockpit, businesses can reduce complexity, minimize errors, and ensure a smooth go-live by efficiently uploading clean legacy data into the SAP cloud system.

Steps to Perform Data Migration in SAP S/4HANA Public Cloud

Step 1: Access the Data Migration App

Go to the Fiori Launchpad.
Open the app: "Migrate Your Data – Migration Cockpit".

Step 2: Create a New Migration Project

Click “Create”

Enter a name for your project eg.. profit center Migration

When you create a migration project, it is saved but not yet started. Once you begin working on it, the status changes to "In Progress." After completing the migration steps, you mark the project as "Finished" and select how long the system should retain the project data. Once that time period ends, the project is automatically removed from the list. However, the data you uploaded will remain in the system and can still be used.

Important Details Before Starting Your Migration Project

After you create the migration project, there are some key points to understand before you begin:

Stage-wise Data Validation: The system performs validations at different stages. You can see how many tables are involved in the migration object and how many data records (instances) will be created in the system.
Mapping Tasks Table: During the mapping process, you can view detailed information about your data, including any errors or successful mappings. You will also see similar reports during the simulation and actual migration steps.

Download the Template
Get the Excel template provided by SAP for the migration object you want to upload.
Prepare the Data
Fill the template carefully with your legacy data, following the format exactly.
Upload the Prepared Template
Upload your completed Excel file into the Data Migration Cockpit.
Mapping Tasks
Review and adjust how your data fields map to SAP system fields if needed.
Simulation
Run a test migration to check for errors without actually posting data.
Migration
Execute the real data upload into SAP once the simulation is successful.
Correction File
If errors appear, download the correction file, fix the data, and repeat the upload process.

These are the steps in the migration process. After you finish one step, the system will take you to the next step automatically. You just need to follow and complete each step.

Download Template and Upload Data

Get the template as an XML file, enter the necessary data, and submit the filled template by uploading it back.

Mapping Task

The Mapping Task helps you connect the data from your uploaded file to the correct values in SAP S/4HANA.

For example:

You may need to match company codes, currencies, or country codes from your old system to the values used in SAP.

During this step:

The system shows you any missing or incorrect values.
You can manually adjust or confirm the correct mappings.
Once everything is mapped correctly, you can continue to the next step.

Simulation

The Simulation step lets you test the data migration without actually posting the data into the SAP system.

What happens during simulation:

The system checks if the data is correct and complete.
It shows any errors or warnings in the data.
You can review the results and fix any problems before doing the actual migration.

This step helps you avoid mistakes during the real migration.

Migration

After a successful simulation, you can start the Migration step.

In this step:

The system uploads the data from the staging tables into SAP S/4HANA.
All valid records are posted to the system.
You can see a summary of successful and failed records.

If there are any errors, you can fix them and repeat the migration for those records.

This is the final step where your data becomes active in SAP.

Migration Result

After the migration is complete, you can view the Migration Results to check the status of your data upload.

In this section, you will see:

Successful Records – These records were uploaded and posted correctly into SAP.
Failed Records – These records had errors and were not posted.

For failed records:

The system shows error messages to help you understand what went wrong.
You can download a Correction File, fix the issues, and re-upload the corrected data.

Reviewing the migration result helps ensure that all your data has been properly transferred into SAP S/4HANA.

The uploaded template file must be less than 100 MB in size. If your data is too large, consider splitting it into multiple files.

#S/4HANA Public Cloud

#Data Migration Cockpit

Data Migration in SAP : The 5W Strategy for SAP Data Migration

2025-08-07T10:56:09.816000+02:00

Good day, reader!
This blog will explain when and why data migration is required for a successful S/4HANA conversion.

When an organization transitions to SAP S/4HANA or consolidates several systems into a single SAP landscape, data migration becomes one of the most important success criteria.
A poor migration strategy causes process disruptions, compliance concerns, and dissatisfied end users/businesses. A systematic 5W framework—What, Why, Who, When, and Where—assists you in developing a robust migration strategy that can reduce risk.

1. To begin with, what is Data Migration in SAP?

Moving important business information, such as material masters, customer profiles, financial summaries, and active transactions, from older systems to a SAP framework is referred to as SAP data migration.

A typical migration strategy consists of

Data from source systems is extracted
cleaned with validation to confirm accuracy
transformed to SAP S/4HANA data formats

with the help of SAP S/4HANA Migration Cockpit (LTMC/LTMOM), SAP Data Services (BODS), and SAP Data Intelligence.

2. Why is SAP Data Migration Important?

Business continuity—Complete and clean data lets your SAP system run properly day one.
Regulatory compliance—Correct historical and financial data facilitates audits and reporting needs.
Data quality improvement—Migration projects offer the opportunity to purge duplicate, inconsistent, or out-of-date records.
Reduced go-live risk—well-planned migration prevents last-minute surprises.
Future readiness—SAP S/4HANA is fueled by high-quality data for analytics, AI, and automation programs.

3. Who Participates in the SAP Data Migration?

Data migration is not the exclusive IT responsibility. A cross-functional team is highly important.

Business process owners need to identify critical data and validate migration outputs.
SAP functional consultants do mapping of historical data to SAP modules (FI, SD, MM, or PP).
Data migration/ETL experts carry out extraction, transformation, and loading activities.
SAP Basis and Security teams maintain system connectivity, performance, and authorizations.
Project managers Migration schedules must be synchronized with overall implementation milestones.
Compliance and audit teams confirm completeness and accuracy for regulatory approval.

4. When to schedule a data migration?

Migration planning should be initiated early in your SAP S/4HANA implementation or upgrade journey.

Key phases are:

At the Blueprint/Design stage, determine data sources and objects.
The Realization phase involves developing and testing migrating tools and programs.
The Cutover process applies the final load immediately prior to going live.

5. Where Does Data Migration Fit Within the SAP Landscape?

Data transfer impacts every SAP module, from Finance and Procurement to Sales and Manufacturing and others. The methodology is different for on-premise and cloud S/4HANA, but the key concepts remain the same:

Map non-SAP data structures to SAP standards for integration of CRM, PLM, and legacy ERP applications.

Summary:

SAP migration involves more than just the physical transfer of data from one system to another. It's a matter of transferring the right data, in the right format, at the right time. You can take the 5W approach and can moderate migration risk, achieve a more seamless go-live, and establish a sound foundation for future digital transformation.

If you're migrating to SAP S/4HANA, begin with a well-defined data migration plan, utilize proven SAP data migration tools, and engage technical teams and business stakeholders at an early stage.

Summary : Data Migration

SAP S/4HANA Migration cockpit: Easier Error Handling

2025-08-14T15:58:47.989000+02:00

Good news 🎉 – with SAP S/4HANA Public Cloud 2508 release, working with upload files just got smoother!

📊⚠️ Get All Errors at Once - during file upload, the migration cockpit now simultaneously checks for file sanity, duplicates, and consistency. This allows all errors to be displayed at once, rather than sequentially.

🧾🔍Error-Friendly Template - after you upload your template to the Migration Cockpit, you may encounter various errors. Previously, you had to search for these errors manually in your file. Now, you can simply download your file along with the identified errors. In the “Messages” tab, hyperlinks take you directly to the problematic cells, making corrections straightforward.

🔄📄Correction File After Simulation
You might already be familiar with the correction file you can generate after Migration. Now you can do the same after Simulation! This gives you a focused file with only the failed records, so you can fix and move on faster.

📢All these improvements, along with new migration objects for the SAP S/4HANA 2508 Public Cloud release, are covered in the Overview Presentation – What’s New Section, which also includes high-resolution screenshots😄

How to perform a successful Carve-Out in SAP ECC and S/4HANA – Update and New Trends 2025 (Part I)

2025-08-19T21:56:37.679000+02:00

It has been four years since I published my original five-part series on SAP Carve-Outs - covering basic topics from what a carve out is (Part I), data migration (Part II) and technical orchestration (Part III) to process and analytics considerations (Part IV) and S/4HANA value creation (Part V).

Time for a look back on what has changed since then with new trends for SAP Carve-Outs and Divestiture Projects in business and technology.

The good news is: The core principles and methods outlined in those earlier posts remain as relevant today as they were then.

However, the past four years have brought notable shifts in both business dynamics and technology landscapes, reshaping how carve-out projects must be planned, managed, and executed. In many cases, these changes have introduced greater complexity, requiring organizations to adapt their strategies to ensure success.

From our recent project experience and industry observations, two main drivers stand out:

More complex M&A scenarios – including multi-entity, multi-source, and joint-venture carve-outs, often with heightened compliance and harmonization requirements.
Technology disruption – particularly the accelerated move to the cloud and the looming SAP ECC end-of-maintenance deadlines (2027, or 2030 with costly extended maintenance under SAP RISE).

In this update, I will explore these emerging trends from two perspectives:

Business & M&A Scenario-Driven Trends (Part I):

Harmonization of processes and structures during the carve-out to reduce operational complexity post-transition.
Multi-source and joint-venture carve-outs that combine data from different systems into a consolidated environment.
Enhanced compliance and legal alignment to address stricter regulatory and contractual requirements.
Business Continuity and Operational Excellence during and after go-live to keep operations running seamlessly and without any business disruption

Technology-Driven Trends (Part II):

Move to cloud – whether via hyperscalers (AWS, Azure, Google Cloud) in private hosting, or through SAP RISE and GROW with SAP offerings.
Expanded functional and integration scope – including SAP modules, third-party systems (Salesforce, Ariba, IBP, EDI), and rebuilt analytics landscapes.
Combined carve-out and S/4HANA transformation to deliver a modern, value-enhanced system to the buyer.
Custom code carve-out and clean-core modernization to simplify future operations and reduce technical debt.

Both parts of this post build on the foundation of the original series, now enriched with current project examples and the latest industry best practices - offering a forward-looking view of what it takes to execute a successful carve-out in 2025 and beyond.

Business and M&A Scenario–Driven Trends in Modern SAP Carve-Outs

1. Harmonization of Processes and Structures

In recent years, we have seen a growing emphasis on harmonizing processes and organizational structures during carve-outs – especially to reduce operational complexity after the transition. This is particularly common among private equity buyers, who aim to simplify process variants, adopt industry best practices over heavy customization, and standardize reporting structures across multiple acquisitions. Two main approaches are used:

Option 1: Greenfield Implementation in the Public Cloud

Some buyers opt for a brand-new SAP system - often in an SAP GROW public cloud environment - built entirely on standardized, industry best-practice processes.

Advantages: Fast to implement, provides a clean slate, and allows extensions via SAP BTP without burdening the core system.
Caveats:
- Historic data is typically lost, requiring separate archival for audit or business purposes.
- The “big bang” cutover into entirely new processes can disrupt business operations without strong change management.

This approach is best suited for asset deals or acquisitions of smaller, less complex entities.

Option 2: Selective Data Transition (SDT)

With the right Transformation Software, SDT enables you to migrate only selected data while simultaneously transforming processes, configurations, and structures. For example, in a carve-out involving multiple company codes from a highly integrated environment, intercompany relationships may need to be converted into customer-vendor-structures - requiring both process reconfiguration and master/transactional data transformation.

SDT also allows:

Changing charts of accounts, profit/cost centers, plants, and org structures.
Transforming open and historical transactional data to match new processes.
Maintaining a continuity of historical data in the new environment.

Trade-offs: SDT is more complex, typically requiring 6-12 months for high-complexity projects and demanding greater involvement from both IT and business teams.

We have seen SDT increasingly used in share deals, spin-offs, and large-scale asset divestitures with significant process complexity.

2. Multi-Source & Joint-Venture Carve-Outs

Another fast-growing trend involves multi-source and joint-venture carve-outs, where data from multiple ERP systems must be consolidated into one new environment.

Typical scenarios:

Multi-source carve-out: Extracting data from several ERP systems (ECC, S/4HANA, or both) within the same organization, often during ongoing SAP S/4HANA transformation projects.
Joint-venture setup: Merging data and processes from multiple partners into a shared system.

Challenges include:

Harmonizing master data, processes, charts of accounts, and org structures – including historic transactional data.
Managing licensing and data visibility between different corporate owners.
Separating and rebuilding formerly shared subsystems or third-party integrations.

Given their complexity, these projects nearly always use SDT combined with system merge methodologies, cross-system harmonization, and automation for plant or unit reallocation - while ensuring strict data access controls between Joint-Venture partners.

Additionally, these projects require a significant engagement from SAP specialists to adjust and reshape processes, harmonize data and organizaional structures, properly adjust interfaces to external or cloud-based systems, and enhance data analytics and reporting. Due to the variety of skill sets needed and the urgency in a carve-out project, the setup usually requires engaging with a specialized System Integrator (SI) early in the project planning phase to ensure these topics are successfully covered.

3. Enhanced Compliance & Legal Alignment

Stricter regulations and geopolitical constraints now significantly influence carve-out planning and execution.

Examples include:

GDPR for companies doing business in EU-countries
Industry-specific requirements (e.g., regulated industries like Utilities, Aerospace & Defense).
Data sovereignty laws such as China’s DSL, CSL, and PIPL, which can require a separate, localized SAP system, to protect your global business data by keeping it separate.

Implications:

Migrate only approved data subsets, particularly personal data.
Ensure full audit documentation of extraction, transformation, and loading.
Include technical safeguards such as log tracing, reversible deletions, and cutover checks.

Modern SDT Software products - like cbs ET Enterprise Transformer - already offer audit-grade logging for these processes, making compliance easier to prove post-project.

Vendor landscape Note:

In the context of the SDT approach, it is worth noting that only four vendors worldwide currently provide both the specialized SDT software and the associated service capabilities needed for complex carve-out scenarios. All are members of the SAP S/4HANA Selective Data Transition Engagement Program and typically collaborate with other system integrators (SI) to cover the full range of services required.

At present, only one of these vendors is able to deliver the complete end-to-end service portfolio independently - an advantage that means fewer communication gaps, with consultants who understand the full scope of services and the role of SDT in the project, rather than working in isolated silos.

Given the sustained market demand for SDT-based initiatives - including both carve-outs and broader SAP S/4HANA transformation projects - delivery capacity can become a bottleneck. To mitigate this risk, organizations should secure delivery slots as early as possible, ideally before the transaction is finalized and the Transition Services Agreement (TSA) is signed, to ensure the resource availability and alignment with agreed project timelines.

4. Business Continuity and Operational Excellence during and after go/live

A successful carve-out is not just about getting the technical cutover right - it’s equally about ensuring the carved-out organization can operate smoothly from day one. One of the most significant risks during these projects is operational disruption, which both buyer and seller are highly motivated to avoid before, during, and after the system handover. Maintaining stable business operations has increasingly become therefore a central project goal.

Change Management and Training

Beyond ensuring clean, accurate data in the new system, it is critical to prepare the business workforce for changes to their daily processes and routines. This requires structured change management and targeted training in all areas where processes are being redesigned or where new roles and responsibilities are introduced. This becomes even more important when moving to more standardized, harmonized processes - often with fewer customization and a leaner user interface than in the previous environment.

In such cases, acceptance grows when users understand the why behind the change and are given the tools and guidance to confidently perform their work in the new system. Proper preparation minimizes post–go-live disruption and supports long-term adoption.

Application Management Services (AMS)

In recent years, we have seen a strong trend toward integrating AMS into carve-out project scope from the outset. This is particularly relevant when:

The carved-out entity lacks internal SAP expertise after organizational changes or downsizing post-transaction.
The seller’s IT services under the TSA come at a premium, and the buyer seeks a faster, more cost-effective transition away from them.
The buyer needs a bridging solution until a new internal IT team is in place.

Some AMS providers even offer fractional consulting for small-scale enhancements and process improvements after go-live, adding flexibility during the stabilization phase.

Choosing a provider who delivers AMS as part of a comprehensive business transformation has clear advantages, as they understand carve-out–specific requirements such as altered team responsibilities, new support structures, and heightened service continuity needs.

For smaller and mid-sized organizations, SAP’s M&A Ambassador Program can be a valuable option, particularly for PE-driven carve-outs. It equips these projects with expert partner frameworks to manage both the initial deployment and post-go-live stabilization. Unfortunately, this program does not include any provider with SDT capabilities.

Recommendation: Define AMS scope and contracts early - including infrastructure operations, interface monitoring, patching, SLA targets, and knowledge handover - so that post-go-live operations run as smoothly as the cutover itself.

Summary of Part I and Key Takeaways

Over the past years, my team and I have seen, and experienced with our customers, that carve-outs in 2025 are no longer purely IT-driven exercises.They are strategic business transformations requiring early leadership engagement and precise planning.

On the business side, the key success factors are:

Early preparation: Business readiness and TSA alignment before signing prevent costly delays.
Selective Data Transition (SDT) as a game changer: Enabling selective migration and process harmonization with minimal disruption; early partner selection is crucial given limited global capacity.
Integrated service delivery: One provider delivering end-to-end reduces communication gaps and ensures holistic understanding.
Business continuity protection: Early investment in process mapping, change management, and training ensures smoother cutovers.
Built-in stabilization: Integrating AMS from the onset speeds post–go-live recovery.
Organizational change management: Early engagement drives faster adoption and productivity.

For the technical delivery models, toolsets, and SDT-related innovations shaping carve-outs in 2025 and beyond, see Part II of this Update 2025 post.

If you’d like to discuss your own carve-out scenario, feel free to contact me directly. @Lorenz_Praefcke2

Simplifying PM Task List Migration: Iterative Loading of Operations and Suboperations

2025-09-18T16:39:32.439000+02:00

Why an Iterative Approach?

The operation numbers are system-generated or derived during the first load.
Suboperations must reference the parent operation Node.
This dependency makes it practical to load operations first, capture the operation Node, and then load suboperations.

Step 1: Creation of Custom object

Create a custom Migration object by enhancing the existing standard cockpit object by adding 3 fields at the S_OPERATIONS Structure:

ZZPLNKN-Node
ZZUVORN- Suboperation Number
ZZSUMNR- Suboperation Node

After adding above fields in Source structure complete the filed mapping to the target and complete the customization.

Note: we need to replicate the field PLNKN for the S_MPACK structure as well, if you are using Maintenance strategy:

Step 2: Load Operations (Iteration 1)

Prepare your input file with the following details:

Task List Group (PLNNR), Group Counter (PLNAL), Activity number (VORNR), node (ZZPLNKN)

Note: during first iteration load the records with operation numbers only to be loaded in technical terms load the task list that has blank or zero in SUMNR filed from source

Use the custom cockpit object created to load the operations.
Capture the generated Node number (ZZPLNKN) from the output of the FM.

These numbers will serve as reference keys for loading suboperations in the next iteration.

Step 2: Load Suboperations (Iteration 2)

Prepare a second input file including:

Note: during Second iteration load the records with Sub-operation numbers only to be loaded in technical terms load the task list that has value in SUMNR filed from source

Task List Group (PLNNR), Group Counter (PLNAL), node (ZZPLNKN)
Activity number (VORNR) – Update this filed with parent VORNR value
Suboperation Number (UVORN)- Should be updated in sequence
Suboperation Node (ZZSUMNR)- this filed is to be updated with the newly generated NODE(PLNKN) from the system.

Use the custom cockpit object created to again load the sub-operations.
Validate in SAP:

Suboperations should appear nested under the correct parent operations in the General Task List. Shown below

Key Considerations

Ensure the task list header is already created before starting.
Maintain sequence numbers correctly for operations and suboperations.
Validate both iterations in a test system before executing in QA or Production.
Log all generated operation numbers for audit and troubleshooting.

Benefits of This Approach

Handles dependency between operations and suboperations cleanly
Reduces risk of errors during cutover
Can be repeated for dry runs and mock loads before final cutover
Compatible with SAP Migration Cockpit (via staging tables) and custom load programs

Conclusion

By adopting a two-step iterative approach with Existing Migration cockpit object, you can ensure accurate loading of both operations and suboperations for General Maintenance Task Lists. This method has proven effective in avoiding errors due to missing operation references and makes the data migration smoother.

A Comprehensive Guide to Data Migration with the SAP S/4HANA Migration Cockpit

2025-09-22T19:17:06.022000+02:00

A Comprehensive Guide to Data Migration with the SAP S/4HANA Migration Cockpit

For End Users, Key Users, Dummies, and Consultants

Page 1: Introduction to Data Migration in SAP S/4HANA

Welcome to your complete guide to the SAP S/4HANA Migration Cockpit. Migrating data is one of the most critical activities in any SAP S/4HANA implementation project. It's the process of moving your essential business data—like customer information, product lists, and financial records—from your old system(s) into your new S/4HANA environment.

Think of it like moving into a new, state-of-the-art house. You can't start living there until you've moved in your furniture (your data). The SAP S/4HANA Migration Cockpit is your professional moving company, designed to make this process as smooth, efficient, and error-free as possible.

Who is this guide for?

For Dummies & End Users: We'll start with the basics, explaining what the tool is and why it's important, using simple analogies and clear steps.
For Key Users: You'll learn how to prepare your data, fill out the templates for your specific business area (like sales or procurement), and validate that the migrated data is correct.
For Consultants: You'll find technical details, information on advanced tools like the Migration Object Modeler, and a framework for managing the entire migration lifecycle.

This guide is based on the standard functionalities of the SAP S/4HANA Migration Cockpit 1, a powerful tool embedded directly within the S/4HANA solution2. It requires

no programming knowledge 3and provides a guided, step-by-step process for your migration journey4.

Page 2: Chapter 1 - Understanding the SAP S/4HANA Migration Cockpit

At its core, the Migration Cockpit is a tool designed to support

New Implementation scenarios 5—also known as a "Greenfield" approach—where you are setting up a fresh SAP S/4HANA system. It helps you load data from both old SAP systems (like ECC) and non-SAP systems6.

The tool is available for all SAP S/4HANA deployment models:

Cloud and On-Premise7.

Key Features and Value Proposition

The power of the Migration Cockpit lies in its simplicity and pre-packaged content. Here's what makes it so valuable:

Preconfigured Migration Content: SAP provides a huge library of "Migration Objects" for the most common data types, such as customers, suppliers, materials, bank data, open purchase orders, and G/L account balances8888.
Predefined Templates: For each migration object, the cockpit provides a ready-to-use Microsoft Excel XML file template9. You just need to extract your legacy data and paste it into this file in the correct format.
Automated Mapping: The tool automatically maps the columns in the template file to the correct fields in the S/4HANA database tables10. This saves countless hours of technical work.
Guided Process: The cockpit guides you through every step, from creating a project to validating and importing your data11.
No Programming Required: All migration programs are generated automatically by the system12. You don't need a developer to write custom code for loading data.
Data Validation: Before committing the data to the database, you can run a simulation to check for errors against your system's configuration and business rules1313. This ensures high data quality.

Page 3: The Three Pillars of the Migration Cockpit

The migration process can be understood through three main pillars, as shown in the architecture overview14141414.

Data Provisioning (The "What"): This is your source data. You must first

extract data from your legacy systems (any system, SAP or non-SAP) and place it into the provided Microsoft Excel XML template files15151515. For On-Premise versions, there are more advanced options like staging tables, but for most users, the file-based approach is the starting point.

Migration Tools (The "How"): This is the engine of the process.

SAP S/4HANA Migration Cockpit: This is the main user interface (a Fiori App) that you will use to manage the project, upload files, and monitor progress16.
SAP S/4HANA Migration Object Modeler (MOM): This is an advanced tool for consultants and developers. It is used when the standard migration objects are not enough, for example, if you need to add custom fields (like a special industry-specific field on the Material Master) or migrate completely custom data objects that are unique to your business17171717. This is available for on-premise and private cloud editions18.

Content (The "Intelligence"): This is the pre-packaged value from SAP.

Preconfigured Migration Objects and Mapping: The library of business objects (e.g., "Customer," "Sales Order") that SAP has already defined for migration19.
Automated Program Generation: The underlying code that takes your file and posts it into S/4HANA is created automatically20.
Built-in Data Validation: The rules and checks that ensure your data is consistent and correct before loading21.

Page 4: Chapter 2 - The Migration Process: A Step-by-Step Guide

Let's walk through a typical migration process using the file-based approach. This process is generally the same whether you are migrating Materials, Customers, or G/L Postings22222222.

Prerequisite: You must have the necessary authorization roles assigned to your user in the SAP S/4HANA Fiori Launchpad. The role is typically SAP_BR_CONFIG_EXPERT_DATA_MIG.

Step 1: Access the Migration Cockpit

Log in to your SAP S/4HANA Fiori Launchpad.
Find and click on the Migrate Your Data - Migration Cockpit tile. This will launch the application.

Step 2: Create a New Migration Project

First, you need a project to organize your work. For example, you might create one project for "Phase 1 - Master Data" and another for "Phase 2 - Transactional Data."

Inside the Migration Cockpit, click the Create button.
You will be prompted to enter a Project Name. Let's call it Z_MASTER_DATA_LOAD_01.
The system will ask for a Mass Transfer ID. This is a system-generated number used for tracking; you can typically leave it as default.
Choose your Migration Scenario. For new implementations, this will generally be Migrate Data Using Staging Tables (for On-Premise, allowing database connection) or Migrate Data Using Files (for Cloud and On-Premise). We will use the file approach.
Click

Create to finalize the project setup23.

Page 5: The Migration Process (Continued)

Step 3: Select Your Migration Objects

Now that you have a project, you need to tell the system what you want to migrate.

With your project

Z_MASTER_DATA_LOAD_01 open, you will see a list of all available Migration Objects24. This list is extensive and categorized by business area.

Scroll through the list or use the search bar to find the objects you need. For our example, let's select:

Customer (for Sales & Distribution)
Material (for Materials Management)
G/L account balance and open/line item (for Finance)

Click the checkbox next to each object you want to include in your project25. You don't have to migrate everything at once. It's best practice to group similar objects together.

Step 4: Download and Populate the Templates

For each selected object, you need to download its unique template file.

Select a migration object you've chosen, for example, Customer.
Click the Download Template button. This will download an

XML file26, which will open in Microsoft Excel.

Understanding the Template:

The file will have multiple tabs (worksheets).
The first tab, "Introduction," explains how to use the file. Read it carefully!
The "Field List" tab shows all possible fields you can populate for that object, indicating which are mandatory (marked with a *) and which are optional.
Subsequent tabs represent the different data structures for the object. For a Customer, you will see tabs for "General Data," "Company Code Data," "Sales Data," "Contact Persons," etc.

Populate the Template: This is the most crucial step. You must extract the data from your legacy system and carefully copy-paste it into the corresponding columns in these worksheets.

Example: For the "General Data" sheet of the Customer template, you would fill in columns for Name, Address, City, Postal Code, Country, etc.
Important: Do not change the structure of the file, rename tabs, or delete columns.

Page 6: The Migration Process (Concluded)

Step 5: Upload and Prepare the Data File

Once your template is filled with data, it's time to upload it back into the cockpit.

Go back to your migration project in the Fiori app.
Select the Customer migration object.
Click the Upload File button and choose the XML file you just populated.
After uploading, the system will automatically Prepare and Validate the file. This step checks for structural integrity and basic data type consistency.

Step 6: Mapping and Simulation

This is where the system checks your data against its own configuration.

After the preparation is complete, you will be taken to the Mapping Tasks screen. Here, the cockpit may ask you to confirm certain value mappings. For example, if your old system used "USA" for the United States and S/4HANA is configured to use "US," you would define that mapping rule here. For many standard values, the system can map them automatically.
Once all mapping is confirmed, click

Simulate27. The system will now pretend to post the data without actually saving it. It will check against all business rules, such as:

Does the specified Company Code exist?
Is the specified Payment Term configured in the system?
Is the provided bank key valid?

The simulation will return with a status:

Success: All records passed validation.
Errors: Some records failed. The system provides a detailed log explaining exactly which record, field, and value caused the error so you can fix it in your file and re-upload.

Step 7: Execute the Migration (Import)

This is the final step where the data is loaded into SAP S/4HANA.

Once your simulation runs successfully with no errors, the Import button will become active.
Click

Import28. The system will now perform the actual data posting.

You can monitor the progress in real-time. Once complete, the cockpit will show you how many records were successfully created. You can then log into the relevant S/4HANA application (e.g., the "Manage Customer Master Data" Fiori app) to view and verify your newly migrated data.

Page 7: Chapter 3 - For Consultants: The Migration Object Modeler (MOM)

The standard content provided by SAP is extensive, but sometimes it's not enough. You might have custom fields or entire custom tables (known as "Z-tables" in the SAP world) that need to be migrated. This is where the

SAP S/4HANA Migration Object Modeler (MOM) comes in29.

Use Cases for the MOM:

Enhancing Standard Objects: You need to add a new custom field to a standard object. For example, your business requires a "Loyalty Program ID" field on the Customer Master, which doesn't exist in the standard template. The MOM allows you to add this new field to the Customer object's structure and template30.
Creating Custom Objects: You need to migrate data for a completely custom business object that is unique to your company, for example, a "Vehicle Fleet Management" table.
Migrating Standard SAP Objects Not Yet in the Cockpit: Occasionally, SAP may not have delivered a migration object for a specific, less common data type. The MOM allows you to build your own object to cover this gap31.

How it Works (High-Level):

The MOM is a technical, design-time tool (transaction code LTMOM) available in the on-premise and private cloud editions. It provides a user interface to:

Define Source Structures: Specify the fields and structure of your incoming data (essentially, designing the template file).
Define Target Structures: Map your data to the target S/4HANA database tables and fields, including any custom "Z-fields."
Define Structure and Field Mappings: Create rules to translate source values to target values (e.g., IF source_field = 'A', THEN target_field = '10').
Generate the Migration Object: Once the design is complete, the MOM generates the runtime object that then becomes available for use in the main Migration Cockpit Fiori app.

Customizing Point (SPRO):

While the MOM itself is a transaction (LTMOM), the underlying custom fields (e.g., adding a new field to the customer master) must first be created using standard S/4HANA extensibility tools, often accessible through the Fiori Launchpad or via the SPRO transaction under Cross-Application Components -> General Application Functions -> Extensibility.

Page 8: Chapter 4 - Practical Exercise 1: Migrating Material Master Data (MM)

Let's apply the process to a real-world example. Your company is implementing SAP S/4HANA Materials Management (MM) and needs to migrate its list of raw materials from a legacy system.

Business Scenario:

You need to create 100 new raw materials (ROH material type) for your main manufacturing plant (1010) and storage location (101A). You need to define their basic data (description, unit of measure), purchasing data (purchasing group), and storage data.

Step-by-Step Exercise:

Create Project: In the Migration Cockpit, create a project named Z_MM_DATA_LOAD.
Select Object: Find and select the Material migration object.
Download Template: Download the XML template file for the Material object.
Populate Template:

Open the file in Excel.
In the Basic Data tab, you will fill in:

MATERIAL_NUMBER: e.g., RM-1001, RM-1002, ...
MATERIAL_DESCRIPTION: e.g., Steel Plate 5mm, Screw M6, ...
MATERIAL_TYPE: ROH for all entries.
BASE_UNIT_OF_MEASURE: PC (for pieces), KG (for kilograms), etc.
MATERIAL_GROUP: 00101 (e.g., for Metals).

In the Plant Data tab:

MATERIAL_NUMBER: RM-1001, RM-1002, ... (must match the basic data).
PLANT: 1010 for all entries.
PURCHASING_GROUP: 001 (e.g., Central Purchasing).

In the Storage Location Data tab:

MATERIAL_NUMBER: RM-1001, RM-1002, ...
PLANT: 1010.
STORAGE_LOCATION: 101A.

Save and Upload: Save the XML file and upload it to the cockpit.
Simulate: Run the simulation. A common error here is trying to use a Purchasing Group (e.g., 999) that has not been configured in S/4HANA yet. The simulation log will report this, and your configuration consultant will need to create it in SPRO (Materials Management -> Purchasing -> Create Purchasing Groups).
Import: Once the simulation is successful, import the data.
Verify: Go to the Manage Product Master Data Fiori app, search for one of your new materials (e.g., RM-1001), and confirm that all the views (Basic Data, Purchasing, Plant/Storage) have been created correctly.

Page 9: Chapter 5 - Practical Exercise 2: Migrating Open Purchase Orders (MM/FI)

Migrating open transactions is more complex than master data. This exercise shows how to load open purchase orders (POs) that were created in your legacy system but have not yet been fully delivered or invoiced.

Business Scenario:

You are going live with S/4HANA on January 1st. You have 50 open POs with your suppliers that need to be created in the new system so you can receive goods and process invoices against them.

Step-by-Step Exercise:

Create Project: Use a new project, Z_TRANSACTION_LOAD, or add to an existing one.
Select Object: Find and select the Purchase order (only open PO) migration object.
Download Template: Download the corresponding template file.
Populate Template: This template is more complex and has header and item details.

In the PO Header tab:

PO_NUMBER: You can enter your legacy PO number here for reference, but S/4HANA will assign a new number.
COMPANY_CODE: 1010.
PURCHASING_ORGANIZATION: 1010.
PURCHASING_GROUP: 001.
SUPPLIER_ID: The ID of the supplier in S/4HANA (this master data must be migrated first!).

In the PO Item tab:

PO_NUMBER: The same legacy PO number to link the item to the header.
PO_ITEM: 10, 20, etc.
MATERIAL_ID: The material number in S/4HANA (must be migrated first!).
QUANTITY: The remaining open quantity to be delivered.
PRICE: The price per unit.
PLANT: 1010.

Save and Upload: Save the file and upload it.
Simulate: Run the simulation. Common errors include referencing a Supplier or Material that does not exist, or using a combination of Purchasing Organization and Plant that is not configured.
Import: Once successful, import the data.
Verify: Use the Manage Purchase Orders Fiori app to find the newly created POs. Check that the supplier, materials, quantities, and prices match your legacy system. The PO will be ready for a goods receipt posting.

Page 10: Chapter 6 - The Future of Data Migration: Outlook

SAP is continuously enhancing the Migration Cockpit. The future direction focuses on providing more flexibility, automation, and integrated quality checks32323232.

Planned Functionalities and Enhancements:

More Data Provisioning Options:

Direct Access / Transfer: For migrations from an existing SAP ECC system, SAP plans to enable a direct connection to transfer data without the need for manual file extraction33333333. This significantly speeds up the process.
Staging Area: A dedicated staging database area where data can be loaded from various sources, cleaned, and validated before being moved into S/4HANA34. This is ideal for complex migration scenarios managed by a dedicated data team.

Enhanced Migration Process:

Automated Validation: More intelligent and automated checks during the simulation phase to catch errors earlier35.
Data Quality Analysis: Integrated tools to analyze the quality of source data even before migration begins, helping to identify and cleanse data in the legacy system36.
Auditable Solution: Enhanced logging and reporting to provide a clear audit trail of what data was migrated, when it was migrated, and by whom, ensuring compliance37.
Near Zero Downtime: For very large-scale migrations, SAP is working on solutions to minimize the business downtime required during the final data cutover38.

These future enhancements aim to make the migration process faster, more reliable, and less reliant on manual effort, transforming it into a more strategic part of the S/4HANA implementation journey.

Page 11: A Comprehensive Test Plan for Data Migration

For End Users, Key Users, Dummies, and Consultants

Introduction and Scope

This test plan provides a structured approach for testing and validating data migrated using the SAP S/4HANA Migration Cockpit. The scope of this plan is to verify the correctness, completeness, and usability of the migrated data within the target S/4HANA system. It does not cover the testing of business process configurations themselves, but rather ensures that the foundation data is solid.

Test Cycles:

Data migration testing should occur during multiple project phases:

Unit Testing: The consultant or key user performs the initial data load for a single object (e.g., Customer) with a small data sample (1-10 records) to ensure the technical process works.
System Integration Testing (SIT): Multiple objects are loaded in sequence (e.g., Cost Centers, then G/L Accounts, then Open Invoices) to test dependencies. A larger, sanitized data set is used.
User Acceptance Testing (UAT): Business users are given the migrated data and asked to perform their daily tasks in the S/4HANA system to validate it in a real-world context. This uses a nearly full data load.

Test Tools:

SAP S/4HANA Migration Cockpit: For executing the loads and checking logs.
SAP S/4HANA Fiori Apps / SAP GUI: For validating the data post-migration.
Microsoft Excel: For comparing source data files against post-migration data extracts.

Page 12: Test Scenario 1: Master Data Integrity (MM & SD)

Objective: To verify that fundamental master data for Materials Management (MM) and Sales & Distribution (SD) has been migrated correctly.

Test Case ID: DM_UAT_MM_001

Description: Verify migrated Material Master data for a finished good.
Pre-conditions:

The Material migration object has been loaded successfully.
The user has access to the Manage Product Master Data Fiori app.

Test Steps:

From the source data file, pick a specific finished good material number (e.g., FG-2055).
Open the Manage Product Master Data app in S/4HANA.
Search for material FG-2055.
Verify that the Basic Data is correct: Description, Base Unit of Measure, Material Group.
Verify that the Sales Data is correct: Sales Org, Distribution Channel, Delivering Plant.
Verify that the MRP Data is correct: MRP Type, MRP Controller.

Expected Results: All data points in S/4HANA for material FG-2055 must exactly match the data provided in the source file. The material should be fully usable for creating a sales order.
Actual Results: [ ] Pass [ ] Fail

Test Case ID: DM_UAT_SD_001

Description: Verify migrated Customer Master data, including company code and sales area data.
Pre-conditions:

The Customer migration object has been loaded successfully.
The user has access to the Manage Customer Master Data Fiori app.

Test Steps:

From the source data file, pick a specific customer (e.g., CUST-100200).
Open the Manage Customer Master Data app.
Search for customer CUST-100200.
Verify General Data: Name, full address, and contact information.
Verify Company Code Data: Reconciliation Account, Payment Terms.
Verify Sales Area Data: Shipping Conditions, Partner Functions (e.g., Ship-to, Bill-to).

Expected Results: The customer record exists and is complete. All details match the source file. The customer can be used to create a sales order in the system.
Actual Results: [ ] Pass [ ] Fail

Page 13: Test Scenario 2: Financial Data Migration (FI)

Objective: To verify that financial master data and opening balances have been loaded correctly and are in balance.

Test Case ID: DM_UAT_FI_001

Description: Verify migrated G/L Account opening balances.
Pre-conditions:

Migration objects for G/L Account Master and G/L account balance and open/line item have been loaded successfully.
The user has access to the Display G/L Account Balances Fiori app.

Test Steps:

From the source data file for G/L balances, identify a specific G/L account (e.g., 10010000 - Bank Account). Note its balance and currency.
In S/4HANA, open the Display G/L Account Balances app.
Enter the G/L account, company code, and fiscal year corresponding to the migration cutover date.
Execute the report.
Compare the closing balance shown in the report with the balance from the source file.
Repeat this for at least one asset, one liability, and one equity account.

Expected Results: The balance for the G/L account in S/4HANA exactly matches the provided legacy balance. The overall trial balance (debits vs. credits) for all migrated G/L balances must be zero.
Actual Results: [ ] Pass [ ] Fail

Test Case ID: DM_UAT_FI_002

Description: Verify migrated Accounts Receivable (AR) open items for a customer.
Pre-conditions:

The Customer and Accounts receivable open item migration objects have been loaded.
The user has access to the Manage Customer Line Items Fiori app.

Test Steps:

From the AR open items source file, choose a customer (e.g., CUST-100200) and note their open invoices (invoice numbers, dates, amounts).
In S/4HANA, open the Manage Customer Line Items app.
Enter the customer number and company code, and select "Open Items."
Execute the report.
Compare the list of open invoices displayed in S/4HANA with the list from the source file. Check document numbers (if mapped), posting dates, and amounts.

Expected Results: Every open invoice from the legacy system exists in S/4HANA for the correct customer with the correct amount and due date. The total AR balance for the customer matches the legacy system.
Actual Results: [ ] Pass [ ] Fail

Page 14: Test Scenario 3: Cross-Module Data Dependencies (PP/MM)

Objective: To ensure data that relies on other data objects has been migrated correctly and that the relationships are intact. A classic example is the Bill of Material (BOM).

Test Case ID: DM_UAT_PP_001

Description: Verify a migrated Bill of Material (BOM) for a finished good.
Pre-conditions:

The Material migration object has been loaded for all finished goods and raw materials.
The Bill of material migration object has been loaded successfully.
The user has access to the Maintain Bill of Material app.

Test Steps:

From your source data, select a finished good that has a BOM (e.g., FG-2055). Note its components and their quantities (e.g., 1x RM-1001, 4x RM-1002).
In S/4HANA, open the Maintain Bill of Material app.
Enter the parent material (FG-2055), the plant (1010), and the BOM usage (1 for Production).
Display the BOM.
Verify that all component materials are listed correctly.
Verify that the quantity for each component is correct.
Verify that the unit of measure for each component is correct.

Expected Results: The BOM in S/4HANA is an exact replica of the BOM from the legacy system. The system can successfully "explode" the BOM for a production planning scenario.
Actual Results: [ ] Pass [ ] Fail

Page 15: Test Scenario 4: Error Handling and Data Validation

Objective: To ensure the migration process correctly identifies and reports errors when provided with bad data. This is a negative test case.

Test Case ID: DM_SIT_VALIDATION_001

Description: Test the system's response to a template with a missing mandatory field.
Pre-conditions:

A migration project is active.
You have a populated Material template.

Test Steps:

Take a valid Material template file.
Find a mandatory field, for example, BASE_UNIT_OF_MEASURE.
Delete the value from this field for one of the rows in the template.
Save and upload the file to the Migration Cockpit.
Run the Simulate step.

Expected Results: The simulation must fail. The migration cockpit should display a clear error message in the logs, indicating that the BASE_UNIT_OF_MEASURE is a required field and is missing for the specific record. The data should not be imported.
Actual Results: [ ] Pass [ ] Fail

Test Case ID: DM_SIT_VALIDATION_002

Description: Test the system's response to data that violates a configuration rule.
Pre-conditions:

A migration project is active.
You have a populated Customer template.
The Payment Term Z999 does not exist in S/4HANA configuration.

Test Steps:

Take a valid Customer template file.
In the Company Code Data tab, for one of the customers, enter Z999 in the PAYMENT_TERMS column.
Save and upload the file to the Migration Cockpit.
Run the Simulate step.

Expected Results: The simulation must fail for that specific record. The log should show an error message stating that "Payment term Z999 is not defined in company code XXXX." The record should not be imported.
Actual Results: [ ] Pass [ ] Fail

Page 16: Test Plan Sign-Off

This section should be used to formally document the completion and outcome of the data migration testing cycles.

Test Cycle: (e.g., UAT - Finance)

Overall Summary:

(Provide a brief summary of the testing activities, e.g., "UAT testing for FI master data and open items was conducted from Sept 15-20. A total of 25 test cases were executed.")

Test Results:

Total Test Cases Executed:
Test Cases Passed:
Test Cases Failed:

Outstanding Defects/Issues:

(List any critical or major defects that remain open and need to be resolved before go-live.)

Defect ID	Description	Severity	Status

Recommendation:

Based on the results above, the test team provides the following recommendation:

[ ] Approval for Go-Live: The migrated data is of sufficient quality for production use.
[ ] Approval with Conditions: Go-Live is approved pending the resolution of the outstanding issues listed above.
[ ] Not Approved: The migrated data has critical defects, and a further test cycle is required after fixes are applied.

Sign-Off:

Role	Name	Signature	Date
Business Key User
IT/Migration Lead
Project Manager

Uptime Customizing for Finance Conversion (UCFC)/CustOnTmp

2025-10-06T23:40:26.528000+02:00

What is CustOnTmp : The downtime-optimized conversion (doC) executes the FIN data conversion on the temporary instance during the uptime. For this, SUM needs the FIN Customizing to apply it prior to the data conversion. Until now, this required a standard conversion run prior to each doC run. In this standard run, the FIN Customizing was created and added to a transport request. Such a transport request is required to be provided to each doC run.

With the new feature Uptime Customizing for Finance Conversion, FIN delta Customizing activities can be performed directly on the temporary instance of the doC run. With this, the number of required standard conversion runs is reduced to one standard conversion at the beginning of the project. All FIN delta Customizing activities can be directly done on the temporary instance of the doC run. For each new doC iteration, the initial FIN Customizing transport request is used (created in standard conversion) together with all the delta Customizing transport requests prepared with each new iteration. It is no longer required to always run a standard conversion before each doC cycle

Prerequisites

Target release SAP S/4HANA 2022 (or higher)
DOC with database migration (so no in place conversion; migration is possible also for source on SAP HANA)
SUM 2.0 SP 23 (or higher)

Differences Between Standard doC and Uptime Customizing

The uptime customizing will by default add most application tables to the uptime handling automatically. This means, the manual selection of tables for uptime migration becomes mostly obsolete. The SUM will no longer display the respective section on downtime-optimized DMO (with file specification "table list"). If there are still tables which cause a significant runtime during phase EU_CLONE_MIG_DT_RUN they can still be added manually using CRRTABLIST.LST as in regular doC approach.

Every application table in uptime handling gets either a replication trigger or a freeze trigger in the source system.

The reasons for a freeze trigger are:

Customizing table with delivery class C, E or G
Static classification in SUM which requires a read-only restriction

Freeze Trigger

Freeze triggers are needed to ensure the consistency of the uptime conversion. Freeze triggers are used in 3 different ways as below

Hard Freeze

Freeze triggers are used to prevent customizing changes in the source system which might influence and invalidate the uptime conversion which is done in parallel to production on the temporary instance. This means that the number of freeze tables is significantly higher as in regular doC approach, although it should not add additional business restrictions as most of the freeze triggers are defined on pure customizing table which are not changed directly in a productive system. Nevertheless, the Impact analysis is of a higher importance for the doC with Uptime Customizing for Finance Conversion approach. The hard freeze will be activated during the preparation in phase SQLDB_FREEZE_TRIG_MODE_SWITCH_SMIG_TCR and will remain until the end of the doC procedure.

Please refer the to SAP Note 2481983 - SUM Impact Analysis for downtime-optimized DMO

Temporary Freeze

Some tables only be set read-only for a short period of time, for example while the Asset Accounting is prepared for the Uptime Conversion.

Freeze on Temporary System

There will be freeze triggers used on the temporary instance between the SUM phases RUN_SMIG_SFIN_CUST_ON_TEMP_FREEZE and RUN_SMIG_SFIN_CUST_ON_TEMP_FREEZE_REV.

As tables must only be changed either by production operation (business users on system) on source system or by the customizing activities on the temporary system, all tables which can be changed by production operation will be set to read-only on the temporary system to avoid conflicting changes. It is, therefore, possible that a Customizing activity on the temporary instance fails with a short dump. In this case, create an incident on component BC-UPG-DTM-TLA to clarify the access.

Some tables can be changed on source system and temporary system. Additionally, it is ensured that this does not cause a conflict or there is a special handling implementation like for number ranges. For more information, refer to section 3.1 Number Ranges in this SAP Note.

Execution

During each doC execution, you must check in phase REQ_DOCMAX_DELTA_CUSTOMIZING that the provided FIN customizing that was added via CTI buffer is still valid.

doC with Uptime Customizing for Finance Conversion allows to add additional Customizing directly shortly before the uptime phase PARRUN_SMIG_SFIN. To do so, perform the following steps:

SUM will stop in dialog phase REQ_DOCMAX_DELTA_CUSTOMIZING.
Perform the IMG activities listed under "IMG/Conversion of Accounting to SAP S/4HANA / Preparations and Migration of Customizing" in each relevant client. Use transaction SPRO in the respective clients to perform the needed customizing steps.
Note: to identify if there are any delta customizing activities required, the customizing activities must be executed step by step (this information can't be provided by the tool).

Remark: The Customizing activities must be strictly restricted to the required Finance conversion Customizing. 3. Start the uptime FIN conversion by continuing SUM

Restricted tables for Uptime Handling

The following tables must not be added manually to uptime using CRRTABLIST.LST to avoid potential issues during Delta Customizing for the S/4HANA Finance Conversion.

BALHDR, BALDAT and BAL_INDX

Customizing on the Temporary Instance

Preparation of Number Range “RF_BELEG” for New Document Type for Postings in Controlling

When using the Uptime Customizing for Finance Conversion approach, the preparation of data migration requires a new document type for postings in Controlling that considers also a new number range object “RF_BELEG”.

Available options for Number Range Number definition for controlling document type:

In target system(S/4HANA):After SFIN Data Migration completion, before releasing the system to business users (the recommended one)
During S/4HANA Standard Customizing preparation with the inclusion into the FI customizing transport request of the CO number ranges numbers;

In source system (ECC): Before the start of S/4HANA technical activities

Preparations and Migration of Customizing for Controlling

Maintain Operating Concern (KEA0)” on the temporary instance is not possible due to read-only restriction on table TKES2 and CEFORMT. Execute “Maintain Operating Concern” only after SFIN delta migration is completed, as an after-migration activity, outside of SUM tool.

Restrictions

Depreciation calculation: Due to a read-only restriction on table T093D it is not allowed to run depreciation calculation when triggers are active in the system. This restriction only applies if table T093D is a logical pool table. If a mitigation is needed for this restriction you can get in contact with SUM development team raising an incident on BC-UPG-DTM-TLA.

Reference Notes:

3428570 - Executing and Monitoring Downtime-Optimized Conversion to SAP S/4HANA with Customizing on Temporary System

3388323 Executing and Monitoring Downtime-Optimized Conversion to SAP S/4HANA with SUM 2.0 SP 19

SAP S/4HANA Migration Cockpit – Migrate Directly from SAP – Increase flexibility using Split Logic

2025-10-08T01:00:00.044000+02:00

Hi all,

Have you ever wondered how to create multiple entries in a target parameter of the target API using just one source table entry? Have you ever had the requirement to migrate one material to multiple plants although the material is only available in one plant in your source SAP system?

With SAP S/4HANA 2025, a new feature is available for the S/4HANA Migration Cockpit called "Split Logic", which can be accessed using the Migration Object Modeler (transaction LTMOM). Note that this feature is only available for the migration approach "Migrate Data Directly from SAP System".

Usually, one entry is created in the target parameter for each assigned source table entry. Using the "Split Logic" feature, you can define a split for the source table to create multiple entries in the target parameter for each source table entry.

There are two types of split logic - simple split logic and advanced split logic. You can use simple split logic to create a fixed number of entries in the target parameter for each source table entry. Using the advanced split logic, you have a flexible way of defining the number of splits using rules.

You have then the possibility to define different field mapping information for each of the so-called "splits".

Some use cases for split logic include:

Creating multiple entries in the target parameter based on one source entry (for example if you want to create a material in multiple plants, whereas previously the material was only available in one plant in the source system)

Handling more complex migration requirements, for example if data in the source system is stored differently than in the target API.

We highly recommend reading our recently published SAP Note 3595079 for more information about this topic.

Let us know how you might use the split logic and feel free to comment below!

All the best for your project!

Philipp

Product Owner SAP S/4HANA Migration Cockpit Direct Transfer

Latest Features in the SAP S/4HANA Migration Cockpit, released with 2025 FPS0

2025-10-29T16:37:51.932000+01:00

Introducing the Latest Features in the SAP S/4HANA Migration Cockpit for SAP S/4HANA Cloud Private Edition and SAP S/4HANA

We're pleased to introduce the newest features in the SAP S/4HANA migration cockpit, released with SAP S/4HANA 2025 FPS0 and SAP S/4HANA Cloud Private Edition 2025 FPS0. These updates have been developed in direct response to customer feedback, aiming to elevate user experience and streamline migration processes.

New Staging and Direct Transfer Approach Features

Sequence Information View

A new feature is the Sequence Information View. This feature is designed to guide you in transferring data to your target system. It organizes migration objects in your project into a sequence for processing. This sequence is tailored to your specific project, depending on the migration objects you're working with.

By default, you'll see the Sequence Information View as your Start View, but you can easily switch back to the Standard View that you're used to.

Easier Access to Message Information

This improvement makes it simpler to navigate and access message-related information.

You can now easily trigger actions related to:

Preparation Messages (only available for direct transfer): Get Information into the messages generated during Prepare Mapping Tasks.
Simulation Messages: Quickly access relevant information to better understand the outcomes of your simulation tasks.
Migration Messages: Get direct insights into the messages generated during the migration process, helping to troubleshoot and optimize your activities.
Migration Results: Access detailed information on the results of migration tasks, ensuring you have all the necessary data for review your migration tasks.

These actions provide direct links to relevant message information, streamlining your navigation and increasing efficiency.

Server Group Assignment

This update offers you the ability to designate a specific application server or server group for your migration project, helping to ensure smooth operations without disrupting business activities.

To set this up, navigate go Job Management – Job Settings under the Option for Project. Here, you can select the application server or server group (if available) that best fits your needs.

Job Management

You now can adjust the number of background jobs assigned to specific migration objects, this offering a flexibility to streamline your data migration process according to your project's requirements.

To utilize this feature, go to Job Management under Jobs Used for Migration Objects, there you can see how many jobs are assigned to each migration object in your project.

Migration objects are categorized as following:

No Constraints: You can adjust the number of jobs assigned to the migration object.
Selection Process Only (1 Job for Simulation / Migration): Some objects, such as CO – Cost Center or CO – Profit Center, are limited to one job, so job adjustments aren't possible for them.
Staging Tables Not Prepared: Before adjusting job numbers, complete the Preparation step for these objects. (available for staging approach)
Status "Not Ready for Processing": If an object has this status, adjustments to job assignments are not possible

For Staging approach, you can find more details in SAP KBA 294684 - SAP S/4HANA Migration Cockpit: List of Migration objects that doesn't support parallel jobs

New Staging Features

Optimize Migration Performance

Migrating large volumes of data can be more efficient if you break it down into smaller packages. Once you've completed the "Prepare" step, you'll receive a recommendation on the number of jobs that can simultaneously handle a specific migration task. In the Job Management section, you have the flexibility to modify the number of background jobs dedicated to migration objects.

Efficient Error Handling When Uploading Template Files

The staging approach has been enhanced to display all sanity, duplicate, and consistency errors at once. This improvement means you no longer need to re-upload your file after each individual correction.

Any errors that arise during file upload are now provided in the template file, collected in the new “Messages” tab. In addition, a cell reference is available for each message which leads you directly to the error. After error correction, you need to delete the “Messages” tab and can upload the template file again.

See also following blog: SAP S/4HANA Migration cockpit: Easier Error Handling

Correction File After Simulation

After a simulation ends with errors, you now have the option to use the "Create Correction File" action. This feature generates a file containing the specific instances of data that encountered errors during simulation.

This makes it straightforward to edit the issue-prone data within the file and re-upload it to the staging tables, like the Correction file feature available after Migration.

Download Template File (LTMOM)

You now have the capability to download Migration Object Template Files as CSV files, not only in the SAP S/4HANA migration cockpit but also in SAP S/4HANA migration object Modeler (LTMOM).

New Direct Transfer (DT) Approach Features

Object Versions

The system will update the status of a migration object when a new version is available. While new versions of migration objects will contain new features or bug fixes, migration objects can also be deprecated or retired. The system will also update the status of such migration objects to inform you that they will be unavailable in future releases.

Define Split Logic (LTMOM)

To generate multiple entries in the target parameter for each entry in a source table, you can define a split. There are two types of split logic available to tailor this process to your needs:

Simple Split Logic
Advanced Split Logic

For more detailed information please see:

SAP Note: 3595079 Defining Split Logic - SAP S/4HANA Migration Object Modeler , especially the detailed guide attached
Blog from Philipp Kreutzheide: SAP S/4HANA Migration Cockpit – Migrate Directly from SAP – Increase flexibility using Split Logic

Event Based Rules (LTMOM)

Event-based rules offer the capability to execute ABAP code at specific point of processing. To set up an event-based rule, you need to map a source table to a target parameter. Moreover, the target parameter must be a table, or a structure of type Importing, Changing, or Tables.

Class Based Source Code Rules (LTMOM)

Class-based source code rules offer an advanced option for defining how source values are transformed to target values. By creating an ABAP class with your own logic, you can create a class-based source code rule that utilizes this class. Additionally, these rules allow you to directly call other rules within the source code.

Utilizing Where Conditions Editor (LTMOM)

The WHERE Conditions Editor enables you to define additional selection criteria across all fields in a table using Open SQL statements. You can use AND and OR operations to build simple or complex conditions. You can leverage all ABAP Dictionary data types, with the exception of STRING, RAWSTRING, LCHR, and LRAW.

More details you can find in SAP KBA 3249988 - Details on selection process - SAP S/4HANA Migration Cockpit - Direct Transfer

Instance Field List (LTMOM)

You can define how migration object instance is displayed in the SAP S/4HANA migration cockpit. They are available under Instance List Settings button on the detailed screen for your root table.)

New Migration Objects

For details on the new migration objects, please check:

SAP S/4HANA migration cockpit: Adapt the XML file to your business needs

2025-11-04T11:52:00.356000+01:00

When using the staging approach for your data migration, you often face the challenge that the provided XML file contains sheets and columns within the sheets that are not relevant for your business needs.

Did you know that it is possible to adjust the XML files easily?

However, before I go to the possible options, note that you must be careful when deleting, as any change can corrupt the XML structure. There is also no guarantee that such a tailored XML file can still be used after upgrading to a higher release.

After creating a migration project in the SAP S/4HANA migration cockpit using the Migrate Your Data app select Download Template in Action for a specific migration object and choose File Type → XML file.

Note

The description below is for Microsoft Excel. The procedure may differ when using another spreadsheet program than Microsoft Excel.

Option 1: Delete a non-mandatory sheet

Open the downloaded file and choose Enable Editing button. Select a non-mandatory sheet you want to delete – choose the context menu by clicking on your mouse and choose "Delete".

Confirm on the follow up pop-up you want to delete.

Proceed in this way with all the non-mandatory sheets that you want to delete.

Note

You can only delete non-mandatory sheets and delete sheets even though the worksheet contains mandatory columns. This is because there is no need to fill the mandatory columns in the sheet with data if the sheet itself is not relevant for your project.

Option 2: Delete a non-mandatory column within a sheet

First, you need to unprotect the sheet. So, you need to select a sheet where you want to delete one column or more columns – choose the context menu by clicking right on your mouse and select “Unprotect Sheet”.

Select the column(s) you want to delete – in my example all columns for Tax Calculation Brazil. Choose "Delete".

Note

Alternatively, you can go to File → Info → Protect Workbook area and click on Unprotect for the sheets you want to make changes on.

Save your changes. You can now fill your XML file as usual and load the data into the SAP S/4HANA migration cockpit.

When you upload your data, the tool informs you that the Validation Completed with Warnings.

To be able to view the messages, choose "Show Messages" you get a list of all messages occurred during Validation.

In this case, warnings are displayed because the fields deleted in the previous steps are missing from the sheet.

To load the data into the SAP S/4HANA migration cockpit select your file and transfer the data via Actions → Transfer Data to Staging Tables.

The instances will be loaded into the SAP S/4HANA migration cockpit staging tables.

You can now proceed with your data migration steps as usual.

Using CSV files

Like the XML file, you can easily tailor your CSV files as you only need to use the files for the structures and fields you want to process. Just provide the files for mandatory structures and the structures you need. Within the files you must also only provide the mandatory fields and the fields you need. All the other fields you can remove. A CSV file has much less administrative data than an XML file. The 100 MB limit is the same, but with tailored CSV files the http-protocol related size limit is not reached that fast as using XML files.

The New Explore Migration Objects App, The Game Changer in Planning Your Data Migration

2025-12-10T09:31:39.708000+01:00

A Short Trip to History

Since people have been performing data migrations into different systems, they have wanted to know the dependencies between the various data they need to migrate. They usually create project plans, PowerPoint presentations, or use tools like Visio to make these dependencies visible. As the saying goes, a picture is worth a thousand words. Since SAP began delivering preconfigured data migration objects, initially as a Rapid Deployment Solution for SAP ECC, later for SAP S/4HANA, and then as migration objects for the SAP S/4HANA Migration Cockpit, customers have repeatedly asked for an overview diagram of the dependencies of these objects.

Initially, when the number of migration objects was manageable, there was an attempt to create an overview diagram in Visio. The interim result, shown in Figure 1, reflects only a portion of the objects present at that time. Each additional object made the diagram increasingly confusing.

Paper Draft

Figure 1, Paper Draft

The data initially resembled a sewing machine pattern or the London Tube Map, making it unusable.

Since the data was already in the system, the dependencies of a migration object were listed in the SAP Help Portal documentation. Customers could view them there. Later, this information was also included in the overview list of "Available Migration Objects."

There have always been efforts to provide customers with an interactive map. Initially, we considered displaying it on a web page using Python's network graph tool. However, this approach failed due to technical, hosting, and maintenance problems.

The Tile of Happiness

After a long wait filled with much effort, numerous usability tests with internal and external consultants, and feedback from customers, we are proud to present the first version of the Explore Migration Objects app. Internally, we refer to it as the EMO app.

The idea to use the SAP Fiori Network Graph and offer it in an easy-to-use app was a decisive turning moment. We began with an initial draft version and conducted several usability tests to determine users' needs and the desired design. Based on the test results, we finalized the app and delivered it through CFD and a feature toggle in SAP S/4HANA Cloud Public Edition 2508.3. In SAP S/4HANA Cloud Public Edition 2602, the app is available without a feature toggle.

Spoiler: In the near future, users may choose between an "empty" tile and a tile that shows the number of available migration objects delivered by SAP within the current release.

Figure 2, The Tiles

How does the app support data migration?

The app assists you with planning your data migrations. It provides a graphical overview of data migration objects and their mandatory or optional predecessor objects. This offers a complete view of the entire data migration scope or individual subareas. You can quickly identify necessary dependent predecessor migration objects. Additionally, you can navigate from each migration object to its documentation on the SAP Help Portal. This makes it easier and faster to familiarize yourself with the details of a migration object.

It helps you plan your data migration scope and the sequence to extract and load your data. You can also determine data migration objects by entering a scope item (business process) to see which migration objects are assigned to it. This helps you check if your planned scope covers all data migration objects or identify which objects might be relevant.

The app is continually enhanced with new functionality in future releases. However, as data migrations in SAP S/4HANA and Private Cloud are not assigned to scope items, this functionality is not supported in those product versions.

For which product and release is the version available, and how do you activate it?

The Explore Migration Objects app (F8638) is available with SAP S/4HANA versions 2508.3 and 2508.4. To activate it, enable the feature Enable new app for Explore Migration objects (CFND_DMCC_NEW_APP_EXPLORE_01).

For more details on activating apps through features, please refer to the What's New Document on the SAP Help Portal

With SAP S/4HANA Cloud Public Edition 2602, the app is generally available in the data migration group without needing activation. For SAP S/4HANA and Private Cloud, the app is available with SAP S/4HANA 2025FPS1. However, for SAP S/4HANA 2023 or earlier releases, the app is not available. These products are already in the support package phase, and new features and apps may only be delivered during the feature pack phase.

What authorization do I need?

If you already have authorization for the SAP S/4HANA migration cockpit, you can use this app too.

Which approaches are supported?

The first version of the app currently supports only the migration objects built for the Staging Tables approach. Support for the Direct Transfer approach (DT) is planned for later versions as the framework for that approach is enhanced with additional functionality.

Where can I find the app?

The app is assigned to the Data Migration page. Especially during the controlled feature delivery phase in version 2508.4, you may need to search for the app by its name and assign it to your page manually.

Data Migration GroupFigure 3, Data Migration Group

How do I use the app?

Selecting the data

The app is structured like most SAP Fiori apps: it includes a selection area and a result area. The selection area displays three different selection fields:

A "Search" field where you can enter a freely defined search string.
A "Migration Object" field where you can enter or select one or more migration objects.
A "Scope Item" field where you can select one or more scope items.

Selection area

Figure 4, Selection area

The results area shows the results of your selection based on the selection field where you entered your search term. It is divided into one area by two tab bars to display migration objects and scope items in a table. When you enter a search string into the search field, the system returns all migration objects and scope items that contain that search string.

Some Example

For example, if you enter "Asset" into the search field, it returns all migration objects containing that search string. When you enter or select a value in the “Migration Object” field, a proposal list first appears. You can then select values from this list.

Result area, Migration Objects Tab
Figure 5, Result area, Migration Objects Tab

You can also use the value help to search and select one or multiple objects.

Migration Objects Field, Value Help

Figure 6, Migration Objects Field, Value Help

If you select the "Go" button or press the Enter key, the system displays the result. This result differs from what you obtain through the search field. Searching with the "Migration Object" field provides relevant migration objects…

Result area, Migration Objects Tab

Figure 7, Result area, Migration Objects Tab

…and the scope items to which these objects are assigned.

Result area, Scope Items Tab

Figure 8, Result area, Scope Items Tab

When you search using the "Scope Item" field, the "Migration Objects" tab lists all migration objects assigned to these scope items. You can find the related scope items on the "Scope Items" tab.

You can combine the "Search" field with either the “Migration Object” field or the “Scope Item” field. However, do not use the “Migration Object” field and the “Scope Item” field together. The search results vary based on which of the three search fields you complete.

Now, let's focus on the most important aspect: what you can actually do with it in the app.

The graphical overview for migration objects

Search for the Migration Object "Material BOM", and select it from the result list. The selection view changes to display the “Migration Object” view. The migration object "Material BOM" and its alias (BOM_3) appear in the title section. The migration object and its dependent predecessor objects are shown as nodes within a network diagram. Each object appears as a blue node within a group that indicates the migration domain to which the migration object belongs. "Material BOM" is assigned to a domain called "Basic Data." The domain name is derived from the application component description to which the object belongs. You can see the alias and the technical name of the component within the blue node. The alias is a technical construct that is part of the technical name of a data migration object. Knowing the alias name of a migration object can be very useful.

Network GraphFigure 9, Network Graph

Connectors illustrate the relationships between migration objects. Upon closer inspection, you'll notice different types of connectors linking the objects. Dashed gray lines represent connections to optional predecessor migration objects. Solid orange lines indicate mandatory predecessor objects, such as "Product" in the example shown.

Network Graph Connectors

Figure 10, Network Graph Connectors

Functions

The toolbar displays various fields and functions. It includes a search field where users can enter a string to find an object in larger network diagrams and navigate to that object.

Initially, the direction of the objects runs from left to right. This means the root object is on the left side, and all others are arranged to the right. Use the “Transpose” button to change the direction from left-right to top-bottom. This can sometimes make it easier to get an overview of larger diagrams or take a better screenshot.

Next to the “Transpose” button is the “Legend” button, which displays the legend. Next to it, you can find the zoom buttons. You can either zoom in or zoom out. Between the two buttons, the zoom factor is displayed as a percentage. Next to the zoom area is the "Zoom to Fit" button. It zooms the diagram so that all nodes are displayed on the screen.

ToolbarFigure 11, Toolbar

The "Enter to Full Screen" button displays the diagram in a separate window. In some browsers with built-in screenshot functionality, such as Microsoft Edge or Firefox, it's sometimes useful to switch to full screen before taking a screenshot.

Directly to the right of the toolbar, you'll find the graph overview. Some users may already be familiar with this feature from other applications or the ABAP Dictionary transaction SE11. In SE11, you could display a graphical overview of tables and their dependencies, where it was called the navigation area. The graph overview helps prevent losing track in very large network diagrams. It always shows the complete network diagram in a small window. A small blue window within the graph overview indicates the current section of the diagram displayed on the screen. You can move the blue window to the section you want to display.

Graph OverviewFigure 12, Graph Overview

Interactions on a node

Clicking on a node opens a menu. This menu offers options to expand or collapse the predecessor structure of the migration objects or to display the links popover.

Interactions on a node

Figure 13, Interactions on a node

In the links popover, accessible through the "Node Links" icon , you find the direct link to the documentation of the migration object on SAP Help Portal. Future versions may also include links to available sample data for the migration object. These samples are already provided on the SAP Help Portal.

Documentation LinksFigure 14, Documentation Links

Similar to a node, you can also collapse or expand a group. When collapsed, the group displays only its name.

Collapse Group
Figure 15, Collapse Group

You can use the Group Details icon to view all migration objects assigned to a collapsed group. If the main object is in a collapsed group, a home icon appears in front of its name.

Group Details IconFigure 16, Group Details Icon

Clicking on a connector or the area surrounding it calls up the connector's detail popover.

Connector's detail popoverFigure 17, Connector's detail popover

You can expand each migration object that has a predecessor object to display these predecessor objects. Simply click the "Expand Migration Objects" icon .

Figure 18, Expand Migration Objects

The graphical overview for scope items

In this example, we use "Asset" as the search term for the scope items, then select “1IH” – "Intercompany Asset Transfer Within Same Country". The functionality of the "Scope Items" view matches that of the view for migration objects. The scope item node appears as a circular shape. Each migration object connects to the scope item in the first release of the app with a solid orange line. In future versions, this solid line changes to a dashed gray line to clarify that such objects aren't mandatory for a scope item.

Network graph Scope ItemFigure 19, Network graph Scope Item

More to Come: A Short Outlook on Ideas

Several additional features are planned or under discussion. One example is an option to display either all available objects delivered by SAP with a release or only the activated migration objects. The latter option shows the same objects that customers see when selecting an object within the migration cockpit. Migration objects assigned to a non-standard scope item that is not activated will not be shown. The same applies to migration objects available only if a business function, such as retail-related objects, is activated.

There are also discussions about displaying the migration object type, indicating whether it is a master data or transaction data object. Additionally, there are plans to show whether a migration object supports key user extensibility.

Once the Direct Transfer approach framework expands to support the EMO app, these migration objects and their dependencies are expected to be available with the app.

Since almost all usability testers saw no need for a download or print function, such a function is not currently planned. Instead, you can use the integrated screenshot functionality provided in several web browsers, such as Firefox and Edge on Microsoft Windows and Apple macOS.

Outlook on SAP S/4HANA and SAP S/4HANA Private Cloud

The EMO app is available with SAP S/4HANA 2025 FPS1. It offers almost the same functionality as the SAP S/4HANA Cloud Public Edition 2508.3/2602 app. However, the scope item functionality isn't available for SAP S/4HANA because migration objects within SAP S/4HANA aren't assigned to scope items. Functions provided within SAP S/4HANA Cloud Public Edition CFD or main releases are likely added to SAP S/4HANA FPS2 and FPS3.

Feel free to share your opinions about the app in the comments section of this blog. You can also suggest new functions and features you might be missing.

P.S. My personal kudo goes to @vishnuvardhantanguturu, Miller Li, Zak Zhang, and @Martina_H, my colleagues in development and product management that worked hard in the last 9 months to deliver the baby in time. Special Thanks also to Joshua Sturm, for checking the blog text before delivery.

🚀 Cloud ERP: SAP S/4HANA migration cockpit updates

2025-12-22T13:58:41.073000+01:00

Following our popular YouTube session on migration cockpit fundamentals (watch here), we are back with the latest updates from release 2408 onwards!

We will cover functionality updates for both staging tables and direct transfer approaches, plus share the list of new migration objects that have been added recently.

📅January 13, 2026, 02:00 - 03:00 PM (CET)
🔗Register Here

This session is part of "Move to a Cloud" webcast series.

🎯Cloud ERP Private: SAP S/4HANA migration cockpit updates

2025-12-22T14:36:02.097000+01:00

Following our popular YouTube session on migration cockpit fundamentals (watch here), we are back with the latest updates from release 2023 FPS2 onwards!

We will cover functionality updates for both staging tables and direct transfer approaches, plus share the list of new migration objects that have been added recently.

🕖January 20, 2026, 02:00 - 03:00 PM (CET)
🔗 Register Here

This session is part of "Move to a Cloud" webcast series.

浏览迁移对象App——你也能成为数据迁移专家

2026-01-07T03:56:06.338000+01:00

除了迁移范围，还有迁移顺序

在Cloud ERP里，数据迁移是每个客户、每个项目都会用到的部分。从最早的十几个迁移对象，到现在超过200个迁移对象。我们除了需要定义迁移范围（需要用到哪些迁移对象，因为不可能每个迁移对象都会用到），另外一个非常重要的是需要知道迁移顺序。也就是你所有准备导入的迁移对象里，哪一个先导入，哪一个后导入。在每一次做数据迁移的时候，都需要规划好迁移顺序。虽然在SAP Help Portal的迁移对象页面上，能查到每个迁移对象的前序依赖对象，比如销售订单，你能看到以下迁移对象是它的前序对象，其中客户和产品这两个迁移对象是必须的，其他为可选的。但是文字的方式总不是特别方便。很多客户提出过希望有一个可以图形化查看迁移对象依赖关系的地方……

千呼万唤始出来

终于，从2508.3版本开始，我们推出了数据迁移下面一个全新的应用“浏览迁移对象”，能够让我们可以图形化的方式来展示迁移对象之间的依赖关系，可以显示迁移对象的必须或可选的前序对象。

这个应用的权限信息如下：

业务目录：SAP_CA_BC_MIG_PC

默认的业务角色：SAP_BR_CONFIG_EXPERT_DATA_MIG

深入浅出“浏览迁移对象”

当你打开应用“浏览迁移对象”，你会看到下面这样一个界面。可以有两种方式来显示迁移对象的依赖关系：

在所有当前可用的迁移对象里，选择某个迁移对象，来显示它的前序对象。
因为我们的功能是按照范围项目（Scope item）来划分的，有时候我们想知道某个范围项目牵涉到哪些迁移对象。所以你也可以选择某个范围项目，来显示跟这个范围项目相关的迁移对象。

根据迁移对象查看

比如，选择迁移对象“客户 - 按新组织级别扩展现有记录”（CUST_EXT_3），你会看到以下这个界面：

你选择的迁移对象会显示在最左边，它的前序依赖对象在它的右边。

你能看到有两种不同的线，橙色的实线代表这个前序对象是必须的，也就是如果你要导入“客户 - 按新组织级别扩展现有记录”，你必须先导入“客户”这个迁移对象。灰色的虚线代表是可选的前序对象。在这个例子里，“FI-CA 合同合作伙伴”、“银行”和“供应商”是3个可选的前序迁移对象。

在上方，你能看到一条菜单栏如下：

点击Transpose按钮，你可以把图形在横向展示和竖向展示之间切换。不同的情况可能不同的展示方式更为方便，或者方便你截图：

菜单上也可以点击显示图例：

以及缩放和全屏显示的按钮。

当然，这个应用绝不是这些功能这么简单！

如果你点击某个节点，在这个节点的右方，会出现几个节点按钮：

你可以选择折叠或展开与该节点相关的其他节点，也可以快速跳转到这个迁移对象的详细文档页面。你也可以点击某个节点，来展示与它相关的前序迁移对象。

根据范围项目来查看

你也可以根据范围项目来查看与它相关的迁移对象。例如，你选择BLF（批次管理），你会得到以下这个界面：

这就展示了如果需要使用BLF批次管理，那么这些迁移对象需要考虑做导入。这个功能也方便了我们的功能顾问来规划迁移范围，不会遗漏应该需要导入的数据。

同样的，我也可以点击上面的任何节点，来展示它是否还有前序对象。比如我选择“类”这个对象，显示依赖关系，我会得到以下的界面：

你可以看到，类这个迁移对象，它有两个可选的前序对象。

未来功能的展望

对于这个新应用，还是会有一些新的功能点在未来会被支持。比如，不是显示所有的迁移对象，而是显示在这个系统中被激活的迁移对象可能会更合适。

另外，显示迁移对象的类型，主数据或者交易数据，这也会是一个经常会用到的过滤点。也有计划会展示迁移对象是否支持关键用户扩展。

如果你想要了解更详细的关于浏览迁移对象（Explore Migration Objects）的介绍，你也可以看一下我们的数据迁移专家Frank Finkbohner的博文：The New Explore Migration Objects App, The Game Ch... - SAP Community

最后，希望你会喜欢这个数据迁移的新应用。如果你有任何问题，欢迎留言！

Mapping Stock to New Nested Handling Units Using Migration Cockpit in SAP S/4HANA Public Cloud

2026-01-14T13:13:07.522000+01:00

Mapping Stock to New Nested Handling Units Using Migration Cockpit in SAP S/4HANA Public Cloud

Step 1: Go to the ‘Migrate Your Data’ tile and create a project by selecting the ‘HUM – Handling Unit’ object.

Img:1

Img:2

Img:3

Img:4

Step 2: Once the project is created, select the project and download the migration template.

Step 3: Fill in the required data in the tabs of the template. The detailed steps are provided below.

Tab 1: Bundles for Nested HUs

Maintain a Run ID when creating Nested HUs for a material.
The Run ID is used to group multiple Handling Units into a single Nested HU structure.

Example: If a carton containing material is packed together with other cartons onto a pallet, the cartons (inner HUs) and the pallet (outer HU) together form a Nested Handling Unit structure and must share the same Run ID (Bundle ID).

Tab 2: Header Data

Since an external number range is maintained in the backend configuration for HU packing types, the External HU ID is filled for the respective packing materials, Plant details.

Tab 3: Item Data

Maintain the material against the respective HU ID and enter the quantity to be migrated into the new Handling Units.

Scenario example used in this document:

At Pallet HU level, the Carton Box HU is assigned.
At Carton Box HU level, the Small Box HU is assigned.
At the Small Box HU level, the material “42 – SFG Material” is maintained with a quantity of 15 KG.

When this data is uploaded, the system:

Automatically assigns the stock to the respective HUs, and Creates the complete Nested HU structure, finally resulting in the Pallet HU containing all lower-level HUs.

Step 4: Upload File and Mapping Task

Upload the completed data template.

Step 5: Simulate

Step 6: Migrate

Finally, migration completed, the system creates the Handling Units (HUs) and assigns them to the existing stock for the material.

Check Stock: Display Stock Overview

The below screenshot confirms successful creation of Nested HUs, with stock correctly assigned from Small Box → Carton Box → Pallet HU.

Using Migration Cockpit, we successfully mapped existing stock into a nested HU structure, enabling accurate HU tracking and improved stock visibility in SAP S/4HANA Public Cloud.

SAP S/4HANA Migration Cockpit – Migrate Directly from SAP System – The Transfer List

2026-01-21T11:54:10.890000+01:00

Hi all,

The migration approach Migrate Data Directly from SAP System uses APIs to write data to the SAP S/4HANA target system.

The source data is passed to the parameters of the target API, and the API uses that data to create data in the target SAP S/4HANA system. However, this data can be first modified by field mapping rules (such as mapping rules or source code rules).

Until now, it was not possible to view the exact data that the API uses to create data in the target SAP S/4HANA system.

In the Migrate Your Data app, you can now use the transfer list to view the data that the target API uses to create data in SAP S/4HANA, including the results of all used mapping rules.

Viewing the transfer list can be beneficial if you want to troubleshoot the simulation or migration process. For example, you can analyze the transfer list to determine whether an issue occurs with the target API or if it is a structure or field mapping issue.

Where can I find the transfer list?

The transfer list is available with SAP S/4HANA Public Cloud Edition 2602 and SAP S/4HANA Private Cloud Edition 2025 FPS1.

In the Migrate Your Data app, navigate to the Migration Object Instances screen, select the relevant migration object instance and then choose the Transfer List button.

Note that this feature is only available for the migration approach Migrate Data Directly from SAP System.

Once the simulation process or migration process is complete for a migration object instance, you can view the transfer list for that instance. If a migration object has multiple transfer steps, a transfer list will be available for each processed step.

Example

On the Transfer List screen, you can see instance ZRH0000011 for the migration object Customer. This migration object has four transfer steps. The first step CMD_MIG_BP_CVI_CREATE has been simulated successfully for the instance. This means that the transfer list is available for this step. On the left-hand side of the screen, you can view detailed information about the import parameters of step API CMD_MIG_BP_CVI_CREATE.

If you select an import parameter, the system displays the input data for the parameter on the right-hand side of the screen.

You can use this information, for example, to determine whether an issue occurs with the target API or if it is a structure or field mapping issue.

We are happy to hear your feedback!

All the best for your project!

Philipp

SAP S/4HANA Migration Cockpit – Migrate Data Directly from SAP System – Using Staging Tables

2026-02-09T15:25:52.977000+01:00

Hi all, 

Over the past few months, our customers have asked us whether there is any way to get more transparency on the selected data for the migration approach Migrate Data Directly from SAP System. Customers have also asked whether there are any opportunities to adjust the selected data based on their requirements.

The selection process for migration approach Migrate Data Directly from SAP System is very complex. This made it difficult to adjust or even view the selected data in the Migrate Your Data app.

However, with SAP S/4HANA Public Cloud Edition CE2602 and SAP S/4HANA Private Cloud Edition OP2025 FPS1 release, we are happy to announce our new feature Staging Tables as Intermediate Storage for Direct Transfer. 

Most of you are familiar with the selection process of migration approach Migrate Data Directly from SAP System. For SAP S/4HANA and SAP S/4HANA Cloud Private Edition, an RFC connection is used to connect to the source system. For SAP S/4HANA Cloud Public Edition, a communication arrangement for communication scenario SAP_COM_0816 is used. 

Figure 1: Selection Process without Staging Tables 

Why use staging tables as intermediate storage?

With this new feature, the Migrate Your Data app can create staging tables for the migration approach Migrate Data Directly from SAP System in a remote SAP HANA schema and can store the selected data there. You can then adjust the values directly in the relevant database tables before continuing with the migration process. This option provides increased transparency for the selected data, as well as providing the opportunity to adjust data directly in the relevant database tables if required.

Figure 2: Selection Process with Staging Tables 

You activate this feature when creating a migration project. During step 3, Staging Tables (Optional), you activate the feature and specify the relevant connection to the remote SAP HANA schema in the Database Connection field.

You then need to activate staging tables for the relevant migration objects.

Note that using staging tables is completely optional!

When using staging tables as intermediate storage, the selection process is divided into two steps. In the first step, the relevant data is extracted from the ECC system to the staging tables. This step is triggered in the Migrate Your Data app using the action Extract to Staging Tables.

In the second step the data is transferred from the staging table to the Migrate Your Data app. Again, this step is triggered in the Migrate Your Data app, this time using the action Transfer from Staging Tables.

Once you have extracted data to the staging tables, you can not only view the data as a whole in the remote SAP HANA schema, but you can also adjust the data according to your requirements. That gives you more flexibility in preparing the data for the migration.  

Figure 3: Contents of staging table 

Note that the staging tables for the migration approach Migrate Data Directly from SAP System cannot be used with the staging tables for the approach Migrate Data Using Staging Tables. The staging tables for the migration approach Migrate Data Using Staging tables are based on the template files for a migration object provided by SAP. The staging tables for the migration approach Migrate Data Directly from SAP System are based on the data model of the migration objects.

Let us know how you might use the staging tables for the migration approach Migrate Data Directly from SAP System and feel free to comment below!  

All the best for your project! 

Philipp

Migration Cockpit in SAP Cloud ERP 2602

2026-02-10T11:30:54.985000+01:00

I am a product expert for SAP S/4HANA Cloud. I am delighted to share some exciting innovations from our latest SAP S/4HANA Cloud Public Edition 2602 release. This update brings significant enhancements to the SAP S/4HANA Migration Cockpit, designed to make your data migration projects smoother, more transparent, and more efficient. These new features are particularly relevant for data migration experts, project managers, and business teams guiding their organizations through the transition to our intelligent cloud ERP.

SAP Cloud ERP is part of SAP Business Suite that brings AI, data, and applications together into a fully integrated system. This community is open for anyone in the cloud ERP ecosystem–customers, partners, and SAP experts.

Migration Cockpit Release 2602 enhances data migration by enabling deeper exploration of migration objects, leveraging staging tables as structured intermediate storage, and introducing transfer lists for better control and transparency during data loads. With increased file size limits, it ensures faster, more efficient handling of large data volumes—reducing complexity, improving reliability, and accelerating system transition projects.

Migration Cockpit

Explore Migration Cockpit
Using Staging Tables as Intermediate Storage
Transfer List
Increased File Size Limits for an Efficient Data Load

Explore Migration Objects: A New SAP Fiori App for Enhanced Project Planning

A successful data migration relies on meticulous planning and a deep understanding of data dependencies. With the 2602 release, we are introducing the SAP Fiori app, "Explore Migration Objects," to bring a new level of clarity to your project preparation.

This app provides crucial insights into migration object dependencies and their relationships to specific scope items. It empowers your project team to efficiently plan data migration projects by ensuring that all mandatory and optional predecessor objects are correctly identified and migrated in the proper sequence. Through interactive graphs, you can now visualize how migration objects are interconnected. The app allows for detailed dependency analysis, differentiating between mandatory and optional predecessors, and provides focused search and direct access to migration object documentation. By visualizing these relationships, your team can make informed decisions, ultimately reducing project risks and optimizing timelines. Please note that this initial version of the app currently supports migration objects built for the "Migrate Data Using Staging Tables" approach.

Enhanced Flexibility with Staging Tables for Direct System Migration

For customers using the "Migrate Data Directly from SAP System" approach, the 2602 release introduces a powerful new capability: the use of staging tables as intermediate storage. This feature is designed to facilitate the adjustment of selected data before it is loaded into SAP S/4HANA Cloud Public Edition.

This enhancement significantly increases transparency and provides robust validation capabilities for your selected data. It gives your team more flexibility to adjust and cleanse application data from the source SAP system before the Now, data adaptation is performed within ETL tool prior to loading the data into the migration cockpit’s staging tables. Once the data is prepared and validated, you can transfer the ready-for-processing data to the SAP S/4HANA Migration Cockpit for further processing, ensuring higher data quality in your new cloud environment.

Check the blog written by Philipp Kreutzheide

Streamline Your Migration Troubleshooting with the New Transfer List

Transfer List

In any complex data migration project, ensuring data is transferred accurately is paramount. When issues arise during the simulation or migration phases, pinpointing the root cause can be time-consuming. To bring greater transparency to this process, we are introducing the Transfer List for the migration approach "Migrate Data Directly from SAP System." This feature is designed for data migration specialists and project teams who need deep visibility into the data transfer process for effective and efficient troubleshooting.

A Clear View for Faster Resolution

The Transfer List provides a detailed view of the data exactly as it is passed to the target API that creates the records in SAP S/4HANA Cloud Public Edition.
This capability is particularly beneficial when you need to troubleshoot the simulation or migration process. For example, your team can now analyze the Transfer List to definitively determine whether an issue lies with the target API itself or if it is related to a problem in the structure or field mapping. This clarity helps you isolate problems faster, reduce resolution time, and keep your migration project on track.

To use this feature, the simulation or migration process must first be completed for the relevant migration object instance. Once complete, you can access the Transfer List with the following steps:

1. From the Migration Project screen, select the "Instances" link for your object.
2. On the Migration Object Instances screen, select the instance you wish to investigate.
3. Choose the "Transfer List" button.

On the subsequent screen, you can view the target parameters, fields, and their corresponding values that were used in the transfer, providing your team with the precise information needed for analysis. This enhancement empowers you to resolve issues with confidence and precision, ensuring a smoother transition to SAP S/4HANA Cloud.

Check the blog written by Philipp Kreutzheide

Increased File Size Limits for an Efficient Data Load

To further streamline your data migration activities, we have increased the file size limits for the "Migrate Data Using Staging Tables" approach. This practical update allows for more efficient handling of large data volumes.

When you upload your data using XML files, you can bundle multiple files into a single zip file for a more convenient upload. With this release, the maximum size for each individual XML file contained within the zip file has been increased to 400MB. This allows you to process larger data sets in a single file. Please be aware that while individual files can be larger, the total size of the zip file itself should not exceed 100MB upon upload to the migration cockpit. This improvement simplifies the data loading process and reduces the number of uploads required for extensive data sets.

I hope you're as excited about these updates as I am! To learn more, I encourage you to explore the SAP Help Portal and join the conversation on the SAP Community.

What is New?

Check Migration Cockpit Community

SAP Help Data Migration

SAP Community YouTube presented by Claudia Gemm and Elizaveta Kozhevenikova

📽️ Watch the replays of our SAP Cloud ERP 2602 Early Release Series!

From January 12-16, we hosted a series of 22 expert-led live sessions to highlight the exciting innovations shipped with the SAP Cloud ERP 2602 release. Missed the live sessions? We've got you covered! Take advantage of the entire series or pick and choose the sessions most relevant to you. You will find the recording and presentation for Migration Cockpit as well as 21 other topics of interest. Don't miss this chance and watch them on demand–anywhere, anytime.

🔎 Find all our assets

We at Cloud ERP and SCM Product Success offer a service as versatile as our product itself. Check out the numerous offerings our team has created for you below:

How to Add a Field to a Migration Object in SAP Cloud ERP (SAP S/4HANA Cloud Public Edition)

2026-02-10T12:59:11.848000+01:00

Migrating data to SAP S/4HANA Cloud sometimes requires adapting standard migration objects to fit your business needs. You might need to add a field to the XML or CSV template files for the SAP S/4HANA migration cockpit that isn’t included by default. The App "Model your migration" (SAP S/4HANA Migration Object Modeler) makes this possible—here’s a step-by-step guide using the supplier object as an example.

❗This blog is only relevant, if you use the approach "Migrate Data Using Staging Tables".

Prerequisites

Access to the SAP Fiori app “Model Your Migration Objects”
The required role: SAP_BR_ADMINISTRATOR
You are using the approach "Migrate Data Using Staging Tables"
Check that the field you want to add is released for use (see the relevant SAP Note, e.g., SAP Note 3019787 for Supplier). In this example we will add field CONTACTALLOWANCECTRCENBP to the migration object Supplier.
Collective Note for all supported migration objects SAP Note 2999428

Step-by-Step Guide: Adding a New Field to the Supplier Migration Object

Example: add field CONTACTALLOWANCECTRCENBP to the migration object Supplier.

1. Open the Migration Object Modeler App

Launch the SAP Fiori app “Model Your Migration Objects” and enter your migration project.

When you open the app for the first time you get the information, that in this app it is only possible to view migration projects and objects, which use the approach "Migrate Data Using Staging Tables". To view migration projects and migration objects that use the migration approach "Migrate Data Directly from SAP system", use the "Implementation Activities" app to access the SAP S/4HANA migration object modeler.

2. Locate the Supplier Migration Object

Expand the migration objects node to view all objects. Double-click “Supplier” to open it.

3. Display Source Structures

Double-click “Source Structures.” If technical names aren’t visible, go to Settings and enable them.

4. Switch to Edit Mode

Change to Edit mode to allow modifications.

5. Add the New Field

Select the relevant source structure and click “Add Field.” Enter the details for your new field (e.g., ZZ_NEW_FIELD). The system flags it as a custom field. In our example we want to add a the field CONTACTALLOWANCECTRCENBP to the migration object Supplier.

6. Save Your Changes

Save your entries. Use the “Full Screen on/off” button to toggle the view if needed.

7. Map the New Field

Double-click “Field Mapping” (ensure you’re still in Edit mode). Search for your new field in the source structure and the corresponding target field (e.g., CONTACTALLOWANCECTRCENBP). Drag your new field to the target field, or right-click and choose “Assign Rule.”

8. Verify and Save the Mapping

Double-check that the mapping is correct and save your changes.

9. Synchronize Structures

Synchronize the structures to apply your changes. Confirm any pop-ups and exit the application.

10. Validate in SAP S/4HANA Migration Cockpit

Go back to “Migrate Your Data – migration cockpit.” Check your project and review the staging tables. If the table status is “Adjustment Required,” select the table and click “Adjust Structure.” If you have already done this step in the Model your Migration App, the status should be "OK".

11. Find the Field in the Template

The newly added field will now be visible in the XML template file for the migration object.

Additional Tips

Resetting Objects: You can reset a migration object to its original template version if needed. This removes all custom changes.
Updating Objects: SAP may update migration objects periodically. If prompted, update the object to ensure compatibility.
Favorites: Add frequently used projects or objects to your favorites for quick access (up to 10 each).

References

Best regards,

Kirstin

SAP Community - SAP S/4HANA migration cockpit

Data Migration Cockpit in SAP S/4HANA public cloud.

Step-by-Step Guide to Data Migration Cockpit in SAP S/4HANA Public Cloud

What is the Data Migration Cockpit?

Steps to Perform Data Migration in SAP S/4HANA Public Cloud

Step 1: Access the Data Migration App

Important Details Before Starting Your Migration Project

Mapping Task

Data Migration in SAP : The 5W Strategy for SAP Data Migration

SAP S/4HANA Migration cockpit: Easier Error Handling

How to perform a successful Carve-Out in SAP ECC and S/4HANA – Update and New Trends 2025 (Part I)

Simplifying PM Task List Migration: Iterative Loading of Operations and Suboperations

A Comprehensive Guide to Data Migration with the SAP S/4HANA Migration Cockpit

Uptime Customizing for Finance Conversion (UCFC)/CustOnTmp

SAP S/4HANA Migration Cockpit – Migrate Directly from SAP – Increase flexibility using Split Logic

Latest Features in the SAP S/4HANA Migration Cockpit, released with 2025 FPS0

Introducing the Latest Features in the SAP S/4HANA Migration Cockpit for SAP S/4HANA Cloud Private Edition and SAP S/4HANA

New Staging and Direct Transfer Approach Features

Sequence Information View

Easier Access to Message Information

Server Group Assignment

Job Management

New Staging Features

Optimize Migration Performance

Efficient Error Handling When Uploading Template Files

Correction File After Simulation

Download Template File (LTMOM)

New Direct Transfer (DT) Approach Features

Object Versions

Define Split Logic (LTMOM)

Event Based Rules (LTMOM)

Class Based Source Code Rules (LTMOM)

Utilizing Where Conditions Editor (LTMOM)

Instance Field List (LTMOM)

New Migration Objects

SAP S/4HANA migration cockpit: Adapt the XML file to your business needs

Did you know that it is possible to adjust the XML files easily?

Note

Option 1: Delete a non-mandatory sheet

Note

Option 2: Delete a non-mandatory column within a sheet

Note

Using CSV files

The New Explore Migration Objects App, The Game Changer in Planning Your Data Migration

A Short Trip to History

The Tile of Happiness

How does the app support data migration?

For which product and release is the version available, and how do you activate it?

What authorization do I need?

Which approaches are supported?

Where can I find the app?

How do I use the app?

Selecting the data

Some Example

The graphical overview for migration objects

Functions

Interactions on a node

The graphical overview for scope items

More to Come: A Short Outlook on Ideas

Outlook on SAP S/4HANA and SAP S/4HANA Private Cloud

🚀 Cloud ERP: SAP S/4HANA migration cockpit updates

🎯Cloud ERP Private: SAP S/4HANA migration cockpit updates

浏览迁移对象App——你也能成为数据迁移专家

除了迁移范围，还有迁移顺序

千呼万唤始出来

深入浅出“浏览迁移对象”

根据迁移对象查看

根据范围项目来查看

未来功能的展望

Mapping Stock to New Nested Handling Units Using Migration Cockpit in SAP S/4HANA Public Cloud

SAP S/4HANA Migration Cockpit – Migrate Directly from SAP System – The Transfer List

SAP S/4HANA Migration Cockpit – Migrate Data Directly from SAP System – Using Staging Tables

Migration Cockpit in SAP Cloud ERP 2602

How to Add a Field to a Migration Object in SAP Cloud ERP (SAP S/4HANA Cloud Public Edition)

SAP S/4HANA Migration Cockpit – Migrate Data Directly from SAP System – Using Staging Tables