Parallel replacement is a migration pattern in which an existing and a replacement implementation are compared over equivalent inputs and starting state before the replacement becomes authoritative. Parallel describes the comparison arrangement; it does not authorize two uncontrolled writers to perform the same live business action.
The pattern supplies evidence about behavioral agreement. Its validity depends on correspondence between executions, the observations selected, and the rules used to interpret differences.
Matched executions
The same request can produce different results when the starting data, configuration, or business date differs. Comparing those results without accounting for the difference does not isolate an implementation defect.
A controlled comparison establishes a reference state, runs the original implementation, records outputs and state changes, then runs the replacement from an equivalent state with equivalent inputs. The runs need not occur at the same wall-clock instant to be comparable.
The shared-Db2 testing approach in the research uses initial and resulting snapshots for this purpose. The mechanism is matched state and input, rather than an assumption that two applications connected to one database will automatically see equivalent conditions.
Observe all required effects
A transaction can return a response, change records, create a file, and initiate an external action. Comparing only the response leaves the other effects outside acceptance.
Suppose two implementations both report that a payment request succeeded. One records the correct amount but sends two downstream messages. The visible response agrees, while the business effect differs. Acceptance must include the observations that distinguish those outcomes.
The selected effects define the scope of a pass. A report comparison provides evidence about that report under its input conditions. It does not establish transaction concurrency, recovery, or paths that the trial never executed.
Shadow execution controls authority
A shadow implementation processes representative input for comparison while the established system remains authoritative. Its outputs require separation from live business effects so that a test does not create a second payment, notification, or equipment command.
Controlling an endpoint changes the evidence boundary. A simulated destination can demonstrate the message the replacement intended to send. It does not prove the external service’s live acceptance or availability. Those properties need a separately bounded trial.
Authority must also be explicit for database state. Test copies or resettable environments permit comparison without allowing both implementations to create competing production history. The exact arrangement depends on the transaction and available isolation mechanisms.
Differences require decisions
A mismatch can represent a replacement defect, a known defect in the original, an approved behavior change, or unequal test conditions. These categories imply different actions.
Normalization removes only differences declared irrelevant to the required contract. Sorting unordered output can be appropriate when ordering has no meaning. Sorting a sequence whose order determines processing priority destroys an important comparison.
Tolerances follow the accepted calculation or representation. Increasing them until discrepancies disappear converts the test into a pass generator. Known-difference checks establish whether the comparator can reject errors that matter.
Promotion and completion
Successful comparison prepares an authority decision. Promotion establishes which implementation receives live work and owns new state. It needs defined routing, configuration, operational responsibility, and treatment of transactions crossing the switch.
Recovery after promotion is a separate state problem. If the replacement has accepted writes, returning traffic to the original does not reconcile the new transactions. The comparison phase supplies behavioral evidence, not automatic reverse synchronization.
A completed replacement also resolves the old implementation’s remaining consumers and schedules. Otherwise, parallel operation can become an indefinite operating arrangement without a defined end.
What varies is the execution environment and the accepted differences. What remains fixed is comparable input and state, controlled authority, and an explicit account of which business effects were demonstrated before responsibility moved.