IFS Data Migration Manager Step by Step: DMM Guide

Data Migration Manager is the end-to-end migration tool in IFS Cloud Solution Manager, where a Migration Project holds the scope, the legacy data, the mappings and the validation rules, and data moves through containers before it is deployed. On community.ifs.com it is described as the successor of Smart Data Manager, which is why older posts and training badges use that name.

The older Data Migration tool (documented under Data Management, Data Migration, and known as FNDMIG) works differently. You build a migration job with a Job ID, a Procedure Name, a Method List and a Source Mapping, and the job loads rows through the New__ and Modify__ methods of the business logic. The documentation says this keeps business rules and validations in force, because data does not go straight into tables. Both tools exist in current releases, and the questions about migration jobs, Excel logs or deleting records belong to the second one.

A thread on community.ifs.com about best practice for 24.1.3 summarises the trade-off the same way: DMM fits migrations with well-prepared source data and many validation rules, while FNDMIG is chosen for numbering conversions and non-master-data areas, and both can run on one project. A DMM container can reject data that a Migration Job would load, so decide per area, not once per project.

Before a first load, the Migration Project needs its basic data: sources, connected environments, migration object scope and target table scope. Main Processes and Sprints are optional, according to the 25R1 documentation of Define Migration Project.

• Installed and connected environments: the environment where DMM runs is the installed environment and is usually PROD for security reasons. Other environments are connected through a database link name that Cloud Operations creates, and no links to PROD are created.
• Sources: every legacy system gets a source with a name, a date format, thousand separator and decimal point. Source priority drives duplicate elimination, and priorities 1 to 9 are reserved for sources created from environments.
• Template project: a project can start from a template with predefined migration objects, target tables, conversion lists and additional deployment processes. Importing a template requires the Migration Project Header first.
• Test environment: the first deployment goes to a non-production target. Rehearse in test, then repeat the same steps for production.
• Clean source files: check character set, decimal separator and date mask before the load, since the formats you define on import override those of the file.

Permissions are the part the documentation leaves open. The 25R1 Data Migration Manager pages do not name a permission set. For the Migration Jobs tool, the documentation describes an Authorized Users form that gives some users full access and others only query and start rights through Execute Job. On community.ifs.com, a user reported that someone who was not an authorized user could not see jobs created by others, even with broad projection access, and an IFS community expert named FND_ADMIN_FNDMIG as the out-of-the-box permission set to duplicate and reduce for a job-level role. Treat that as community guidance, check the set names in your own release, and keep the principle from permission sets and segregation of duties: the migration user is a named, reviewed account, not a shared administrator. In 24R2, a community poster found the menu under Data Management, Data Migration, Migration Jobs, so menu paths differ by version.

Seven objects carry a DMM migration, and the container names are literal screen names in the documentation.

• Migration Project: the main record that holds all project settings.
• Migration Object: the core element of the scope, defined in Project Basic Data. It contains target tables, and every target table used to load data into IFS must be bound to a migration object.
• Target Table: the IFS view that receives data. The Target Table Definition stores its metadata: field type and length, mandatory, key, input and updatable flags, letter case and enumeration values.
• Legacy Data and Legacy Table Definition: the imported CSV files, each load numbered with a Load Sequence.
• Mapping: a Mapping Header for a project, a legacy source and a migration object, with detail lines per target field.
• Containers: the Input Container (staging), Output Container (transformed data considered for deployment), Basic Data Container (reference data) and Deployment Container (approved records ready to deploy).
• Transformation Rules and Conversion Lists: the two mechanisms that change values on the way from Input to Output.

The Input, Output and Deployment Containers share one generic layout of 12 key field columns and 400 non-key columns, each field up to 4000 characters, with a message column beside every field. That is why a validation message always sits next to the value it describes.

The sequence below follows the order of the 25R1 Data Migration Manager pages. Run it first for one small table with a few rows, trace the rows from legacy file to Output Container, and only then scale up.

Step 1: Define the project and the scope

Create the Migration Project Header with an ID, a name and the date and number formats DMM should display, then connect a template if you use one. Build the Migration Object Scope in Project Basic Data and generate the Target Table Scope from it. Each target table is classified as Master Data, Transactional Data, Basic Data LOV or Basic Data Set Up, and Referenced Table Relationships can pull in the reference tables a target depends on. A 21R2 option limits that expansion to one level, which keeps scope from growing out of control. Targets that belong to an object are locked by default, and you unlock one before taking it out of scope.

Step 2: Create the target table definitions

For every in-scope target, create the Target Table Definition from the template or the master environment, and then create the metadata lines in the Input Container with the ALL source. The definition extraction picks up custom fields and user-defined fields, so repeat it after customisation changes. Read the flags: key fields that are not insertable are set to Autogenerated, and read-only fields are set Out of Scope. You can pick up to five columns for the duplicate check here.

Step 3: Prepare and export the mapping template

Use the command that exports Migration Object Details in Scope to get an Excel workbook with one sheet per in-scope target table and its fields. This is the document your data owners fill from, and it only contains field details if the definitions from step 2 exist. DMM itself imports CSV, so the extract from the legacy system is delivered as CSV.

Step 4: Load the legacy data and lock the load

Define the Legacy Data Header with the project ID, the source and the legacy data table name, describe the file (character set, field delimiter, string delimiter, date and number format) and choose client or server import. Client loads can run Online or in Background, and Background is recommended for many rows. The server load uses Oracle external tables and, per the documentation, is not available in the public cloud. Each import receives a Load Sequence number. Lock the load: only a locked load can be attached to a mapping, one load can be locked per legacy table, and locking creates the Legacy Table Definition. If a later load differs in structure, DMM warns you, so one mapping serves loads of the same layout.

Step 5: Map legacy fields to the target table

Create the Mapping Header with the Project ID, the Legacy Source ID and a Migration Object that is in scope and has its target table definitions. You can map one legacy column, a concatenation of two, or a legacy SQL column, add a prefix or suffix as a literal in single quotes, or fall back to default values. Smart Mapping suggests pairings by comparing field names, scores each from 0 to 100 and lets you set the accuracy threshold, then you review the suggestions and use Update Original mapping. If the same target is mapped twice, DMM appends a hash and the sequence number, and both mappings load into one target table.

Step 6: Transfer to the Input Container and test with a subset

Use the subset transfer to test the mapping first. Records from it are marked Test, are for testing only and cannot be processed further, and the option is unavailable after a full transfer until you delete the data. Then transfer everything, optionally with Meta Data Validation in the same run. The transfer compares the incoming rows with the Input Container and sets Record Status to New, Modified, Existing or Deleted.

Step 7: Validate and fix in the Input Container

Set the filters for a migration object and target table first, because the container shows nothing without them. Run Meta Data Validation for the source: errors set Data Status to Error and the message column next to the field says why. Fix by transformation rule (the link on the Transformation Rules metadata row) or by Conversion List, where Autofill Conversion List can add All, Missing or Erroneous values and marks new entries with seven asterisks so you see what is still to fill. Then run Check for Duplicates, decide each pair with Exclude from Transfer or a source-specific conversion of the ID, and rerun the check. The only columns a user can edit in this container are Exclude from Transfer and Exclude Comment.

Step 8: Transfer to Output, validate against basic data, approve

Transfer to Output applies the transformation rules. In the Output Container, Basic Data Validation looks for the referenced value in the Validation Target environment of the target table definition, then in the environment from the project's basic data setup, and otherwise in the Basic Data Container and approved Output Container records. If a reference is missing, either transform the value and transfer again, or use Basic Data Extraction to copy the missing value into the Basic Data Container, validate and approve it there, and revalidate the Output Container. A record without errors is set to Approved, and only approved records appear in the Deployment Container.

Step 9: Deploy without commit, read the result, then deploy with commit

In the Deployment Container, existing records are updated through Modify__ and new ones inserted through New__, unless you define an Other Deployment Method. Deploy Without Commit tests for errors and rolls back, and the result is in the Deploy Message field. Deploy With Commit writes and commits, fetches generated keys into the Target Key columns and is the only option that updates Deploy Status and Deploy Date Time. Pre and post deployment processes per target table exist for calculated values and status changes, and an SQL statement process must start with SELECT or WITH, runs once per record and does not allow DML or DDL.

Step 10: Schedule when the project is stable

Once scope, target tables, legacy data and mappings are complete, create a schedule job under Solution Manager, Data Management, Data Migration Manager, Data Migration Manager Schedule Jobs, New Schedule Job. The wizard has four pages: job details, target table details, job setup (including deploy with or without commit and where the process stops) and schedule. The job becomes Active only if the project has no validation errors. Otherwise it stays in planning until you fix what the Validation Info log lists.

Basic data goes first because DMM validates references against approved values. The Target Table Scope classifies tables as Master Data, Transactional Data, Basic Data LOV and Basic Data Set Up. Master and transactional tables are mapped against legacy tables, while the two basic data classes live in the Basic Data Container and are fed by extractions from the Output Container or from target environments.

In practice the order follows the references. Codes, sites and units come first, then master data that points to them, and transactional records last, such as opening balances, open orders or invoices that need the parts, customers or suppliers already approved. The scope view helps here: it shows for each target how many reference tables it has and how many of them are out of scope, so a transactional load with an out-of-scope reference is visible before it fails. The Deployment Container does not show a migration object until a mapping for it exists (one community thread on a missing Customer object suggests creating the mapping of legacy tables to the migration object and refreshing the page; the thread does not confirm which fix worked), so check the mapping and approved records before suspecting permissions.

Cutover is the same sequence run under time pressure. Rehearse the cutover at least once before go-live, and repeat until the reconciliation results are clean, using a fresh extract each time in a test environment. Record how long each stage takes, and fold every manual correction back into the extract or into a transformation rule. A fix applied only inside a spreadsheet will not exist at the next rehearsal, which is how the quiet failures described in data migration as a business reset start. The master data side of the plan is covered in implementing IFS Cloud master data, and the overall phases in the IFS Cloud ERP implementation guide. For the plan itself, the Data Migration Plan and Customer Data Readiness Checklist (IDK-15) gives a per-object load order, sign-offs and a cycle calendar.

For Migration Jobs the reading order differs. The Last Info field of Execute Job holds the log of the last execution and the Details tab holds row-level messages. For source jobs, double-click the Attribute String and Error Message columns, fix what is fixable and use Restart Online. If the error comes from the input file, use Clean Up and run the corrected file from the start. When the cause stays unclear, open the Debug Console before restarting and read the trace of the Start_Job call. The business logic messages are the same ones you would get typing the record by hand, and entering a similar record manually with the console open is the documentation's own tip.

Errors that never appear in these places, such as a wrong unit conversion that loads cleanly, are described in the silent killers article, and the reconciliation list below is how you catch them.

A load is reconciled when counts and values in IFS Cloud match an agreed figure from the source, per target table, and someone other than the loader has signed it.

1. Row counts per stage: legacy rows loaded, rows by Data Status in the Input Container, approved rows in the Output Container, rows deployed with commit. Every difference has a reason: excluded, duplicate or error.
2. Excluded records: each Exclude from Transfer carries an Exclude Comment, so the list is explainable.
3. Control totals: stock quantity and value per site, open order value, open invoice balance, compared with the legacy report on the cutover date.
4. Sample check: a set of records opened in the IFS Cloud client and compared field by field with the source, including units of measure and statuses.
5. Referential check: no deployed record points to a code or parent that is missing or unapproved.
6. Repeatability: a repeated rehearsal produces the same counts.
7. Sign-off: the data owner confirms the reconciliation sheet, which then feeds UAT. A tracker for it is in the UAT test tracker template.

Book a 30-minute migration call Professional data migration services

• IFS Cloud Technical Documentation 25R1, Data Migration Manager. The pages read for this guide: Define Migration Project, Migration Scope, Target Table Definition, Legacy Source Data Import, Map Legacy Data Target Table, Input Container, Output Container, Basic Data Container, Deployment Container and Schedule Migration Jobs. The Extra Configurations page was not read.
• IFS Cloud Technical Documentation 24R2, Data Migration. The pages read: the Data Migration overview, Execute Job, Excel Migration, Migration History Analysis, Authorized Users, Known Limitations, Handling Error Messages and Debug Info, and Parsing Variables Between Methods.
• IFS Community threads: best practices for 24.1.3, permission sets for migration jobs, deleting data with migration and a missing migration object in the Deployment Container. These are user and staff answers, not release documentation.

The documentation text was read as published for 25R1 and 24R2 and was not tested against a live system for this article. Menu paths are given only where the documentation states them. Permission set names come from community answers, and the details above (container sizes, source priorities, flags, wizard pages, menu paths) can differ between releases, so confirm each against your own IFS Cloud version and test environment before relying on it.

Dariusz Myśliwiec: 18 years hands-on with IFS (Apps 7.5–10 and IFS Cloud), including data migrations with FndMig and Data Migration Manager. IFS Certified Associate Consultant. PRINCE2® 7. Based in Kraków, delivering remotely across Europe and globally as an independent practice, so you talk to the consultant who does the work.

Selected clients: Betafence (PRÆSIDIAD) · Newag · RADPOL · Fugro · NGK Ceramics · ATLAS.

IFS is a registered trademark of IFS AB; this practice is not affiliated with IFS AB.