Now accepting guest editorial from SAP, Oracle, Workday and ServiceNow practitioners.Pitch a guide
The Sign-Off Table

Lesson 1 of 5

Adapt, create or do neither

11 min

The SAP S/4HANA Migration Cockpit ships with a large library of predefined migration objects, and for most projects they cover most of the data. Sooner or later, though, the template is missing something: a custom field the business relies on, a structure the predefined object does not carry, or a whole kind of data SAP does not deliver an object for. The Migration Object Modeler is the tool for those cases. It lets you adjust predefined objects and build your own, and in on-premise and Private Edition systems you open it with transaction LTMOM.

Because the modeler is powerful, the first skill is restraint. Every change you make is code and configuration that must be designed, tested, transported and maintained across mocks. The question is not "can we model this?" but "what is the least custom way to get this data in correctly?"

Three options, in order of preference

1. Use what SAP deliversCheck the predefined object list and documentation in your exact release; objects are added over time. For key user custom fields, check whether the object supports them automatically.
2. Adapt a predefined objectAdd fields, structures or rules to an object SAP already maintains. You keep SAP's API and checks and change only what you need.
3. Create your own objectBuild a user-defined object on a function module or BAPI when no predefined object fits. You own the whole design, its tests and its maintenance.
Preference order for getting data in. Go down a layer only when the one above cannot do the job.
The Sign-Off Table · thesignofftable.com/academy/sap-dmg-301

Before you model anything

  • Check the release. The object list and object documentation differ by release and by edition. An object missing in an older release may exist in SAP S/4HANA 2025.
  • Check custom field support. For many objects, custom fields created with the key user Custom Fields app and enabled for the relevant business context appear automatically in the migration template and staging tables. SAP lists which objects support this; if yours does, no modeling is needed.
  • Check the volume. Forty records of a rarely used master data type may be cheaper to enter manually under a controlled procedure, with evidence, than to model, test and transport.
  • Check the API. If you create an object, you need a function module or BAPI that creates the data with SAP's checks. If none exists, the object is a development project, not a migration task.
  1. Does a predefined object exist for this data in our release?Yes → next question · No → go to question 4
  2. Does it carry every field we need, including key user custom fields?Yes → use it as delivered · No → next question
  3. Can the missing fields be added to its structures and mapped to its target API?Yes → adapt the predefined object · No → consider a custom object
  4. Is the volume large or the load repeated in several mocks?Yes → create a custom object on a suitable function module · No → consider controlled manual entry with evidence
Deciding between using, adapting and creating a migration object.
The Sign-Off Table · thesignofftable.com/academy/sap-dmg-301

Contoso's Wave 2 cases

Our example is Contoso's Wave 2. After converting its ECC system to SAP S/4HANA, Contoso acquired Alternadores del Norte S.A. de C.V. in Monterrey, Mexico, and is loading its data from a non-SAP legacy ERP into the converted system as company code 1910 (MXN) with plant 1910 Monterrey. The load hits both situations. First, Contoso's alternator products carry a warranty class that drives fleet warranty handling; it was created as a key user custom field after the conversion, and the product object supports custom fields, so it appears in the template without modeling. Second, Contoso runs a core return program: fleet customers pay a deposit on each alternator and get it back when they return the old unit. Its agreements live in a custom table that came across in the conversion, and Alternadores has a similar program in its legacy ERP. No predefined object can load that custom table, so the migration team plans a user-defined object.

NeedOption chosenWhy
Warranty class on Alternadores productsUse as deliveredKey user custom field; the product object supports custom fields
Legacy append field "core part flag" on productsAdapt the predefined product objectField appended to the product tables by a developer; must be added to the source structure and mapped
Core return agreements for fleet customersCreate a custom objectCustom table carried over by the conversion; no predefined object; about 2,600 Alternadores agreements loaded in every mock
Twelve legacy shipping instruction textsManual entry with evidenceLow volume, entered once by the Monterrey sales team in the Wave 2 cutover plan

Wave 2 migration extension decisions. Each is recorded in the object list with its reason.

Editions

This course is written for on-premise and Private Edition, where LTMOM gives the full modeler. In SAP S/4HANA Cloud Public Edition, SAP provides more restricted modeling apps, available only for a released set of migration objects and run through the system's own apps rather than the on-premise transaction. Public Edition projects should check SAP's current documentation before planning any modeling.

Manual entry with evidenceLarge gap, few records: entering them under a controlled procedure can beat building an object
Custom objectLarge gap, many records: build a user-defined object on a function module and own its tests
Use as deliveredSmall gap, few records: live with the delivered object or a small adaptation
Adapt the predefined objectSmall gap, many records: add fields, structures or rules to SAP's object
Choosing an option by the size of the gap and the volume of data. Effort grows with distance from what SAP delivers.
The Sign-Off Table · thesignofftable.com/academy/sap-dmg-301

What would you do?

A Wave 2 developer proposes building a custom migration object for business partners "so we have full control", because the predefined object does not carry two legacy fields. What should the migration lead recommend?

Key points
  • The Migration Object Modeler (LTMOM in on-premise and Private Edition) adapts predefined objects and creates your own.
  • Prefer: use as delivered, then adapt, then create; manual entry can suit tiny volumes.
  • Check release, custom field support, volume and the availability of a creating API first.
  • Public Edition offers more restricted modeling for released objects only.

Check your understanding · not graded

Lesson check

  1. 1. Which transaction opens the Migration Object Modeler in on-premise and Private Edition?

  2. 2. What should you check first when the template lacks a key user custom field?

  3. 3. When does creating a custom object make sense?

  4. 4. What is the main cost of each modeler change?