Kandiantong: Open orders can be listed and moved on their own
Start with the conclusion: orders already completed three years ago usually do not need to enter the new shipping flow. Putting them in a read-only archive is safer than pouring them into the production database.
What moves
Export fields from the old product change with the version. When a project starts, use the actual export file and the payment provider's statement. This article gives the acceptance criteria.
Every unfinished order enters the new system, or it is explicitly left in the old system until it is finished. Only one operating entrance may be chosen. Recent completed orders move in with a completed status if after-sales support is still required. Earlier orders are exported as an archive file, and customer service looks them up by order number.
What does not move
Historical line items with no after-sales need, internal logs from the old system, and duplicate payment notifications do not move. During the move, only this class of data is carried. The difference is that in-transit orders must move and history may be archived. Overwriting the whole database would also bring in logs, test orders, and balances that cannot be explained.
Mapping checks and the switch
Customer service can look up the amount in the archive by order number. The production database does not contain a waiting-for-shipment status for that order from two years ago. The announcement states clearly where orders from before a given date can be found, so customer service does not say both systems have nothing.
The entrance is switched only once. After the switch, the old system can handle only the in-transit orders on the list. It cannot take new orders. Business and finance look at the totals together. If they do not match, stop at the rehearsal and do not change the mini-program entrance. Whether a payment succeeded follows the payment provider's statement, not a paid status in the old back office.
Source: https://www.kandiantong.com/migrate/history-orders-choice.html