Transfer tenant write ownership without accepting commands on both sides

Project context

A fictional B2B scheduling service stores account settings in a legacy module whose database access leaks into HTTP handlers. A replacement must support existing clients and migration by tenant. Build a local modular application, a synthetic two-tenant dataset, and controllable old/new adapters; no baseline repository or fixtures are supplied. Keep the exercise in one application and local database, with no live customer traffic.

Setup prerequisites

• REST contracts
• Tenant authorization
• Transactions
• Dependency injection

Preceding work

Complete these dependencies, or supply their agreed outputs before taking this ticket.

• PMIGRATE-101 · Put legacy account lookups behind a contract the replacement can keep
• PMIGRATE-102 · Remove the process-wide current-tenant account client
• PMIGRATE-103 · Separate account policy from legacy SQL and replacement storage
• PMIGRATE-104 · Shadow account reads without duplicating booking-channel writes
• PMIGRATE-105 · Preserve tenant scope and conditional reads through the migration proxy
• PMIGRATE-106 · Decide whether a separate account summary read model earns its lag

Acceptance criteria

• Represent write ownership with a durable tenant migration revision and reject commands using a stale ownership revision at the write boundary.
• Backfill replacement data and reconcile it through the final legacy revision under the ownership fence; do not open the new writer while any committed legacy change remains unapplied.
• Define a cutover sequence that drains or rejects in-flight old-owner commands before the new owner accepts writes.
• Document and rehearse how rollback handles writes already accepted by the new owner; switching a read flag alone cannot declare rollback complete.

Implementation constraints

• Keep the exercise in one local database and explicit transactions; do not claim cross-database atomicity or solve stale ownership with cache TTL alone.

Verification to include

• Copy tenant data, commit a later legacy write, then interleave commands from two instances around cutover; assert the new owner includes that write and a single accepted ownership lineage loses no successful writes.
• Crash after ownership transfer and attempt rollback after a new-side write; verify the recovery procedure detects and reconciles that write before reopening old ownership.

Deliverables

• Tenant cutover command, stale-owner rejection checks, and write-aware rollback drill

Rollout and recovery

Rehearse with one synthetic tenant and a paused writer; expand only after cutover and rollback counts reconcile.

Value of the work

For the engineer: Practice incremental migration, dependency boundaries, compatibility testing, and removing abstractions that obscure behavior rather than enabling change.

For the team: Inspect a migration plan with measurable parity, explicit write ownership, tenant-safe routing, and rollback limits instead of accepting a rewrite diagram alone.

Evidence boundaries

Outcome Evidence: Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs.

Ownership Evidence: Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence.