TL;DR
The SAP migration cockpit is SAP’s built-in tool for loading business data from SAP and non-SAP sources into S/4HANA. You open it through the Migrate Your Data app, Fiori ID F3473. It comes with S/4HANA at no additional license cost. Each project uses staging tables for files, non-SAP systems and ETL tools, or direct transfer for supported ABAP-based SAP systems. Every load then runs select, get data, map, simulate and migrate, in the order object dependencies require. A clean simulation is still not sign-off, so reconcile counts and balances with business owners before cutover.
Key Takeaways The Migrate Your Data app (Fiori ID F3473) replaced transaction LTMC, and LTMC projects do not carry over after an upgrade. Staging tables take data from XML or CSV templates, a remote SAP HANA schema or an ETL tool, while direct transfer reads ABAP-based SAP systems over RFC. Object coverage depends on edition and release, and SAP’s January 2026 deck lists 237 staging and 260 direct-transfer objects for S/4HANA Cloud Private Edition. Load order matters more than object count, and the Sequence Information view shows which objects must go first. The cockpit carries no extra license, but project effort, ETL infrastructure and reconciliation work are still yours to plan. Simulation proves the technical load, while reconciliation in the functional apps proves the data is right. Watch on YouTube
State of Enterprise Data Migration 2026: Why 73% of Migrations Fail
Kanerika walks through why enterprise migrations stall between a technically finished load and data the business trusts, the same gap a cockpit project has to close before cutover.
A Cutover Weekend and a Template That Will Not Validate
“Validation Completed with Warnings.” A template can show that status after an XML or CSV upload in the Migrate Your Data app, and it reads like good news. It tells you validation ran. What it leaves out, according to SAP KBA 3752152 , is that the data never reached the staging tables, so simulation is unavailable.
Now let the customer template come back with that status on the Saturday night of a cutover weekend. Open items cannot load before the customers they belong to, and every hour spent on one template pushes back every object behind it. The scene is illustrative, a composite rather than a client story, but each piece of it is real cockpit behavior.
The SAP migration cockpit is SAP’s primary tool for moving business data into S/4HANA. Still, most cutover pain traces back to three decisions made weeks earlier, the approach, the load order and the proof that the numbers are right.
What Is the SAP Migration Cockpit?
The SAP migration cockpit is the data migration tool built into SAP S/4HANA. SAP Learning calls it the primary tool for migration from both SAP and non-SAP source systems. Users reach it through the Migrate Your Data app on the Fiori launchpad. That holds for on-premise, private cloud and public cloud, although functions and available objects vary by environment.
What the Cockpit Does in an S/4HANA Project
Its unit of work is the migration object. A migration object is a predefined SAP model for one kind of business data.
Examples include a cost center, a G/L account, a customer or a bill of materials. It carries the source structures, the target structures and the mapping rules for that data.
For each object, the cockpit generates its own migration program, so moving standard data needs no programming. The loads also run through the same APIs and technical validation checks as the standard functional apps.
For example, a bank record loaded through the cockpit passes the same checks as one entered in the Manage Banks app. That is why SAP points teams back to those apps for verification.
What It Is Not: Sync, Conversion or a Database Move
The cockpit is built for the initial load of a new S/4HANA system. SAP also uses it for repeatable one-off loads, for instance when a newly acquired subsidiary moves into the parent company’s system.
It will not keep two systems in sync after go-live, though. That job belongs to the integration layer, covered in Kanerika’s guide to SAP data integration .
It is also not a system conversion. A brownfield conversion keeps the existing ERP data and converts it in place.
So the cockpit’s clearest role is greenfield, where the new system starts empty. Selective data transition projects use it only for the slices of data they rebuild. The difference between data migration and data integration also explains why one tool rarely does both jobs.
What You Need Cockpit Fit Where to Look Instead Initial load into a new S/4HANA system Core use Not needed One-off load, such as an acquired subsidiary Good fit, repeatable per project Not needed Ongoing sync between systems Not designed for it An integration or replication platform In-place move of an existing ERP (brownfield) Different path SAP system conversion tooling Heavy cleansing across many non-SAP sources Partial, needs help upstream SAP Data Services or an ETL tool feeding staging tables
Where It Sits in the Wider Migration Program
The cockpit handles one stage of a larger effort. Scoping, cleansing, testing and governance sit around it, and Kanerika’s guide to SAP data migration covers that program view across ERP and analytics data. Because the cockpit only moves what the plan hands it, the plan decides most of the outcome, whatever the type of data migration involved.
Migrate Your Data App vs LTMC (and LSMW): What Changed
The redeveloped cockpit arrived with release 1610 at the end of 2016, according to the gambit consulting wiki . It followed LSMW, the older Legacy System Migration Workbench, which SAP does not recommend for S/4HANA loads. Direct transfer came later, from release 1909.
Why Old LTMC Tutorials Still Rank
Search for the cockpit and many screenshots still show transaction LTMC, the Web Dynpro version. Those pages were written when LTMC was the front door, and they describe a “Transferring Data Using Files” approach that belonged to LTMC alone.
Kanerika Service
Data Migration Services
Kanerika plans, cleanses, rehearses and reconciles enterprise data migrations, so the load tool receives data that is ready to move.
Explore Migration Services SAP’s KBA 2988692 separates the two versions. The old one had file and staging approaches, while the Fiori app has staging tables and direct transfer.
The Migrate Your Data App (F3473)
From S/4HANA 2020 onward, the Fiori app is the route for staging-table projects, as SAP’s FAQ note KBA 2733253 shows. LeverX , citing SAP documentation, reports that SAP S/4HANA 2025 FPS01 no longer lets LTMC migrate data at all, although old projects stay viewable. Because no single cut-off year holds for every release, check KBA 2988692 for yours.
Two practical consequences follow. First, LTMC projects do not appear in the new app after an upgrade (KBA 3190915), so plan to rebuild them early, before a test cycle exposes the gap.
Second, the migration object modeler, transaction LTMOM, is still current, and teams use it to extend objects.
That also settles the common question about the SAP migration cockpit tcode. On-premise and Private Edition users open the Fiori app, LTMOM is the modeler transaction, and LTMC belongs to the past.
What to Check Before You Follow a Tutorial
Tutorial Signal What to Verify Screenshots of transaction LTMC Whether your release still lets LTMC migrate data A “file” approach The Fiori equivalent, staging tables filled from XML or CSV templates Excel XML templates only Whether CSV templates or remote staging suit your volume better No release number on the page The object list on SAP Help for your exact release Object names you cannot find The object’s lifecycle status, such as deprecated or retired
Staging Tables vs Direct Transfer: Choosing Your Approach
Every cockpit project starts with a choice of approach, and the source system usually makes it for you. Both routes end in the same place, though, with a simulation, a migration and then a reconciliation.
Watch on YouTube
Data Migration Life Cycle: 7-Phase Step-by-Step Guide (2026)
A step-by-step walk through the phases of a data migration, from assessment and mapping to testing and sign-off, useful context for where each cockpit step sits.
Migrate Data Using Staging Tables
With staging tables, data passes through a temporary table in SAP HANA before it reaches S/4HANA. The cockpit creates those tables automatically, either locally or in a remote system. There are two ways to fill them.
The local schema route uses downloadable XML or CSV templates that people fill by hand or by copy-paste. SAP calls it the standard approach, but also notes that it gets labor-intensive for very large datasets.
The remote schema route puts a separate SAP HANA database between the legacy system and S/4HANA. Teams then fill it with an ETL tool or SAP Data Services. SAP calls this setup more complex, but also highly efficient for high-volume migrations. Because staging accepts any source that can produce the right structure, it suits non-SAP systems and legacy data migration . It also fits teams that already run ETL pipelines .
Migrate Data Directly From an SAP System
Direct transfer connects to an ABAP-based SAP source system over an RFC connection. It selects data by predefined criteria, such as company code for an ERP source. SAP’s January 2026 product deck lists supported scenarios from SAP ERP, SAP AFS, SAP APO SPP, SAP CRM and SAP EWM.
Data converts to the S/4HANA data model during the load. A detailed selection, however, is only possible through LTMOM, as the SAP consultancy Consilio points out.
Direct does not mean clean. Bad records in the source arrive just as bad in the target, and mapping and validation still apply.
So SAP S/4HANA 2025 FPS01 added an option, for supported scenarios, to park selected data in staging tables first. Teams can then adjust and cleanse it before the transfer finishes.
Criterion Staging Tables Direct Transfer Typical sources Files, non-SAP systems, ETL tools and SAP systems ABAP-based SAP systems (ERP, AFS, APO SPP, CRM, EWM) Data preparation Outside SAP, in templates or the remote schema Selection criteria in the cockpit and LTMOM Connectivity File upload or a remote SAP HANA schema RFC connection to the source Value mapping In the template or the cockpit In the cockpit only Objects, S/4HANA Cloud Private Edition (Jan 2026 deck) 237 260 Best fit Non-SAP or messy sources and heavy cleansing SAP ERP to S/4HANA with a clear scope
How to Choose for Your Project
Five questions settle most choices before anyone builds a template.
Scenario. Is this a greenfield load, a selective transition or an acquired company?Deployment. Which edition and release will the target run, since object coverage changes with both?Object coverage. Does SAP ship an object for each data set in scope, for the approach you want?Source. Is the source an ABAP-based SAP system with a supported scenario, or something else?Readiness. Can the team clean, map and reconcile the data at the volume involved?If the source question comes back no, staging tables are the answer. If it comes back yes and the data is in good shape, direct transfer saves the template work. Staging still stays available for any object that needs heavy cleansing first.
Migration Objects: Scope, Dependencies and Extensions
Migration objects decide what the cockpit can load at all. Before anyone fills a template, the team needs to know which objects exist for its release, which depend on others and which need changes.
What a Migration Object Contains
A migration object bundles the structures, relationships and mapping rules for one business entity. The list of available objects depends on the activated scope, the approach and the release.
SAP also documents new, changed, deprecated and removed objects for each release. So a plan copied from an older object list is really a plan for a different system.
Objects have a lifecycle as well. SAP marks some as deprecated or retired, and a “New Mandatory” version forces the team to add that object to the project again.
How to Check Object Coverage for Your Release
Start with the object documentation on SAP Help for the exact release and edition. Each object’s page includes a Post-Processing section that names the app to use for validation, and that list later becomes the reconciliation plan. Counts differ by edition, so the Private Edition figures in the table above are a reference point, not a promise for your system.
Load Order and Object Dependencies
Objects depend on each other. A customer open item, for instance, needs the customer record to exist first. Two places in the cockpit now show these links, the Sequence Information view and a newer app built for exploring them.
Kanerika Service
SAP ABAP Development
Kanerika’s ABAP team builds and documents LTMOM rules, custom fields and S/4HANA extensions that stay upgrade-safe.
Explore SAP ABAP Services The Sequence Information view groups objects in the order to process them, with Group 1 migrated first and Group 2 after it. The Explore Migration Objects app (App ID F8638) draws how objects connect and marks each predecessor as mandatory or optional. An illustrative order, not an SAP rule, runs in five layers.
Configuration and organizational structure in the target system Foundational master data, such as G/L accounts, cost centers and banks Dependent master data, such as customers, suppliers and materials Open items and balances Reconciliation against the source and the business totals Historical data is the usual surprise in that order. The cockpit loads open items and balances, not full transaction history.
For Public Edition, SAP documents that the cockpit does not migrate closed historical transactional data at all. Agree early on where old documents will live.
Extending Objects With LTMOM
Standard objects rarely match a real company exactly. LTMOM adds custom fields to objects.
For direct transfer, it also supports split logic, event-based rules that run ABAP at processing events, class-based rules and a WHERE conditions editor. That work is ABAP development, and Kanerika’s guide to SAP ABAP explains where it fits in a modern S/4HANA team.
Every extension also has a life after go-live. So keep custom rules small and documented, because each one should respect the SAP clean core approach the new system is meant to protect.
How to Use the SAP Migration Cockpit: Step by Step
SAP describes the flow as five steps, select migration objects, get data, map and transform, simulate and migrate. This guide adds a setup step before them and a reconciliation step after them, where the project proves the load, so it runs in seven steps. Access comes before all of it, because the user needs authorization for the Migrate Your Data app plus permissions for each data type being loaded.
1. Create the Migration Project and Pick the Approach
Create the project in the app and choose staging tables or direct transfer. For direct transfer, the project also needs the RFC connection to the source. For large runs, SAP now lets teams assign a dedicated application server group, so the migration does not disrupt the business.
2. Select Migration Objects and Check Prerequisites
Add the objects in scope, then open Sequence Information to confirm the order. If a mandatory predecessor is missing from the project, add it now instead of finding it at simulation.
3. Get the Data Into the Project
In a staging project, download each template, fill it and upload it. The upload checks size and format, sanity, duplicates and consistency, and since the 2025 release all sanity, duplicate and consistency errors appear at once. That means nobody re-uploads the file after each fix.
Errors land in a Messages tab inside the template, with links to the affected cells. The team downloads the file with errors, fixes the cells, deletes the Messages tab and uploads it again. SAP also raised the XML upload size limit in 2025 FPS01, so check the current limit in Application Help before you split files.
In a direct-transfer project, the cockpit selects data from the source by the criteria the team sets. The Analyze Your Selection Process app simulates the selection for one object instance and shows what was picked, which helps when counts look wrong.
4. Map and Transform Values
Mapping tasks convert legacy values into S/4HANA values, such as old plant codes into new ones. With staging, new values can live in the template or the cockpit, while direct transfer keeps all mapping in the cockpit. Keep a signed copy of each mapping, because source-to-target mapping decisions are what auditors ask about later, and they feed data lineage records too.
5. Simulate and Fix Errors
Simulation runs the load through the real APIs without committing data. When it ends with errors, Create Correction File produces a file that holds only the failed instances.
As a result, the team fixes those rows instead of reworking the whole set. The guidance actions on each message also point to a likely cause.
6. Migrate, Then Monitor Results
Migration commits the data. Split large volumes into more packages, then use Job Management to set parallel jobs, starting from the number the Prepare step suggests. Some objects allow only one job, CO cost center among them, and KBA 3294684 lists the rest.
In direct-transfer projects, the Transfer List shows exactly what the cockpit passed to the API after mapping, instance by instance. It becomes available once an object has been simulated or migrated, so it is the first place to look when a field arrives empty.
7. Reconcile and Sign Off
A green migration status says the API accepted the records. It does not say the trial balance matches.
So verify each object in the functional app named in its Post-Processing section. Then compare record counts and control totals with the source, and check a sample of records field by field.
Finally, get the data owner’s signature for each object. Kanerika’s guides to data migration testing and data reconciliation tools cover the methods in more depth.
Common SAP Migration Cockpit Errors and How to Approach Them
Cockpit errors tend to fall into a handful of families. SAP publishes the symptoms in public knowledge base articles, while the resolutions often sit behind an SAP for Me login. The table below therefore names the likely cause and the place to check, not a guaranteed fix.
Symptom Likely Cause Where to Check Object stuck at “Not ready for processing” with a “preparing this migration object” popup Object preparation has stalled KBA 3350561, then the latest cockpit corrections per KBA 3707655 “Validation Completed with Warnings” after upload, staging stays empty Upload validated with warnings, data not yet in staging, so Prepare, Mapping and Simulation stay disabled KBA 3752152 and the template’s Messages tab Upload rejected with cell-level messages Format, sanity, duplicate or consistency errors Messages tab in the downloaded template Simulation ends with errors Values, mappings or a missing predecessor Simulation messages and the correction file App tile or create action missing Authorization or business role gap The user’s roles for the app and the data type Date or number values rejected Template format differs from user settings Template format rules and the user’s date and decimal settings Duplicates after a re-run Re-run behavior differs by object The object documentation, before any reload Parallel job settings will not change Single-job object, or status “Not Ready for Processing” KBA 3294684 and the Job Management screen
One failure never shows up in that table. A load can pass every technical check and still leave finance balances off, because a mapping sent receivables to the wrong account. That gap between technical success and a failed reconciliation is one of the harder-to-spot data migration challenges . It is also the reason simulation success is never business sign-off.
Readiness and Cutover: What to Settle Before the Final Load
The final load is the shortest part of the project and the least forgiving. A sound plan runs several test cycles before it, starting with an early load that tests templates and mappings. Then comes a repeat cycle at production-like volume, and finally a dress rehearsal close to cutover with the real sequence and timings.
Checklist
Data Migration Checklist for Enterprise Teams
A step-by-step checklist for scoping, cleansing, testing, cutover and sign-off, the controls a cockpit load depends on.
Get the Checklist → Each cycle should end the same way, with counts, totals and samples checked against the source. If a rehearsal only proves that the cockpit ran, the team has tested the tool and not the data.
Requirement Evidence Owner Target configuration complete Configuration transported and organizational structure checked SAP functional lead Roles assigned A test user loads each object without authorization errors Security and basis team Object coverage confirmed Object list checked on SAP Help for the target release Migration lead Mappings approved Signed mapping files per object Data owners Rehearsal loads passed Last rehearsal inside the agreed error threshold Migration lead Load sequence fixed Sequence Information matches the cutover runbook Migration lead Reconciliation rules agreed Count, total and sample rules for each object Finance and data owners Sign-off path named One named approver per object Business sponsor
Running the Cutover Weekend
Cutover itself needs a source freeze, a fixed extraction time, the agreed load sequence and failure thresholds that trigger a stop. It also needs named people who sign off each object. Write the rollback trigger down before the weekend, so nobody has to decide it at 2 a.m.
Protecting Real Data in Test Cycles
Test cycles also put real customer and employee data into non-production systems. Limit staging access to the people loading data, mask what testers do not need with data masking tools , and delete staging contents after each cycle. Kanerika’s data migration governance guide and its data migration checklist cover the controls that sit around this step.
Limits of the SAP Migration Cockpit and When You Need More
The cockpit suits light to medium complexity, in the words of the gambit wiki. When a project pulls from many third-party legacy systems, the same wiki points to SAP Data Services instead, because such projects are usually data-quality work.
It is also not a cleansing engine, a sync tool or a system conversion. Quality work therefore happens before the template, which is where a data quality framework and a plan for data cleansing during migration earn their place.
License cost is rarely the issue, since SAP includes the cockpit at no additional cost. Instead, the effort sits in object count, source data quality, custom fields, rehearsal cycles and reconciliation. For a side-by-side view of the cockpit and other options, see the full comparison of SAP data migration tools . For where the load sits in a larger change effort, see Kanerika’s view of SAP modernization .
How Kanerika Supports SAP Data Migration Around the Cockpit
Kanerika works around the cockpit and does not replace it. The work follows the load itself.
First the team assesses object coverage and dependencies for the target release. Then it profiles, cleanses and maps the source data and rehearses cockpit loads. Finally it reconciles the result and builds trusted reporting once the new system is live.
For LTMOM rules and custom field work, Kanerika’s SAP ABAP services build and document the extensions. For reconciliation, Klarity360 compares source and target data, applies business rules written in plain language and keeps a traceable record of every match and mismatch.
It reads files such as CSV and Excel and databases such as SQL Server and Oracle. So teams run it on legacy extracts and target-side exports, not inside the cockpit.
Kanerika reports 60% faster data reconciliation and 5X faster migration sign-off with Klarity360. Those gains matter most in the rehearsal cycles, where the same comparison runs again and again under data governance rules the business has already agreed.
The Same Discipline Outside SAP
The same discipline shows up in Kanerika’s migrations outside SAP. One example is a North American beverage manufacturer and distributor with ERP, HR and IoT sources. Kanerika moved its analytics from SSAS to Snowflake, cut manual data reconciliation by 60% and made reporting cycles 40% faster. It was not a cockpit project, but the lesson carries over, because automating the data flow took most of the manual reconciliation off the team.
Case Study
60% Less Manual Reconciliation via Snowflake Migration
A beverage manufacturer and distributor moved from SSAS to Snowflake with ERP and IoT sources, cutting manual data reconciliation by 60% and reporting cycles by 40%.
Read the Case Study → Three pitfalls come up again and again in S/4HANA loads, planning from an old object list, treating simulation as sign-off and rebuilding LTMC projects late. Each one is cheap to fix in week two and expensive on cutover weekend.
Kanerika’s migration services start with exactly those checks. To scope a cockpit project or review readiness before the final load, talk to Kanerika’s team .
What a Validated Cockpit Load Comes Down To
The SAP migration cockpit is SAP’s built-in route for loading business data into S/4HANA through the Migrate Your Data app, with no extra license. Choose staging tables for files, non-SAP sources and ETL tools.
Choose direct transfer for supported ABAP-based SAP systems. Then run select, get data, map, simulate and migrate in dependency order, and call the load done only after the business has reconciled it.
Frequently Asked Questions
What is the SAP migration cockpit?
The SAP migration cockpit is the data migration tool built into SAP S/4HANA. It loads business data such as customers, suppliers, G/L accounts and open items from SAP and non-SAP sources. Users open it through the Migrate Your Data app on the Fiori launchpad, and it generates the migration programs for each predefined migration object.
What is the SAP migration cockpit tcode, and how do I access it?
On current S/4HANA releases there is no single tcode to remember, because the entry point is the Fiori app Migrate Your Data, ID F3473. Transaction LTMOM still opens the migration object modeler for extensions. Older guides name LTMC, but SAP now documents LTMC as no longer usable for migration on recent releases.
Is the SAP migration cockpit the same as LTMC?
LTMC was the earlier Web Dynpro version of the cockpit. The Fiori app Migrate Your Data replaced it, starting with S/4HANA 2020 for staging-table projects. Projects created in LTMC do not appear in the new app after an upgrade, so teams need to rebuild them in the Fiori app before their next test cycle.
What is the difference between staging tables and direct transfer?
Staging tables hold data in a temporary SAP HANA table filled from XML or CSV templates, a remote schema or an ETL tool, so they suit files and non-SAP systems. Direct transfer reads an ABAP-based SAP source over an RFC connection and converts the data to the S/4HANA model during the load.
Can the SAP migration cockpit load data from non-SAP systems?
Yes. The staging tables approach accepts data from any source that can produce the template structure, including legacy databases, spreadsheets and other ERP systems. For high volumes, teams fill a remote SAP HANA schema with an ETL tool or SAP Data Services, which then feeds the staging tables the cockpit reads from.
Does the SAP migration cockpit need a separate license?
No. SAP includes the migration cockpit with SAP S/4HANA at no additional cost. Other parts of a migration still carry costs, though, such as a remote SAP HANA database for staging, ETL tools or SAP Data Services, consulting effort, rehearsal cycles and the reconciliation work that proves the load is right.
Can the SAP migration cockpit migrate historical transactions?
The cockpit is designed for open items and balances, not complete transaction history. For SAP S/4HANA Cloud Public Edition, SAP documents that closed historical transactional data is not migrated through the cockpit. Teams usually keep old documents in an archive or a reporting store and agree on that plan before mapping starts.
Can I add custom fields or extend migration objects?
Yes, through the migration object modeler, transaction LTMOM. It adds custom fields to standard objects and, for direct transfer, supports split logic, event-based ABAP rules, class-based rules and a WHERE conditions editor. Keep each extension small and documented, so the S/4HANA system stays easy to upgrade later.
How many migration objects does the SAP migration cockpit support?
It depends on the edition, release and approach. SAP’s January 2026 product deck lists 237 staging objects and 260 direct-transfer objects for S/4HANA Cloud Private Edition. SAP also publishes new, changed and deprecated objects for every release, so always check the object list on SAP Help for the exact target release.
