Software migration and cutover · Troubleshooting · intermediate

PMS migration rejected-record register

Keep skipped, transformed, duplicated, quarantined, and manually corrected records visible from source identity to final disposition.
By Aptoria editorial team · 3 min read · Updated 2026-09-18 · Last reviewed 2026-09-18
Technical content review: Codex technical editorial review. Reviewed intent separation, internal consistency, original decision artifacts, fictional examples, source limits, and operational risk boundaries. No legal, tax, accounting, banking, safety, or human professional approval is claimed.
This is a technical review, not independent human or professional review.
What to do now
A rejected-record register captures every source record not accepted as expected: stable source identity, domain, rejection stage and reason, raw evidence reference, attempted transformation, destination impact, owner, next action, and approved disposition. Reconcile the register to import totals so skipped records cannot disappear between logs and manual fixes.

Key takeaways

  • A successful job can still contain rejected records.
  • Preserve source identity through every remediation attempt.
  • Manual correction needs the same disposition and acceptance evidence as automated import.

Reconcile the import population

For each domain, prove source count equals accepted plus rejected plus intentionally excluded under an approved rule, with duplicates and merges explained. Counts alone are not enough when records split or combine; retain the mapping.
Do not overwrite raw rejected input while cleaning it. Keep a restricted evidence reference and create a new transformation or correction version.

Use a disposition register, not a log dump

Technical logs may contain the error; the operational register explains the decision and impact.
Rejected-record disposition register
FieldRequired contentWhy it matters
LineageSource system, domain, stable ID, source snapshotFind the original record
FailureStage, reason code, readable explanationGroup without losing specificity
ImpactRelated balances, documents, workflows, or partiesPrioritize the consequence
RemediationTransformation or manual action versionAvoid repeating failed attempts
DispositionReimported, merged, excluded, deferred, or unresolvedPrevent silent deletion
AcceptanceDestination ID, verifier, evidence, dateClose the lineage loop

Separate data defects from mapping decisions

Examples include missing required source value, invalid format, unresolved relationship, destination constraint, duplicate candidate, unsupported legacy field, and technical transport failure. “Bad data” hides whether the source is wrong or the migration rule is incomplete.
When a record is intentionally excluded, name the approved exclusion rule and retrieval path. Excluded is a disposition that requires evidence, not a synonym for unimportant.

Operational checklist

Mark your progress, then save a working copy. Selections reset when you leave this page. A checked box is not an approval or evidence of completion.
0 of 7 marked

Edge cases

  • One source record becomes several destination records: retain a one-to-many mapping.
  • Several source duplicates merge: preserve all source IDs and the merge authority.
  • A rejected record contains sensitive data: restrict evidence while keeping a non-sensitive operational reference.

Sources and references

Follow each source to check the underlying claim. Access checks and professional review are different steps.

Revision history

2026-09-18
Initial Phase 2 operational article with an original decision artifact, explicit failure states, primary-source scope notes, and AI-assisted technical review.
Report a correction to this resource