MDS model versions: what you actually used them for, and what replaces them

Ask a team what their MDS versions are for and watch what happens. There is a pause. Then someone explains the versioning strategy the implementation partner set up in 2019, and someone else says yes, but we only ever edit VERSION_4. The other three sit there committed, read-only, untouched since the quarter they were frozen. Nobody has opened them in years. Nobody is willing to delete them either.

Versions are the MDS feature teams are most anxious about losing and the one they used least. That combination is worth pulling apart, because the anxiety is not really about versions. It is about four separate jobs that versions were doing, badly, all at once. Three of them survive a migration in better shape than they were. One does not, and I would rather say so plainly than sell you a workaround.

What an MDS version actually was

The unit of versioning in MDS was the model. Not the row, not the attribute, the whole model with every entity and every member inside it. A version had a status: Open meant editable, Locked meant frozen while somebody reviewed it, Committed meant sealed and read-only forever. To start a new cycle you copied a committed version, which gave you a fresh Open version carrying a full duplicate of the data, and off you went again.

Underneath, the version was a column. Every member row carried a version ID, subscriber views were bound to a version or to a version flag that pointed at whichever version was current, and the flag was how you swapped what downstream systems saw without touching their queries. That design assumed a governance rhythm: open a version in January, make the quarter's changes, lock it in March, review, commit, move the flag, repeat. For an organization that worked in quarterly cycles, it was coherent.

Almost nobody works in quarterly cycles. Master data changes on Tuesday because a supplier changed their bank details on Tuesday. So the model of the world that versions encoded was wrong for most estates from the first week, and what teams did instead was keep one version open permanently and use the mechanism for whatever else it happened to be good at.

The four jobs versions were really doing

Before you ask any vendor how they replace versions, work out which of these you are actually doing. The answer is usually one, sometimes two, never all four.

Staging a big change: approvals do this better

This is the most common one. A reorganization is coming, six hundred cost centers need to move, and nobody wants that half-finished in live data. So you copy the version, do the work in the copy, and swap the flag when it is done.

It works, and it is a blunt instrument. You froze an entire model to protect six hundred rows. Everyone else's routine edits either queue behind your project or land in the old version and have to be reconciled into the new one afterward, which is the step that goes wrong. And the copy itself was slow on any model of size, slow enough that teams scheduled it overnight.

Changeset approvals do the same job at the granularity the job actually has. On an entity that requires approval, an editor's changes are held as pending changes that are not live. An approver who is not the author reviews the diff row by row and approves or rejects each one, and only approved rows reach live data. Your six hundred cost centers sit in review while everyone else's Tuesday edits flow through untouched. There is no copy, so there is nothing to reconcile.

Publishing downstream: the flag becomes a view

The version flag was genuinely good design. Downstream systems queried a subscriber view bound to the flag, you moved the flag, and every consumer saw the new data without a single query changing. That indirection is the part worth keeping.

You keep it with a view, which is what the flag was standing in for. Primentra deploys integration views as real SQL Server views over the governed data, and consumers query those instead of the tables. The contract with the downstream system is the view's shape, which you control, so the model underneath can change without breaking anybody. If nothing reaches those views until it is approved, the view is already the stable surface the committed version was giving you, except it is stable continuously rather than once a quarter.

Point-in-time: the job versions never really did

Some teams kept committed versions as history. What did the cost center structure look like in Q2? Open VERSION_2 and read it. It sounds right and it mostly did not work, because versioning at model granularity is the wrong shape for the question. Comparing two versions meant comparing every entity in both, custom queries, and enough waiting that people stopped asking. The teams that needed real point-in-time reporting gave up on versions and built an SCD Type 2 layer in the warehouse. That is where their master data history actually lives today, and it was never in MDS.

So when you migrate, check what you are really losing here. If the requirement is “an auditor asks who changed this supplier's bank details and what they were before,” the audit log answers that directly, per attribute, with the user and the timestamp, and it answers it for every change rather than for the four you happened to freeze. If the requirement is a revenue-by-region report rerun as of last December across a million rows, that is a temporal model, and it belongs in the warehouse whether you are on MDS or not. Neither of those is a version. Both got called versioning.

What-if experiments, and the one thing I will not pretend about

The fourth job is trying something out. What would the hierarchy look like if we split the EMEA rollup? Copy the version, restructure, look at it, throw it away. For structural experiments Primentra has Clone entity, which duplicates an entity with its attributes and data so you can reshape the copy, and Model Export/Import, which moves a whole model's structure between environments. Do the experiment in a test environment, export what survives, import it into production. That is a better loop than experimenting inside production behind a version flag, which is what MDS quietly encouraged.

Now the part I will not dress up. Primentra has no model versions. No version flag, no copy-version, no committed read-only snapshot of a model, and no roadmap promise I am willing to make on this page. It holds one live model, governed by approvals and recorded by the audit log. If you sort your four jobs and find that what you need is genuinely the fifth thing, a frozen quarterly snapshot of an entire model that people can open and read years later, then this is a real gap and you should know it now. In practice I have not met the team that needed that and could not get there with an approved model, an audit log, and a database backup. But I have met teams who thought they needed it because it was the feature they had, which is a different thing.

Do not port the versions. Port the intent.

The migration question people ask is how do I keep my versions. The better one is what were the versions for. Once you split them into staging, publishing, history, and experiments, each piece lands somewhere clearer, and most of them land somewhere better than a whole-model copy that ran overnight.

The committed versions themselves are usually the easiest call of the migration. Take the current open version, migrate that, and keep the old MDS database read-only somewhere cheap for as long as your retention policy says. Nobody has queried VERSION_2 since 2021. Migrating it costs you weeks and buys a comfort blanket. If you are still scoping the migration, deciding this early is worth doing, because “all versions” and “the live version” are very different projects.

Common questions