Running old and new business systems in parallel: who is allowed to write?

Old and new business systems can run at the same time, but a particular operation on a particular record needs an authoritative write destination at each stage. Begin with read-only comparison, then transfer writing by department, object or business cohort. This is easier to verify than asking employees to enter everything twice and reconcile it later. The subject here is ownership of live operations during transition. Cleaning and moving historical data remains a separate workstream.

Assign ownership at the level of business operations

“The old system owns customer data” may still be too broad. Customer names, account assignments, contract status and receipts can have different owners. List the relevant objects and operations. A departmental pilot must also account for shared customers and cross-region orders; the operator's department alone may not determine record ownership.

After establishing field ownership with the ERP, CRM and OA integration responsibility method, add the pilot stage, effective time, routing rule and conflict owner. Include these operating rules in the scope of custom software development (Chinese), alongside the new entry screens.

Rehearse the transfer with an order already in progress

Consider this design example, rather than a customer case: an order was created in the old system and is awaiting approval when the pilot starts. If the new system also permits editing, an old approval could authorize the original amount while the new screen shows a changed amount. One option is to finish existing orders in the old system and create new ones in the replacement. Transferring active workflows is another option, but requires explicit acceptance of each state, record version and outstanding responsibility.

1. Identify the cohort and its active operations, then pause new writes for that scope.
2. Resolve or explicitly cancel accepted but unfinished approvals, imports, scheduled jobs and interface retries.
3. Confirm the reconciliation point and destination access before opening the new writer. Make the old entry read-only or explicitly reject writes.
4. Verify that old bookmarks, mobile clients and external interfaces follow the same ownership rule.

Hiding an old screen's edit button is insufficient. Background tasks, integration accounts and browser pages that remain open can still submit requests. Record which rule version controlled the transfer, and include those less visible entry points in the evidence.

Use comparison to reveal differences, not to create another writer

A comparison view may display both results, but each comparison should carry the business identifier, source version, last synchronization point and difference status. If an update has not arrived, classify it as awaiting synchronization. If a field is genuinely wrong, correct it in the authoritative system and propagate the result instead of manually changing both copies.

The AWS transactional outbox guidance explains the inconsistency risk when a database update and its event notification fail independently. It also calls for handling duplicate messages at the consumer. That helps with reliable propagation; it does not decide business ownership. Adding a queue does not authorize two systems to edit the same field independently.

Preserve conflicting versions before deciding the business outcome

If both sides have already changed a record, retain both versions, the actors, business timestamps and receipt times. Put the item into a controlled resolution list. A last-arrival-wins rule is particularly questionable for amounts, approvals and ownership assignments: network delay is not evidence of a later business intention. A named owner must decide which change to retain, reverse or compensate, with a linked resolution record.

Pause expansion when the pilot exposes misrouted writes, duplicate business transactions or critical work that cannot be transferred. Differences allowed to remain under observation still need an impact statement and a review deadline. Do not classify every unexplained mismatch as ordinary synchronization lag.

Exit and rollback must account for business already conducted

Before ending parallel operation, review differences, pending work, failed retries and use of old entry points over a representative business cycle. The business owner should confirm that the new destination can independently handle the agreed operations. Set the observation period from the actual workflow rather than promising an arbitrary number of days.

For rollback, stop new writes within the pilot scope, preserve business created or changed during that period, and decide how the old system will take it over. Redirecting users to the old page alone can omit real transactions. Apply the project change and handover method to preserve the release version, ownership table, reconciliation evidence and rollback owner. Rehearse the handling of an order created after the initial switch, not only records that existed before it.