Warehouse management master data migration fails due to incompatible UoM mappings

We’re migrating warehouse master data from our legacy WMS to SAP IBP si-2211 using Migration Cockpit and hitting a critical blocker. The migration validates successfully but fails during execution with UoM mapping errors.

Our legacy system uses non-standard UoM codes (PKT for packets, CTN for cartons) that don’t map to SAP standard units. We have roughly 8,500 material records affected. The error log shows “UoM PKT not found in target system” for about 2,300 materials.

We’ve tried creating custom UoM entries in IBP, but the migration still fails. The UoM mapping table seems to require ISO codes, but our legacy codes don’t follow that standard. Additionally, some materials have dependencies on the material master that aren’t being resolved during migration.

Anyone dealt with UoM standardization during warehouse data migration? We’re blocked on go-live.

Always re-validate the entire package after making UoM changes. The Migration Cockpit validation checks referential integrity across all records, not just the ones that failed previously.

Here’s what I’d recommend:

  1. Clean your source data - standardize all legacy UoM codes to a single base unit per material
  2. Set up UoM conversions in IBP Master Data with proper conversion factors
  3. Update the UoM_MAPPING sheet in your migration template with legacy→ISO mappings
  4. Re-validate the complete migration package in Migration Cockpit
  5. Run a test migration with a subset of 100-200 materials first
  6. Check the migration log for any remaining errors before doing the full run

For the material master dependencies, split your migration into three sequential jobs: Materials first, then Locations, then Warehouse data. Each job should complete successfully before starting the next one.

I’ve seen this exact issue twice before. The Migration Cockpit UoM mapping requires a pre-configured conversion table that maps your legacy codes to ISO standards. You can’t just create custom UoMs in IBP and expect the migration to pick them up automatically.

Check your migration template - there should be a UoM_MAPPING sheet where you define legacy_code → ISO_code mappings. For PKT and CTN, you’d typically map to PCE (piece) and CS (case) respectively, then handle the conversion factors separately.

The material master dependencies are a separate issue - IBP expects materials to exist before warehouse locations reference them.

You need to set up the UoM conversions in IBP master data BEFORE running the migration. The migration template only handles the code mapping, not the conversion logic.

Go to Master Data → Unit of Measure and create your conversion relationships there. Define PKT as an alternative UoM for PCE with factor 12, and CTN with factor 144. Once that’s configured in IBP, update your migration template to map PKT→PCE and CTN→CS.

For the dependencies, yes - always migrate in this order: 1) Materials, 2) Locations, 3) Warehouse-specific data. Running them together causes referential integrity issues.

Thanks Ray. I found the UoM_MAPPING sheet but it’s not clear how to handle the conversion factors. Our PKT = 12 pieces and CTN = 144 pieces. Do these conversions need to be set up in IBP master data first, or can they be defined in the migration template itself?

Also, regarding material master dependencies - we’re migrating materials and warehouse locations in the same batch. Should we split these into separate migration runs?

Let me provide a comprehensive solution based on your specific scenario with 8,500 materials and non-standard UoM codes.

Step 1: UoM Mapping Table Setup Create a standardization mapping in Excel:


Legacy_UoM | ISO_Code | Conversion_Factor | Base_Unit
PKT        | PCE      | 12                | PCE
CTN        | CS       | 144               | PCE

Step 2: Configure IBP Master Data Navigate to Master Data → Unit of Measure in IBP and create the conversion relationships:

  • Define PCE (Piece) as your base unit
  • Create alternative UoM: PKT with numerator=12, denominator=1, base=PCE
  • Create alternative UoM: CTN with numerator=144, denominator=1, base=PCE
  • Ensure CS (Case) is mapped with appropriate conversions

This establishes the foundation for IBP to understand your legacy unit conversions.

Step 3: Legacy Code Standardization Before migration, cleanse your source data:

  • Identify the 400 materials with multiple UoM codes
  • Determine the primary/base UoM for each material
  • Convert all quantity fields to use the base UoM
  • Document any materials where conversion is ambiguous (manual review needed)

Run this SQL against your legacy system to identify problematic records:

SELECT material_id, COUNT(DISTINCT uom_code) as uom_count
FROM legacy_materials
GROUP BY material_id
HAVING COUNT(DISTINCT uom_code) > 1;

Step 4: Material Master Dependencies Address the dependency chain by splitting your migration into three separate jobs in Migration Cockpit:

Job 1 - Material Master (run first):

  • Migrate all 8,500 material records
  • Include base attributes: material number, description, base UoM
  • Validate that all materials are created successfully in IBP

Job 2 - Location Master (run second):

  • Migrate warehouse locations
  • Ensure location type mappings are configured
  • Verify location-material relationships reference existing materials

Job 3 - Warehouse Data (run third):

  • Migrate stock levels, bin assignments, and warehouse-specific attributes
  • All material and location references should now resolve correctly

Step 5: Migration Template Update In your Migration Cockpit template, update the UoM_MAPPING sheet:

  • Map PKT → PCE (the system will apply the 12x conversion automatically)
  • Map CTN → CS (ensure CS is also configured with proper conversion to PCE)
  • For any other legacy codes, map to the closest ISO equivalent

Step 6: Validation and Testing Before the full migration:

  • Re-validate the complete migration package (don’t skip this)
  • Run a pilot migration with 200 representative materials (include some with PKT/CTN)
  • Check the migration log for errors: MIGR_LOG table in IBP
  • Verify converted quantities are correct in IBP after pilot
  • Test a planning run with the migrated data to ensure downstream processes work

Step 7: Handle Edge Cases For the 2,300 materials showing “UoM not found” errors:

  • Export the error list from Migration Cockpit
  • Cross-reference with your UoM mapping table
  • Identify any legacy codes you haven’t mapped yet
  • Add missing mappings to the UoM_MAPPING sheet
  • For truly custom units that don’t have ISO equivalents, you may need to create custom UoMs in IBP first

Critical Success Factors:

  1. Never run migrations in parallel - dependencies must be respected
  2. Always use base UoMs in quantity fields during migration
  3. Test conversion calculations manually for a sample of materials
  4. Keep detailed documentation of your UoM mapping decisions
  5. Plan for a rollback strategy if the full migration fails

Post-Migration Validation: After successful migration, run these checks:

  • Compare material counts: legacy system vs IBP (should match 8,500)
  • Verify UoM conversions with spot checks on 50-100 materials
  • Test warehouse transactions using the new UoMs
  • Run a full planning cycle to ensure no data quality issues surface

The key insight here is that Migration Cockpit UoM handling requires both system configuration (IBP master data) AND template mapping (migration file). You can’t rely on one without the other. Additionally, the material master dependencies mean you must migrate in sequence, not in a single batch.

Once you’ve completed steps 1-3, your migration should proceed cleanly. The 2,300 errors will resolve once the UoM mapping table is properly configured and the legacy codes are standardized.

Adding to the above - watch out for legacy materials that use multiple non-standard UoMs. I’ve seen cases where a single material had 4-5 different UoM codes in the legacy system, and only one was the “base” unit.

You’ll need to standardize these before migration. Create a mapping document that identifies the base UoM for each material, then ensure all quantity fields in your migration file reference that base unit. Otherwise, you’ll get inconsistent data in IBP that causes issues downstream in planning runs.

Also check if any of your 8,500 materials are marked as inactive in the legacy system - Migration Cockpit sometimes tries to migrate everything, including obsolete records.