The Engine Room – DAL Doctrine

(Part 3 of the 6-part series “The Migration Playbook”)

In Part 1, we defined the Strategy and the Clean Cut approach. In Part 2, we established the Governance and the importance of User Enrichment. Now, the meetings are over. The boardroom is empty. It is just you, the server, and a file containing thousand records of Item Masters.

Welcome to The Engine Room.

This is where the theoretical plan meets the hard reality of bits and bytes. In the Infor LN ecosystem, this phase is often misunderstood. Many consultants think migration is just a matter of writing a script to push data into tables. They are wrong. ERPs like Infor LN are a complex organism of business logic. If you try to force-feed it, it will choke.

Today, we explore the technical heart of the migration: the Exchange Framework, the non-negotiable DAL Doctrine, and the psychological trap of False Positives.

The Toolset: more Than Just SQL

In the old days of on-premise ERPs, we had direct access to the database. If we wanted to create a customer, we could theoretically write a SQL statement directly into the table. In the modern CloudSuite era, that door is locked and guarded. We must use the official tools provided by the platform.

While the market offers powerful external tools and Infor itself provides alternatives like Excel Add-ins (perfect for smaller, ad-hoc updates), we will mention Exchange Schemes as the primary vehicle for migration since it’s a built-in solution already available for everyone to use.

Exchange schemes represents the best compromise between performance and integrity. Being a native tool embedded directly within Infor LN, it processes data locally on the server, yet it fully respects the business logic validation (DAL). It is the heavy lifter designed for exactly this purpose.

Think of Exchange Schemes not as a simple import tool, but as a Translation Engine. It allows you to map your flat files to the internal LN table structures, handling the conversions on the fly. Whether your source file uses specific date formats or requires complex field mapping, Exchange converts it to LN internal logic automatically. It also allows for Batch Management, ensuring you can group imports and respect dependencies, such as loading Item Groups before the Item Masters themselves.

The DAL Doctrine: Speed vs. Safety

This is the most critical technical concept in the entire series. Infor LN relies on a Data Access Layer (DAL). This is a software layer that sits between the User Interface (or the Import tool) and the physical database tables.

For technical details on how the DAL maintains business integrity, refer to the official Infor LN DAL Overview.

When you create a Production Order manually in a screen, you aren’t just typing data. The DAL is working in the background to perform validation, ensuring the Item exists. It handles defaults, automatically filling in the Warehouse based on Item Group logic. Most importantly, it handles Triggers.
Creating a header might trigger the creation of default routing operations or allocate inventory in a completely different table.

Let’s be honest: the DAL has pros and cons. The main drawback is speed, as validating logic record by record is computationally expensive. Disabling the DAL drastically increases migration speed, allowing you to load millions of rows in minutes. However, this speed comes at a steep price: safety.

When you bypass the DAL (using Table Update modes), you remove a safety net. The system performs no integrity checks at the moment of insertion. It blindly accepts whatever data you feed it. The risk is that you might successfully load dirty data that looks fine in the database table, but creates chaos the moment a user tries to interact with it.

For example, You might load an Item, but because the DAL didn’t fire, important hidden fields are left null. When a user clicks on that Item in the UI, the screen crashes or throws cryptic errors.

My Take: bypassing the DAL is not forbidden, but it requires extreme caution. It should be reserved for exceptional cases and managed only by expert technical consultants who know exactly which hidden fields and related tables must be manually populated to keep the system consistent. For most of migrations, the slower, safer DAL path is the safest choice.

The False Positive Trap

Once you commit to using the DAL, you must prepare yourself for a specific phenomenon that causes panic: The False Positive Error. The DAL is designed to be thorough. When you import a complex structure, like a Purchase Order with 50 lines, the system validates each line individually. However, for every line it processes, the DAL often re-validates the logic of the Header to ensure consistency.

Imagine migrating a Purchase Order where the Supplier is flagged with a signal code. When the first line loads, the DAL checks the Header and writes an error in the log: Supplier has Quality Issues. When the second line loads, it writes the error again. By the time you finish, you see a log with 500 errors. In reality, you successfully migrated 10 orders, and the system simply reminded you 500 times about a warning.

To manage this, the team responsible for the migration must filter the logs. Identify these repetitive, non-blocking logic messages during dry runs and create a safe list of codes that are actually just noise. If you don’t explain this mechanism to the Business users beforehand, they will lose confidence in the data integrity when they see a red log.

Performance vs. Integrity

Let’s move to a different playing field. We are not just talking about raw insertion speed, but about managing the critical Cutover Window. When dealing with massive data volumes, such as migrating thousands of Open Order lines, the estimated processing time can easily exceed the available 48-hour weekend window.

The solution is not to bypass the DAL, but to optimize your Batch Strategy through Parallel Processing. Instead of loading one massive file sequentially, split your data into smaller, logical chunks. Run multiple batches simultaneously on different datasets that do not collide on the same tables. This approach allows you to saturate the server’s processing power and fit the massive workload into the weekend schedule without ever compromising the safety and integrity of the DAL.

Conclusion

We have our tools selected. We know how to read the logs without panicking. The engine is ready, but a high-performance engine is useless if you don’t know the race track.

In the next part, we build the map. We will talk about The Cutover Migration Plan, the master document that dictates exactly what happens, when it happens, and who pushes the button during the critical Go-Live weekend.

Written by Andrea Guaccio 

March 26 2026