08 · Implementation & go-live · Opening balances
A customer that does not match must not be stuffed into a code called Other
The data-migration engineer moves opening balances by the mapping table. Data that will not migrate goes on the reject list. He does not invent a merge rule, and he must not fake master data to make the row count look good.
| Object | Treatment | Must be true on go-live day |
|---|---|---|
| Customer | Match tax ID or confirm by hand; otherwise do not migrate | New documents cannot pick an unconfirmed customer |
| Stock | Split by warehouse and status; disabled warehouses listed separately | Available qty excludes disabled warehouses |
| Open documents | Belong to the old system or become pending receive — pick one | Both sides must not receive the same goods |
The data-migration engineer owns an explainable opening balance
The data steward gives the mapping rules. The data-migration engineer executes them and proves the result. What marks this role is keeping a reject list. Customers that do not match, locations with no temperature zone, stock with a negative quantity all go on the list, for the owner to handle. He does not invent a merge himself, and he does not change a negative to zero so the import succeeds. An import that succeeds while the balance cannot be explained is harder to close than an import that failed.
Every migration round must be rerunnable. Production data patched by hand is not a version. He uses a script, a batch number, and a reconciliation report. The report compares old-system and new-system quantities by warehouse. A variance row can be clicked back to the source document. A warehouse that does not reconcile does not go live. It is not go live first and adjust the books later.
Disabled warehouses and in-transit
The old system often still has quantity in a disabled warehouse, and in-transit has no status. The migration engineer splits columns by the data architect's definition: available, in-transit, disabled. Goods in a disabled warehouse do not enter sellable. If the business thinks those goods can still be sold, they first receive them in or enable the warehouse, then migrate. Do not quietly add them into available qty in the script.
The Other code, negative stock, no temperature zone
Once, to catch cutover, unmatched customers were put into Other. In the first week some new documents hung under Other, and receivables could not be chased by customer. The migration engineer exported that batch, rehung each one onto a confirmed customer, and forbade importing Other again. The next reconciliation required Other's balance to be zero before sign-off. Cutover was therefore one day late. Collections did not break.
The reject list also has to list two kinds on their own. Numbers must not be changed to make the row count look good. Negative stock: a stock-loss hanging on the books that the old system allowed. Before migrate, the owner decides reverse or freeze. The script must not change it to zero. Locations with no temperature zone: a cold-chain location with no temperature-zone tag is rejected as a whole row. Goods are not stuffed into default ambient. These two are harder than Other, so when sorted by reason they sit at the front. They are not left for cutover night.
The report goes to the implementation consultant as one of the conditions for opening the gate. If the balance cannot be explained, the first new document should not start. Before cutover the migration engineer does a dry run: script, reconcile, roll back, all finished and timed on staging. If timing exceeds the window, he cuts the objects in this batch or changes the plan. Open purchase documents migrate remaining qty only. A deactivated supplier must not be reactivated just because opening payables remain. Enable is a purchasing decision, not a script default. The batch counts on cutover night are printed for the warehouse lead to sign. What they sign is not that the script finished. It is that each warehouse's quantity can be explained. A group message saying “migration done” has no object. When it does not match, nobody remembers what they admitted.
The dry run leaves three times: how long the script ran, how long reconcile took, how long rollback took. If the window cannot hold it, cut the objects in this batch. Do not watch the progress bar for the first time on cutover night. Every round uses a batch number. Production data patched by hand is not a version. The reconciliation report lists variance rows by warehouse, clickable back to the source document. A warehouse that does not match does not enter the gate-open list. He does not invent a merge. A customer whose tax ID does not match goes on the reject list, for the steward's owner to handle. If the script defaults contain Other, or change a negative to zero, this batch is void and rerun. Migration's result is an explainable reject list, not a pretty import row count.