Software migration and cutover · Playbook · intermediate

PMS migration delta capture after the source freeze

Account for every transaction, lease change, payment event, work update, document, and identity change created between extraction and cutover.
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, operational risk boundaries, and links. No legal, tax, accounting, banking, safety, or human professional approval is claimed.
This is a technical review, not independent human or professional review.
The short answer
Capture migration deltas by defining a baseline extraction checkpoint, every source allowed to change afterward, a stable change identity, the system of entry during the transition, and a final replay or manual-entry register. Reconcile each delta exactly once in the target before releasing the old source from operational use.

Key takeaways

  • A source freeze is a rule with exceptions, not a timestamp alone.
  • Track creates, updates, deletes, and external events.
  • Prove each delta was applied once and in dependency order.

Define the baseline and every continuing writer

Record the source systems, extraction job and time, time zone, included record versions, file hashes where available, and the target import batch. Then inventory remaining writers: staff, residents, owners, vendors, payment processors, bank feeds, document inboxes, APIs, scheduled jobs, and provider webhooks.
For each writer, choose pause, redirect to the target, capture for replay, or permit under a manual register. A banner asking staff not to edit does not govern external payment or message events.

Capture deltas with dependency and idempotency fields

Use source event or record IDs where possible. Record operation type, source version, event time and receipt time, parent dependencies, target identity, apply status, and conflict decision.
Migration delta register
Delta typeExample dependencyApply-once test
CreateNew tenant depends on property/unit identitySource ID maps to one target ID
UpdateLease amendment depends on base lease versionExpected prior version matches
Delete/archiveCanceled work order or removed draftTarget disposition retained, not silently omitted
External eventPayment return depends on original payment identityOriginal and event linked once
DocumentAttachment depends on parent record and access scopeFile hash/name, parent, and count verified

Run a final ordered reconciliation

Stop or route all remaining writers at the final cutoff, export the last delta window, and compare it with captured events. Apply parent records before children and original transactions before returns or corrections. Conflicts require a named source-of-truth decision; later timestamp alone is not enough.
After replay, re-run critical counts and balances plus a sample of changed records. Preserve rejected deltas and reasons. The source can become read-only only when the approved cutover plan says its remaining operational role has ended.

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

  • A source edit changes no updated timestamp: use audit logs or bounded comparison where available.
  • A payment settles after cutover but began before it: retain the original provider identity across systems.
  • A record is edited in both systems: escalate the field-level conflict instead of choosing the latest whole record.

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 3 operational article with a distinct decision artifact, failure states, source-scope notes, and AI-assisted technical review.
Report a correction to this resource