Running into issues with our asset lifecycle data migration on Workday R1 2023. We’re using EIB to import about 5000 asset records from our legacy system, but the import fails validation with ‘Location Not Found’ errors for roughly 40% of records.
EIB error log shows:
Row 234: Location 'BLDG-A-FL2' not found
Row 235: Location 'WAREHOUSE-03' not found
Validation failed: Invalid location reference
Our legacy system uses custom location codes that don’t match Workday’s location hierarchy. The location code mapping seems to be the blocker here, but I’m not sure how to properly map these for EIB import validation. Has anyone dealt with location reference mismatches during asset lifecycle migration?
Classic location mapping challenge. EIB needs exact Workday Location IDs, not your legacy codes. First step is to export all your Workday locations (Company > Set Up Locations) and get the Location_ID field. Then you need to build a crosswalk between your legacy codes and Workday IDs. For example, your ‘BLDG-A-FL2’ might map to Workday’s ‘LOC-001-Building_A_Floor_2’. Without this mapping, EIB has no way to resolve your references.
Definitely create the missing locations in Workday first. Don’t force-fit assets to incorrect locations just to make the migration work - that’ll cause data quality issues downstream. Use the Location business process to bulk-create the 120 missing locations before you run your asset EIB. Make sure each new location has the proper hierarchy, is assigned to the right company/organization, and has appropriate security settings. It’s extra work upfront but ensures clean asset lifecycle migration data.
Here’s the complete approach for handling location code mapping in asset lifecycle migration:
Phase 1: Location Code Mapping Analysis
First, extract all unique location codes from your legacy asset data and create a mapping matrix:
legacy_locs = df['Location_Code'].unique()
for loc in legacy_locs:
print(f"Legacy: {loc} -> Workday: [TO BE MAPPED]")
Phase 2: Workday Location Setup
Export current Workday locations via custom report (Location_ID, Name, Type, Parent fields). Identify gaps where legacy locations don’t have Workday equivalents. For the 120 missing locations, create them in Workday using proper hierarchy:
Set Location Type (Building, Floor, Room, etc.)
Assign to correct organizational unit
Establish parent-child relationships
Activate for your effective date range
Phase 3: EIB Import Validation
Build your mapping lookup table and apply it to asset data before EIB:
Phase 4: Asset Lifecycle Migration
Structure your EIB file with these critical fields:
Asset_ID (legacy identifier)
Location_Reference (mapped Workday ID)
Acquisition_Date
Asset_Type_Reference
Cost_Center_Reference
Validation Checklist:
All location references resolve to active Workday locations
Location hierarchy is appropriate for asset type
Locations are enabled for the asset’s effective date
Security allows asset assignment to these locations
Test with 50-100 assets first, validate results in Workday UI, then scale to full migration. Document your location mapping - you’ll need it for ongoing asset imports and integrations. We reduced our location-related EIB failures from 40% to zero using this systematic approach.
Good points. I’ve started building the mapping table. Question though - do I need to create missing locations in Workday first, or should I try to map all legacy locations to existing Workday locations even if they’re not exact matches? We have about 200 unique location codes in our legacy data but only 80 locations currently set up in Workday.
I’d add that you should validate your location mapping before the full asset migration. Create a test EIB file with just 50 assets covering all your location types, run it through validation, and fix any mapping issues. This iterative approach is much faster than debugging 5000 failed records. Also check if any of your legacy locations are inactive or retired - those shouldn’t be created in Workday unless there’s a specific business need.