Ask any veteran Infor LN consultant what causes implementation projects to slip, and data migration will appear near the top of every list. It is time-consuming, detail-intensive, and dependent on business stakeholders who are already stretched thin. Yet it is also non-negotiable—no business can run on an ERP system loaded with inaccurate or incomplete data. This guide outlines a pragmatic approach to data migration built from hard-won implementation experience.
Understanding the Scope: Key Data Objects in Infor LN
Infor LN's data model is rich and interconnected. A change to an item record can affect bills of material, routings, sales prices, purchase contracts, and warehouse configuration simultaneously. Before writing a single migration script, invest time in understanding the full scope of what needs to move.
- Items (finished goods, raw materials, semi-finished, purchased parts, services)
- Bills of material (BOM) — often multi-level with hundreds of components
- Routings and work centers
- Business partners (customers, suppliers, both)
- Open sales orders and purchase orders
- Inventory balances by location and lot
- General ledger opening balances
- Accounts receivable and accounts payable open items
- Fixed assets
- Customer pricing agreements and purchase contracts
Choosing a Migration Approach
Direct Load via Infor LN APIs and Session Parameters
Infor LN exposes most master data objects through sessions that can be driven by batch import. For example, items can be loaded through the item maintenance session (tcibd0101m000) using BOD (Business Object Document) files or direct database load utilities. This approach gives the most control and performance but requires deep knowledge of LN's table structure and validation logic.
Infor ION and BOD-Based Integration
For organizations moving from another Infor product or using Infor's integration platform (ION), BOD-based migration is the natural fit. Infor defines standard BOD schemas for items, customers, suppliers, and orders. Transforming legacy data into BOD format and publishing through ION ensures that all LN validation logic fires correctly and that data lands in the system in a supported way.
Excel-Based Templates
For smaller data sets and simpler objects, Infor LN's built-in import functionality via Excel templates is effective. This is commonly used for chart of accounts, cost centers, and initial master data in smaller implementations. It is not suitable for high-volume transactional data.
The Migration Lifecycle
- Phase 1 — Inventory and Profile: catalog all source systems and data objects; run profiling queries to measure completeness and quality
- Phase 2 — Mapping: document field-level mappings from source to target with transformation rules
- Phase 3 — Cleansing: execute data cleansing in the source system where possible; fix duplicates, fill mandatory fields, standardize formats
- Phase 4 — Build: develop migration scripts and load programs
- Phase 5 — Mock Migration 1: load into development environment; identify technical errors
- Phase 6 — Mock Migration 2: load into QA environment with cleansed data; business users validate
- Phase 7 — Mock Migration 3 (dress rehearsal): full cutover simulation including timing; validate cutover runbook
- Phase 8 — Production Cutover: execute with sign-off checkpoints at each object
Bills of Material: The Hardest Object to Migrate
Bills of material deserve special attention. A BOM is not just a list of components—in Infor LN it carries effectivity dates, scrap factors, operation references, and phantom item logic. Legacy BOMs often contain years of accumulated errors: inactive components left on active BOMs, quantities in the wrong unit of measure, and engineering changes that were never formally closed.
The recommended approach is to perform a BOM audit before migration. Work with engineering to freeze BOM changes during the migration window, validate component quantities against physical builds, and establish a clear policy for whether historical BOMs or only current BOMs will be migrated.
Common Pitfalls
- Starting migration too late — data migration should begin in parallel with configuration, not after
- Migrating too much — consider whether all historical data actually needs to be in LN or whether a data warehouse is more appropriate
- Skipping business owner validation — IT cannot validate business data; sign-off must come from operations, finance, and engineering
- Underestimating cutover time — building a realistic cutover runbook with task durations and dependencies is essential
- Ignoring related configuration — migrated inventory balances are useless without correct warehouse locations and item parameters already configured
- No rollback plan — define the conditions under which you would abort a go-live and how you would revert to legacy
Working With Auspex on Data Migration
Auspex Consulting brings deep Infor LN data expertise to every migration engagement. We have built migration toolkits for all major LN object types, developed cleansing frameworks that business users can drive without SQL knowledge, and managed cutover operations for multi-site go-lives. If you are beginning an LN implementation or cleaning up a troubled one, let us help you get your data right.