The first real task in most MDS migrations is not the data. It is the export where you finally see how many business rules the model has grown. I have watched a team open that list and count 240 of them, and then go quiet, because nobody in the room could say which ones still fired, which two contradicted each other, or which had been switched off during a project three years ago and never turned back on. That pile is the part everyone dreads recreating. The good news, which takes a minute to believe, is that most of it should not be recreated at all.
MDS business rules do not export. There is no file, no script, no clean handoff. They live inside the MDS database, bound to a model and a version, and whatever you decide to keep you re-express by hand in the new platform. That sounds like bad news. It is the opening you need, because it forces the one question a migration is the only good time to ask: does this rule still earn its place?
What an MDS business rule actually was
MDS gave you a point-and-click rule builder: a set of IF conditions, a set of THEN actions, and a priority order. On paper that is a real conditional engine. In practice, almost every rule people built came out as one of a handful of shapes. This field must have a value. This value must be unique. This must come from that list. This must be a decimal with two places. This must be positive. This must not exceed forty characters.
The genuinely conditional rules existed too, the ones where the requirement on one field depends on the value of another. They were also the ones that hurt. MDS could not reach across entities in a condition, the expression language ran out fast, and validation on a large model was slow enough that many teams stopped running it on save and ran it on a schedule instead. That last compromise is the quiet one. A rule that only runs Sunday night is not a rule that prevents bad data. It is a report that tells you which bad data got in.
Inventory before you rebuild
Before you map a single rule to anything, list them all with three columns: does it still fire, what does it enforce, and is it attribute-level or genuinely conditional. This takes a day. In every estate I have seen it pays for itself several times over, because the honest answer to the first column is usually that a large share of the rules are dead. Duplicates. Rules disabled and forgotten. Rules guarding an attribute nobody populates anymore. Two rules that quietly disagree, where whichever has the higher priority wins and the other has been a no-op for years.
You do not want to carry that across. Porting a pile of dead rules into a new system just relocates the mess, and it buries the ten rules that matter under two hundred that do not. Sort first, migrate what survives.
Where the simple rules land
The attribute-level rules, which is most of them, stop being rules at all. In Primentra they are properties of the attribute, set once when you define the field and enforced from then on without a rule to maintain.
The difference that matters is not the mapping, it is where the check runs. Primentra enforces these constraints in four places: as you type in the grid, again when you save, again in the usp_Data_SaveRow stored procedure, and again while a batch loads through import and staging. A bulk load cannot slip past them and an API write cannot either, because the last line of defense is the stored procedure every write path goes through. That is the specific gap MDS left open: staged members could enter the model unvalidated until someone ran validation, and by then they were already in.
The last three rows of that table are business rules rather than attribute properties, and they run on the same write paths — though not in the same way on each. A grid save that breaks a rule is refused outright. A staged row is written, found, and put back. A file import refuses the bad rows or loads everything and counts them, depending on how you set that import. The differences are deliberate, and worth knowing before you plan an ETL feed around them.
The conditional rules, and what changed three weeks after I wrote this
This section used to say Primentra had no business rules engine, and that conditional rules had to go to an approval workflow or into hand-written T-SQL. That was true when I published this in July. It stopped being true in August, when the rules engine shipped. I am leaving the old advice visible in outline rather than quietly deleting it, because if you read this post in July and planned around it, you should be able to see exactly what moved.
A rule is now two boolean trees: an IF and a THEN, each able to combine several columns with AND, OR and NOT. IF Country is US THEN State must have a value is a rule you build in the interface, not a stored procedure you maintain. So the conditional rules that survived your inventory now have somewhere native to land, which is a better answer than either of the two I gave in July.
One of those two answers still stands, though, and it is the one worth keeping. Most conditional rules are governance wearing a rule's clothing. “A new supplier cannot go live until someone checks the bank details” is not a validation expression, it is a review step, and an engine is a clumsy way to enforce it however good the engine is. Primentra's requires-approval workflows still handle that better than any rule can: an approver who is not the author reviews the diff, and a person can tell a real exception from a typo. Sort your inventory into the two piles before you start rebuilding. Expressions go to rules, judgment goes to approval.
The T-SQL advice is the part I would now skip. Writing a cross-field check into a stored procedure still works, and it is still familiar ground for a DBA, but you are maintaining by hand something the engine evaluates on every write path anyway, and a rule in the builder is visible to the steward who has to live with it.
Migration is a chance to prune, not to port
The instinct is to recreate all 240 rules so that nothing is lost. Resist it. You lose nothing worth keeping by rebuilding the ten that matter and dropping the rest. What you lose is the clutter that made the model impossible to reason about. Keep the rules that enforce something real and express them as attribute properties. Move the conditional exceptions into approval, or into T-SQL if they are genuine hard constraints. Let the dead ones stay dead.
A migration is the one moment you have standing permission to ask of every rule whether it still earns its place, because you are re-expressing it anyway. Most teams never get that permission again. Spend it well, and the model you land on the other side is smaller, faster to validate, and finally something a new steward can read. If you are still mapping out the migration, the rule inventory is a good place to start, because it tells you how much of what you built you still use.
Common questions
What happens to my MDS business rules when I migrate?
They do not export. They live inside the MDS database, tied to a model and a version, with no clean file to carry across. So you re-express intent rather than move rules. Most of what a rule enforced becomes a property of the attribute, not something you rebuild. The conditional rules are the real work, and most of those are governance decisions better handled by an approval step.
Does Primentra have a business rules engine like MDS?
Yes, since August 2026. A rule is an IF tree and a THEN tree over the entity’s own columns, with 35 operators across text, numbers, dates and domain values. It covers conditional requirements, cross-attribute comparison, ranges, format masks and uniqueness on a combination of columns. It does not do computed defaults, and its regex operator is checked in the browser and on the API rather than in the database, because SQL Server has no regex engine.
How does Primentra stop bad data without a rules engine?
Through attribute constraints enforced in four places: as you type, on save, in the usp_Data_SaveRow stored procedure, and during import and staging. Required fields, data types, code uniqueness, and domain references are checked on every write path, so a bulk load or an API call cannot slip past them. Anything needing human judgment goes through an approval workflow instead.
Can I enforce a conditional rule like IF Country = US THEN State is required?
Yes. That is the shape the builder is built around. The IF side and the THEN side are both boolean trees, so the IF can combine several columns with AND, OR and NOT. Set the rule to error and the save is refused; set it to warning and the row is written and marked instead. Governance questions that need a person rather than an expression still belong in an approval workflow.
Rebuild the rules that matter, drop the ones that never did
Primentra enforces data types, required fields, code uniqueness, and domain integrity at the point of entry, on save, in the stored procedure, and during import. On top of that sits the business rules engine for the conditional and cross-field cases, and changeset-based approvals for the calls no engine should make. It runs on your own SQL Server, deploys in a day, and costs €7,500 per year flat. The 60-day trial is long enough to migrate one real entity and see what your rule pile looks like once it is sorted.