Lesson 2 of 5
Templates and staging tables
11 min
For each migration object, the cockpit generates staging tables: database tables that mirror the object's source structures, one table per structure. A Supplier object, for example, has structures for general data, addresses, bank details, company code data and purchasing organization data. Your job is to get correct data into those tables. There are two ways to do it.
| Fill via templates (files) | Fill directly (your tools) | |
|---|---|---|
| How | Download the object's template, fill it, upload it; the cockpit writes the data into the staging tables | Your extraction and transformation tooling writes into the staging tables, often in a remote SAP HANA schema |
| Formats | XML (spreadsheet format) or CSV, depending on release and choice | Database inserts; no file limits |
| Best for | Small and medium volumes; teams without ETL tooling; manual cleansing | Large volumes; repeatable automated extract-transform-load |
| Contoso use | Banks, source lists, small objects | Suppliers, products and open items from the migration team's staging area |
Working with templates
Download the template from the object in the app. Each sheet (in XML) or file (in CSV) corresponds to a structure. The first sheet usually explains the template; field headers carry the technical and descriptive name, and mandatory fields are marked. Keep these rules:
- Never change the template structure: no renamed, added or moved columns or sheets. If the object structure changes, download a fresh template.
- Respect formats: dates, decimals and leading zeros cause many first-load errors. Store numbers as text where leading zeros matter, such as old supplier numbers.
- Fill key fields consistently across sheets: the supplier key in the bank sheet must match the key in the general data sheet.
- Use the source values in the template and let value mapping convert them (lesson 3), rather than hand-converting values in the file.
File size limits
Uploads have limits. SAP's migration cockpit team has described a limit of 100 MB per XML file, and for a zip archive of several XML files a limit of 100 MB for the zip and 160 MB for the files it contains. The size the cockpit calculates is based on the template's columns, not just the file on disk, so wide templates hit the limit sooner. These figures can change with releases and SAP Notes; check the current documentation. When a file is too big, split the data into several files for the same object, or fill the staging tables directly.
- Is the object's volume small enough for files under the size limit?Yes → templates are fine · No → split into several files or fill staging tables directly
- Will this object be loaded in several mocks with the same logic?Yes → prefer automated filling of staging tables for repeatability · No → templates are fine
- Does the data need heavy transformation before loading?Yes → transform in your ETL tooling and write to staging tables · No → templates plus value mapping
- Is the team comfortable maintaining an ETL flow?Yes → remote schema with ETL · No → templates, with strict version control of files
After the data is in
Once the staging tables are filled, you start the transfer for the object. The cockpit prepares the data, checks it against the structure definitions and generates mapping tasks for the values it found. You can display the records in the staging tables in the app, see how many records each table has, and see each record's processing status as it moves through the steps. Records that are migrated successfully are not migrated again when you rerun; records with errors stay available for correction.
- Step 1FillUpload templates or write to staging tables
- Step 2PrepareCockpit reads staging data and generates mapping tasks
- Step 3MapConfirm value mappings and fixed values (lesson 3)
- Step 4SimulateRun the business checks without creating data (lesson 4)
- Step 5MigrateCreate the data; correct errors and repeat (lesson 5)
Extending objects
If the Alternadores products carry custom fields Contoso uses that must be migrated, the predefined Product object will not know them. In on-premise and Private Edition, the Migration Object Modeler (LTMOM) lets specialists add fields to source structures and map them to targets. After structure changes, the staging tables must be synchronized with the new definition, and templates must be downloaded again. Treat every LTMOM change as a change to tested logic: version it, transport it like configuration and retest the object.
What would you do?
Contoso's Product template upload fails with a message that the file is too large. The file contains 9,000 Alternadores products with all plant and valuation data for plant 1910. What is the best response?
- The cockpit generates staging tables per object structure; fill them via templates or directly.
- Templates come as XML or CSV; never change their structure; watch dates, decimals and leading zeros.
- Mind upload limits (100 MB per XML file as SAP has described); split files or fill tables directly for big objects.
- Extend objects with the Migration Object Modeler in on-premise and Private Edition; resync and retest after changes.
Check your understanding · not graded
Lesson check
1. For staging-table loads, the cockpit:
2. Which change to a template is safe?
3. When is filling staging tables directly preferable to templates?
4. Which tool adds custom fields to a migration object in on-premise and Private Edition?