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 conditional rules, and where I will not oversell
Now the honest part. Primentra has no business rules engine. There is no IF-THEN builder, no cross-attribute condition, no regex field, no computed default. A declarative conditional engine is on the roadmap, not in the product today, and I would rather you hear that from me now than discover it in week three of a migration. So what do you do with the conditional rules that survived your inventory? There are two real answers, and between them they cover almost everything.
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 a rule engine was always a clumsy way to enforce it. Primentra's requires-approval workflows handle that directly: an editor's changes are held as pending changes, an approver who is not the author reviews the diff, and nothing reaches live data until they approve it. That catches the same cases a conditional rule would have flagged, except the check is a person who can tell a real exception from a typo, which a regex never could.
The few rules that are true cross-field invariants, the ones that must hold every time with no human judgment involved, belong in a stored procedure. Primentra already runs its validation in usp_Data_SaveRow, so a cross-field check lives in the same place, written in T-SQL, kept under source control, applying to every write path. For a team coming off MDS that is familiar ground: it is where your DBAs already work, and a rule in version control beats a rule buried in a GUI nobody can diff or review.
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?
No, and it is worth being direct about that. There is no IF-THEN builder, no cross-attribute conditions, no regex, no computed defaults. A conditional rules engine is on the roadmap, not in the product today. What it does have is declarative attribute constraints enforced at four layers, plus requires-approval workflows for the judgment calls a rule engine cannot make.
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?
Not declaratively today. Most conditional rules are really governance, and a requires-approval workflow handles those with a reviewer who can tell an exception from a typo. The few that are true cross-field invariants belong in a stored procedure, alongside the validation Primentra already runs, written in T-SQL and under source control. A declarative conditional engine is on the roadmap.
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, then adds changeset-based approvals for the calls a rule engine cannot 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.