MDS Direct Migration connects Primentra to your Master Data Services database and reads it. You pick the models, check a dry run that writes nothing, and start the run. Primentra then creates the models, entities and attributes and loads the members, in one run. When MDS changes later, you run it again, and only the changes move.
We built it because the older route has too many hands in it. MDS Manual Import asks you to run a script on the MDS server, save the result, upload it, and do the same for the data. That works, and it stays for servers that Primentra cannot reach. But while you test Primentra, people keep editing in MDS, and every change meant another round of files.
What you need
- A SQL Server login that can read the MDS database. A read-only login is the safe choice. Primentra warns you when the login can write, and it never writes to MDS either way.
- A network path from the Primentra server to the MDS server. The server makes the connection, not your browser.
- MDS 2016 or newer. The database list shows the schema version and the MDS release of each database.
- The Administrator role in Primentra.
Windows sign-in to the MDS database does not work yet, so it has to be a SQL login. If nobody can give you one, use MDS Manual Import: it runs on the same engine, only the first step differs.
Five steps, and the last one twice
- Connect. Type the server and the login, or paste a connection string. Test connection tells you at once whether the login works.
- Database. Primentra lists the databases on that server that hold MDS, with the number of models in each.
- Options. Which MDS version to read, what to do with members that are gone from MDS, and what to do with values that do not fit.
- Select. A tree with every model and entity, all selected. Clear what you do not want. An entity that another selected entity links to stays selected and says which one needs it, so you cannot break a link by accident.
- Run. First a dry run. Then the run itself.
Every step is described in full in the MDS Direct Migration docs.
The dry run is the part that matters
The dry run reads MDS, compares every member with what Primentra holds, and writes nothing. You get one row per entity with six counts: New, Changed, Unchanged, Conflicts, Gone and Refused. Zeros are gray, so the numbers that need you stand out.
Under the counts sits the problem list. It names every member that would stay out and why, sorted into Blocked (did not come across), Warning (came across, but changed) and Info (MDS features we list for you, such as business rules). You can download it as CSV, Excel or JSON and hand it to whoever owns the data. The run itself cannot start until a dry run has finished.
Values that do not fit
Old master data has corners. By default the run refuses a row it cannot hold as it is, because a silently changed value is worse than a missing one. On the Options step you can choose otherwise, per kind of problem:
| What MDS has | By default | Or |
|---|---|---|
| More than 10 decimals | The row stays out | Round to 10 decimals |
| Text longer than the column | The row stays out | Cut the text to fit |
| A number with 13 or more digits before the point | The row stays out | Load the row, leave that value empty |
| A link to a member that does not come across | The row stays out | Load the row, leave the link empty |
| A member without a Name | The Code becomes the Name | Leave the Name empty |
Every value that loads with a change shows up in the problem list next to what MDS had. A Code that is too long is always refused: cutting it could turn two members into one.
Run it again when MDS changes
This is the part the file-based route could never do well. Pick the saved connection, click Run again with the same settings, and you get a new dry run with the database, options and selections of the last run. A model that Primentra already holds is merged: new members go in, changed members are updated, and unchanged members are not touched.
A member that changed in both places is a conflict. The problem list names the column. By default MDS wins that column; select Keep the Primentra values on a conflict for an entity to keep your Primentra edits instead. Members that MDS no longer has are counted as Gone, and they are only deleted when you switch that on.
On our test machine, an entity of 1,000,000 MDS members loaded in about 12 minutes. After we renamed two of those members in MDS, the second run finished that entity in 170 seconds and wrote exactly two rows. It is a test PC with SQL Server on the same box, so read the numbers as a scale, not a promise.
Users, permissions and views come along
MDS users and groups become Primentra users and roles, with their permissions on what the run migrates. MDS and Primentra do not reason about permissions the same way: in MDS a Deny beats everything, in Primentra the highest permission of a user's roles wins. So the run compares what each user could do in MDS with what Primentra allows afterwards, entity by entity and column by column, and lists every user who would get More access. Check those first.
MDS subscription views of the leaf attributes become Integration Views with the same name and the same columns. An ETL job that read the MDS view only needs a new connection.
What stays behind
- Business rules. The problem list names each one with its IF, THEN and ELSE text, so you can set it up again in Primentra.
- Deactivated members. Only active members migrate.
- Derived hierarchies, collections, file attributes, annotations and the transaction log.
The full list, and how each MDS data type maps, is in the Migration Overview.
And if a run goes wrong
Cancel run stops after the batch it is working on, and Resume carries on at the step that stopped. If the database refuses rows for a reason nobody foresaw, the run finds the row, sets it aside with the database message, and loads the rest. An entity with too many of those stops on its own, so one bad table cannot fill your problem list with a million lines. Undo this run takes the whole run back, and first shows you what it will remove.
For the bigger picture of leaving MDS, from the timeline to the choice of a replacement, start with our guide on how to migrate from Microsoft MDS. After the run, the After Migration checklist covers what to check before your users move over.