Troubleshooting DMM issues with Migration Jobs
- Martin Surasky
- Dec 17, 2025
- 4 min read
I've often observed that the Data Migration Manager doesn't effectively communicate errors related to business rule violations during container migrations.
Today, I'll share a recent experience that was quite frustrating and took me days to resolve. By sharing this, I hope you can avoid the same troubles.
Presenting the scenario: is DMM Lying to me?
I was tasked with migrating Posting Controls using the Data Migration Manager. I thought it would be straightforward and expected to quickly create a proof of concept showing that Posting Control Headers (POSTING_CTRL) could be easily migrated with DMM. I was confident in my understanding of Posting Controls and DMM, so what could go wrong? (famous last words).
Shortly after, I had my initial "POC" ready—a legacy file with a single Posting Control to move through DMM's migration stages, from creation to full deployment, with necessary validations in between.
What does this header aim to migrate? A single posting control for Posting Type M2 (Internal Issue), with C83 as the Control Type (Location Group), used for Code Part A (Account).
Getting to Work
To ensure no business rules were violated, I manually inserted a similar record in my Test Environment. This is a best practice I use, especially when dealing with unfamiliar containers. I wanted to confirm my POC data was valid.
The manual insertion succeeded, and the data appeared in my list of Posting Controls.
With my test and sample one-row legacy file, I deleted the record and attempted to insert it via DMM. What followed was the typical DMM process:
Load Container Table Rows
Lock Loads
Move to Input Container Table
Validate Meta Data
Move to Output Container Table
Validate Basic Data
Approve
Deploy
All eight steps were nearly successful. DMM reported success after deploying my Posting Control, indicating no errors.
Typically, this means the task was completed, and the data should be in the target system, "CFG." However, upon checking, I found only two entries for M2 (Control Types AC1 and C5), with no sign of C83.
Problem Investigation
I won't detail my extensive investigation. I spent considerable time debugging, examining IFS's process for inserting a new Posting Control, trying to understand why the data wasn't in the database despite DMM's "Deployed with Commit" report. I repeated tests with different Control Types, checked the POSTING_CTRL view and base table (POSTING_CTRL_TAB), and verified permissions, hoping it was a permission issue (data existed but was invisible). None provided answers.
After being unsure of where to look, I decided to use the original legacy file again, but this time I tried the FNDMIG tool (also known as the "Simple Tool" or "Migration Jobs"). This tool offers an alternative method for data manipulation, which involves more than just migration, by using discrete migration tasks that focus on a single activity. I created a Job using the INSERT_BY_METHOD_NEW. I don't intend for this post to focus on the tools mentioned here, as I assume you're already familiar with them. If you're not, please refer to the IFS technical documentation, as explaining the details here would make this post unnecessarily long for those IFS consultants/techs who are already knowledgeable about this.
The configuration of my Migration Job looks more or less like this
After loading the file and starting the job (online), I sought insights into the issue or successful row insertion. Here came the breakthrough. Using the Migration Job tool, I encountered an error—unlike DMM, the Migration Job reported what was wrong with my file.
Findings
So, if the "Posting Ctrl already exists," what was I doing wrong? The answer was obvious, but I needed the error description to unravel my migration issues. The data "already exists" due to a duplicate Primary Key! Was my understanding of this data incorrect? Could the PK be COMPANY (PII) + CODE_PART (A) + POSTING_TYPE (M2) + CONTROL_TYPE (C83)?
There are ways to confirm this, such as examining view meta data field flags. This info is also in the Migration Job definition. In fig6 (File Mapping tab), notice the Flags column tells a different story—the composite PK is actually COMPANY (PII) + CODE_PART (A) + POSTING_TYPE (M2) and PC_VALID_FROM (2018-01-02)!
Reflecting on this, with my Finance functional role cap in my head, it made sense—two Posting Controls for the same Code Part and Posting Type can't be active simultaneously (Same Valid From). Essentially, if you have an M2 transaction and Fixed Value (AC1), account ABC123 is used, and your Location Group (C83) dictates the account for the transaction (maybe XYZ789). Two rules sending a transaction to different Financial Accounts can't coexist.
Why didn't I catch this during manual entry? Because IFS auto-populates the Valid From date with today's date, not 2018-01-02. I missed this and didn't verify my record against the legacy text file.
I could've noticed this in my DMM migration results (fig3). The "Deploy Record Status" column reads "UPDATE." If it was a new record, why not "INSERT"? DMM saw the Primary Key fields, assumed the record existed, tried to UPDATE it (the AC1 control type), failed, but swallowed the error for some reason and reported success instead.
Lesson Learned
The lesson for me? If DMM reports success but the data is missing in target systems, use an INSERT_BY_METHOD_NEW Job for deeper insights, as it may reveal errors DMM doesn't report.
That's my story today. I hope it helps with your migrations. While this involved Posting Controls, you can apply this experience elsewhere because DMM sometimes reports success despite errors, so this technique is useful beyond Posting Controls.
Have a great day and feel free to reply with your own thoughts and experiences on this subject. Always glad to hear about your own stories!
Comments