Dual writes or runtime version detection for rollback-safe schema changes?

Constraint

A Ballerina 2.x service needs a rollback-safe response to a breaking record-schema change, including data produced by both the previous and new schema versions. The goal is a defined restoration guarantee, not automatic conversion of persisted records: record versioning addresses compatibility with older payloads, while transactional rollback depends on the transaction scope and service-defined compensation.

The unresolved choice is between dual-writing both representations during migration and detecting the record version at runtime. Dual writes introduce consistency obligations when one write succeeds and the other fails. Runtime detection avoids duplicated writes but leaves the behavior of mixed-version records and rollback ordering unclear.

Record versioning may be marked preview in Ballerina releases before 2.1, so its status in the selected release must be confirmed. The rollback contract should also be validated against persisted old- and new-version records after a deployed transaction failure; compilation or hot reload alone cannot establish data restoration.

Should the migration use dual writes with explicit consistency handling, or runtime version detection with transactional rollback and service-defined compensation? What atomicity guarantee must cover a partial dual-write failure, and which persisted-state checks are required for the target release?