After Migration
Both wizards report what they wrote, but neither checks whether the result is correct. Work through this list before you let users into the migrated data.
1. Check the row counts
Open each entity in the grid and compare the record count in the status bar with the count in MDS. A gap usually means one of these:
- A line in the NDJSON file was truncated. The wizard warns about this on upload.
- Rows were skipped because their Code already existed and the action was Import.
- The entity was left on Skip in the preview.
2. Check the domain columns
An unresolved domain value is dropped silently. Sort or filter each domain column on empty values, and compare with the source.
The usual causes are a target entity that was imported later than expected, a Code that changed between the two systems, and a display value that matches neither the Code nor the Name. See Domain Attributes & Hierarchies.
3. Validate the business rules
Business rules do not migrate, and the import does not enforce the rules you already have. Legacy data is expected to break them.
- Create the rules you need — see Creating a Rule from Templates.
- Run validation per entity and use the row filter to show only failing rows — see Validating Entities.
4. Finish the entity configuration
The structure import cannot carry every setting across. Check each entity:
- Requires approval is off on every imported entity, even when the MDS entity required approval. Turn it back on where you need it, and assign approvers — see Configuring Approvers.
- Required and unique flags, date and time formats, and column order are worth a second look — see Attributes & Data Types.
- Column widths are not migrated.
5. Set up access
MDS users, groups and functional area security are not migrated. Until you configure roles, only administrators can see the new entities.
- Create or review the roles — see Roles & Permissions.
- Create the users — see User Management.
- Check the result with the Permissions Report.
6. Create the integration views
MDS subscription views are not migrated. Primentra's integration views are created per entity and are not generated automatically, so a migrated entity starts without one. The Integration Views screen lists every entity that has no view yet — see Integration Views.
Known difference: Code and Name attributes
An entity imported from MDS carries two extra rows in its attribute list: one flagged as the code attribute and one flagged as the name attribute. An entity created inside Primentra does not have them, because Code and Name are built-in columns there.
The rows are metadata only. They hold no data, and the migration never writes a value to them.
Where you can see the difference:
| Place | What you see |
|---|---|
| Data grid | No difference. Code and Name are normal columns |
| Entity form | No difference. The attribute list hides them |
| Permission tree | Both appear, greyed out, tagged CODE and NAME. They cannot be given a permission |
| Model schema export | They are included, so an imported entity produces a different export file from an identical native entity |
Nothing needs to be done about this. It matters only when you compare a model export of an imported entity with one of an entity you built by hand — see Model Export / Import.
Re-running a migration
Both wizards can be run again. The structure wizard offers Skip or Overwrite per existing entity, and the data wizard offers Overwrite or Delete + import. To start from an empty database instead, reinstall and run the wizards from the beginning.
Related
- Migrate Master Data — the import this page follows
- Validating Entities — finding the rows that break your rules
- Integration Views — replacing MDS subscription views
- Roles & Permissions — giving users access to the migrated entities
- Entity Management — cloning, renaming and deleting after the import