Reference-Data
Migration Governance: What Moves, What Doesn’t, and Why

Category: Business-Rule Documentation,
Data-Dictionary Development & Migration Sequencing

Every system migration or environment promotion involves a question
that’s easy to underestimate: not “how do we move the data,” but “which
data should move at all.” This case study looks at a real reference-data
export/import procedure where the answer wasn’t “everything” - it was a
deliberately curated subset, with the exclusions documented as
explicitly as the inclusions.

The Procedure

The platform stored its configuration as a set of reference data
objects - lookup tables that drive dropdowns, workflow routing, status
colors, and business rules throughout the application. When promoting a
validated release from a test environment to production, the standard
procedure was:

  1. Select all reference data objects as the starting point
  2. Auto-calculate the dependency/load order (so tables with foreign-key
    relationships import in the correct sequence)
  3. Explicitly exclude a fixed list of object
    categories from the export
  4. Export the remaining set, including any attached files, as a
    package
  5. Import that package into the target environment

The
Exclusion List Is the Real Governance Artifact

Ten categories were excluded from every promotion, each for a
distinct reason:

Excluded category (generalized) Why it’s excluded
Audit log data Audit trails are environment-specific by design - importing a source
environment’s audit history into a target environment would misrepresent
what actually happened there
User/employee records and user-import staging data User accounts are managed per-environment (test users differ from
production users); overwriting production user data with test data is a
data-integrity and security risk
Workflow request-status and request-type lookups (two
categories)		 These are typically already correct in the target environment and
are more likely to have been independently updated there since the last
promotion - overwriting them risks reverting a live configuration
change
System-user lookups tied to environment-specific accounts Same rationale as user records - these values don’t have a valid
meaning outside the environment they were created in
Sequence-tracking data Sequence counters must reflect the target environment’s actual
current state, not the source environment’s - importing this would risk
ID collisions
System configuration and system email-recipient lists These are deliberately maintained separately per environment (e.g.,
production email recipients should never be overwritten with
test-environment recipients)
System run-once log This is a record of what has already executed in that
environment - importing it from elsewhere would falsely mark
target-environment tasks as already complete

Why This Matters
as a Consulting Deliverable

This exclusion list is, functionally, a data dictionary
decision framework: for every category of reference data,
someone had already answered “does this belong to the environment or to
the release?” and encoded that answer into a repeatable checklist rather
than re-deciding it by hand on every promotion.

That distinction - environment-owned data versus
release-owned data - is the reusable pattern here, and it
generalizes well beyond any one platform:

Takeaway for Clients

Any organization migrating data between environments - test to
production, old system to new, on-prem to cloud - benefits from making
this same distinction explicit and documenting it once, rather than
re-litigating “should this table move?” on every migration. A one-time
exclusion-list exercise, revisited only when the data model changes,
turns a judgment call into a repeatable, auditable procedure.