You build and test a new attribute in development. The schema works. The data validates. You export it and import it to production. The import succeeds. Then a week later someone asks why the new field is empty in production, and you realize the data never left test.
Model promotion isn't a single operation. It's at least two: the schema change and the data change. They have different constraints and different dangers. Separating them keeps production from becoming a mirror of test, or test from overwriting production by accident.
The five phases
A safe promotion follows this order. Skip any of them and you pay for it later.
Step 1Model in test, data in test
You build and validate the schema change in test with toy or sample data. No production exposure yet.
Step 2Validate against production data
Copy production data into test without overwriting test. Run the schema change against it. Does it work? Do any rows violate the new constraints?
Step 3Check downstream impact
List every system that reads the model or depends on a published view. For each one: Does the schema change break it? Can it handle renamed or deleted attributes?
Step 4Promote schema only
Export the model without data from test and import it to production. The schema lands, data stays where it is.
Step 5Promote data separately (if at all)
If the test data is the real data you intend to use in production, export and import it as a separate step after the schema is live and integration breakage is fixed.
Five things that break
Each of these happens because the schema change and the data move as separate events.
Data rows violate the new constraint
You add a uniqueness constraint but two production rows have the same value. The constraint import succeeds, the data already there stays unchanged, but the first time someone tries to edit either row they hit a validation error they cannot explain. Fix: test the constraint against a copy of real production data first.
An integration view depends on a deleted or renamed attribute
You delete an attribute and export the model. The schema import succeeds. The integration view tries to select from a column that no longer exists. Downstream systems get a SQL error and stop pulling data. Fix: find every downstream consumer before you promote, tell them what changed, and coordinate.
A downstream system caches field metadata
An external tool cached the attribute list or the field order at startup. You rename an attribute and promote the model. The cache still points to the old name and nobody notices until a steward tries to use the new field and it does not appear in the export. Fix: tell every consumer when the metadata changed and ask them to refresh or restart.
The test and production models diverge
You promote the schema to production and leave the data in test. A change lands in test later and gets promoted, but a different change landed in production in the meantime. Now the two environments have different model definitions and neither is the source of truth. Fix: pick one as the source, make the other a copy, and promote from source to copy.
Test data overwrites production data silently
You export test data (thinking it is sample data) and import it to production, choosing the "overwrite" action. Real supplier records disappear and are replaced with toy records called "Supplier A", "Supplier B", and "Test Corp". Fix: never run an overwrite import to production without asking "is this data real and production-ready?"
How to promote safely
Export the model without data
Every model export tool has an "include data" option. Leave it off. The schema lands in production, the data stays where it is. This is safe because:
- The production data is real and was already validated
- Test data is toy data and overwriting production rows with it is data loss
- If the new schema has constraints, they will be evaluated against production data when the import runs — you catch the problem before it lands
- You can run migrations or backfills to populate new attributes after the schema change succeeds
Test the schema change against production data first
Before you import anything, make a copy of the production database in test. Apply the schema change to that copy. Does it work? Do any production rows violate a new uniqueness constraint or fail a new validation rule? You need to know before the change is live, not after.
This catches 90% of the breaking changes. The other 10% are downstream integrations that don't know the schema changed.
Find every downstream consumer
List every system that reads the model or depends on a published view. For each one, ask:
- Does it use the attribute I am renaming or deleting?
- Does it depend on a specific field order?
- Does it cache the attribute list or the view definition?
- Does it enforce the old constraint, so a new constraint would break it?
- Is the integration view on the list of things I am promoting?
If any answer is yes, tell the owner before you promote. Coordinate with them on the order of changes. A one-hour heads-up prevents a one-week incident.
Import with conflict resolution set to "skip" or "merge"
If production already has a model with the same name, the import tool asks how to handle it: overwrite, skip, or merge. Never pick "overwrite". That replaces the production model with the test version and deletes any entities or attributes that exist in production but not in test.
Pick "merge" or "skip" depending on what changed. Merge if the test version is a superset of the production version (new attributes, new hierarchies, new business rules). Skip if you want to run the change manually or need to coordinate with a deployment. Let the tool tell you about conflicts before anything is committed.
Promote data separately, if at all
If the test data is the real data you intend to use — a fresh load or a corrected historical record — promote it as a separate step after the schema is live and downstream systems have been updated. Use a two-step workflow:
- Export the model schema only and import to production
- Verify the import succeeded and that no downstream system is broken
- Notify downstream consumers that the model changed
- Export the data from test and import to production (separate operation, separate approval, separate records)
- Update documentation with the new data source and the date the change landed
If the test data is not real — just sample data you built to validate the schema — do not promote it at all. Leave it in test where it belongs.
The hard part
The hard part is not the promotion. It is knowing what you are promoting. Most organisations do not know which downstream systems depend on which views. They do not know which attributes an external tool caches or how many places depend on a specific field order.
That discovery usually happens after the model changes land and the system stops working. The time to find out is before you promote, when you still have the option to coordinate or delay.
On the project plan, add a line item: "map all downstream consumers". Put it before promotion week. Give it a person. It takes an afternoon and saves a weekend.
Questions
What if the production model is too different from the one in test?
Then test and production have diverged, and you have two problems: decide which is the source of truth, and make the other a copy of it. This usually means choosing production as the source (because it has real data) and re-running any pending changes against a copy of production. It is more work than keeping them in sync, which is why the separation of schema and data matters — you can catch the divergence before it is a disaster.
Can I promote just one entity or attribute?
Yes, if your export tool supports filtering. Export only what changed, and handle conflicts carefully. The risk is higher because you are less likely to catch everything downstream that depends on just that one thing. It is safer to promote the whole model and let the tool figure out what actually changed.
What if I am using MDS and exporting a package with MDSModelDeploy?
The same rules apply. Export the package without data (no -includedata flag), test the deployment against a copy of real production data, and coordinate with downstream systems before you run the import. MDSModelDeploy does not export permissions or file attributes, so those need manual coordination anyway.
Should I have a staging environment in addition to test and production?
Only if your model changes are complex enough that they need a full validation run with real data and real integrations before production. Most organisations do not need it. You can simulate staging by making a production data copy in test, applying the model change there, and running integration tests. Commit to staging only if your change-management process genuinely requires it.
What if a constraint import fails?
The import stops. The good news: the schema change did not land. The bad news: you now have a constraint that does not apply to your production data, and you have to either remove the constraint, fix the production data, or both. This is why testing against a copy of production data first is not optional.
Test model changes safely on your own SQL Server
Primentra lets you validate schema changes against a copy of real production data before the change lands. No model promotion goes live until it has been tested against the data that will have to live with it.