Data deployment is not solution deployment (11/15)

Solutions move metadata and components. They do not move your business data, and they should not try to. Yet many releases depend on records being present: a list of categories, a set of approval rules, a configuration table. That data needs its own plan.

Why mixing the two goes wrong

When data travels as an afterthought, the same problems keep appearing: broken lookups, duplicate records and, worst of all, an update that overwrites production values someone changed on purpose.

None of these show up in the solution import. They show up when a user opens a record and something is missing or wrong.

Classify before you move anything

I sort the tables a release touches into four groups:

• Configuration — settings the app needs to behave correctly. Usually deployed.
• Reference — lists like categories or regions. Deployed, but carefully.
• Transactional — real business records. Almost never moved between environments.
• Environment-owned — values that legitimately differ per environment. Never overwritten by a release.

The classification decides the method. It also stops the "it's only a small table" assumption.

How to deploy data reliably

1. Order by dependency. Load parent tables before the tables that look them up.
2. Use stable keys. Alternate keys let you upsert records consistently instead of relying on GUIDs that differ between environments.
3. Use tooling that reports. Whatever you use should validate, upsert and tell you exactly what changed.
4. Back up and rehearse. Back up the target and test the migration on a representative copy before production.

I treat data migration as a release component with its own evidence. If the feature depends on records being there, the runbook needs more than a solution import.

A practical next step

Make a short table of the first five tables your releases move between environments, with a classification and a method for each. You will probably find at least one being moved that should not be.