Back to blog
PrimentraPrimentra
·February 25, 2026·6 min read

Managing master data structures in MDS vs Primentra: what actually changed

Home/Blog/Managing master data structures in MDS vs Primentra: what actually changed
Attributes — Branch entity
CodeTextSYSTEM
NameTextSYSTEM
Product CategoryDomain
Renewal DateDate
StatusDomain
Drag the grip handle to reorder — system attributes stay locked at the top

MDS got a lot right. SQL Server-native, it handled large attribute sets, and for many teams it ran master data operations for years without much complaint. But managing the structure of your data — not the records, but the model itself: attributes, permissions, environments — was a different experience. Slow, and confusing in ways that were hard to articulate until you used something better.

Three things stood out when we built Primentra.

1. Reordering attributes

Attribute order matters more than it looks. It controls what your data stewards see first in the grid, the column sequence in export files, and the field order in the approval diff view. Models change, priorities shift, and suddenly the attributes your team uses most are buried at the bottom behind six fields nobody looks at. For a complete overview of how models, entities, and attributes fit together, this post covers the full data model.

Fixing this in MDS meant clicking the up arrow. Once per position. With a mandatory wait after each click while the page reloaded — call it five seconds minimum. Move an attribute up 20 slots and that's 100 seconds for one column. Do that for five attributes and you've spent eight-plus minutes doing nothing but clicking and staring at a loading screen. That math is real. We ran it.

In Primentra you grab the grip handle and drag. Or use the up/down arrows if you prefer. System attributes (Code, Name, the audit timestamps) are locked at the top and won't move. Everything else goes where you put it. A full reorder of a complex entity takes maybe two minutes.

2. Assigning permissions

MDS permissions were genuinely hard to reason about. The model/member/collection hierarchy, the colored squares meaning explicit vs inherited vs deny, the separate handling of leaf members vs consolidated members. I've watched data architects who used MDS daily spend 20 minutes diagnosing why a user could open a model but couldn't edit anything. The answer was always buried two levels into the permission grid.

Primentra uses the same three-level structure (model, entity, attribute) but the interface is meant to be read at a glance. Each entity has four toggles: Create, Read, Update, Delete. The logic is straightforward: turn on Create and Read enables itself automatically, because you can't create a record you can't see. Turn off Read and everything else follows. No hidden state, no squares to decode.

Inherited permissions show with a dashed border so you can immediately see what's coming from the model level versus what's been explicitly set on the entity. Attribute-level permissions default to "inherit from entity" — you only touch them when you need field-level control on specific columns.

Everything is on one screen. No tabs to hunt through, no separate member type trees.

3. Moving data between environments

Promoting from UAT to production in MDS was its own project. There was no export button. If you wanted to move entity data from one instance to another, you either wrote T-SQL scripts against the staging tables, found someone who'd done it before, or rebuilt everything by hand in production. Most teams had one person who knew the process. When that person left, so did the knowledge.

In Primentra, exporting entity data is a button in the data grid. Pick JSON or CSV, download the file. The JSON format matches exactly what the import wizard expects on the other end, so there's no conversion step. Open the import wizard in production, upload the file, choose your action per entity — add new rows, overwrite everything, or skip — and run it. The file from UAT goes straight into PRD.

You can also import without data — bring the entity structure across and leave production data empty until you're ready to populate it. That's the schema migration wizard, which handles models, entities, and attributes. The data wizard handles rows. They work independently, so you're not stuck with one all-or-nothing move.

No scripts, no tribal knowledge, no spelunking through staging tables.


None of this is revolutionary. It's just the table stakes for a tool that doesn't make you fight the interface to do routine work. If you're looking at Primentra as a Microsoft MDS alternative, the structure management is worth trying early — most people notice within the first session. For a complete picture of what migration from MDS looks like, the MDS migration guide walks through every step.

More from the blog

Your MDS Excel Add-in Stopped Working. Here’s What Happened — and What to Use Instead.8 min readHow to Migrate from Microsoft MDS: A Practical Guide to Your Best MDS Replacement15 min readMaster data without an audit trail is a liability8 min read

Ready to migrate from Microsoft MDS?

Join the waitlist and be the first to try Primentra. All features included.

Download Free TrialTry DemoCompare MDM tools