What to check before moving business data into a new system

Acceptance needs to cover both the information and the work that continues from it. Decide in advance what evidence permits the switch and who decides what to do with differences that remain unexplained.

Inventory the data sets: customers, products, sales transactions, open work, correction history and attachments. Identify each owner, source, approximate volume, relationships and access requirements. Exporting every available file before deciding its purpose makes the scope harder to control.

Agree which historical information belongs in the new system and which can remain accessible in an archive. Open work that people must continue may need different treatment from records retained only for reference.

Back up the original before transforming it, with its covered period and capture time. Version the migration inputs and transformation rules so the result can be traced. Never transform the only source copy and lose the recoverable pre-migration state.

Map each original field to its destination and define required values and the handling of unknown inputs. Test leading-zero codes, Thai text, line breaks, decimals, spaces and the difference between an empty field and zero.

Check day-month ordering, Buddhist and Gregorian calendar years, and time zones. Avoid guessing date formats from text without confirmed examples. A date can appear valid while its month has been swapped or its instant shifted into another day.

Use a representative set containing older records, open work, unusual cases and attachments. The source and target must cover a comparable point in time. If the source continues changing, define how changes after the cut-off will be captured.

Begin with counts by record type and meaningful control totals, then compare individual records. Equal overall counts can conceal missing records offset by duplicates. Stable references are needed for item-by-item reconciliation.

AWS DMS data-validation documentation describes comparing source and target records and reporting mismatches, subject to tool requirements and processing overhead. Such checks support data-level evidence; they do not replace checks of files, permissions and business workflows.

Opening an order should reveal the correct customer, items and associated documents. Open work must retain a usable state and owner. A text description of its old state is insufficient if the new system cannot continue the process.

Inspect cancellations, corrections and partial returns as well. If only current values are migrated, confirm where required history remains available and ensure readers are not led to believe that a record was never changed.

Have people in each role test the work they need to perform: locating customers, opening documents, continuing pending work and producing reports. Use realistic permissions. An administrator who can access everything may not notice a restriction preventing the team from operating.

Maintain a discrepancy list with affected counts, examples, causes and responsible owners. Separate intended transformations from defects. Do not accept an unexplained difference simply because the grand totals look close.

Define pass conditions before the cut-over day. Examples include no broken references within the agreed scope, important files opening correctly and required workflows continuing successfully. Any accepted exception needs an identified approver and a recorded treatment.

Record evidence against these conditions rather than relying on a general statement that the import looked fine. If a failed case is repaired, repeat the relevant check and verify that the fix has not changed the related records incorrectly.

Specify any write pause or method of capturing post-cut-off changes, who checks the final transfer and when the team may begin entering information in the new system. Avoid allowing both systems to accept changes without a reconciliation method.

A return plan must account for new transactions created after the switch. Simply reopening the old system can lose the work entered in the new one. Define how those transactions will be transferred back, held or reconciled, and who can decide to use that plan.

After launch, monitor failures and important totals for the agreed period. Retain source copies and acceptance evidence under the business's retention rules before retiring the original system.

If source references remain inconsistent, start with aligning product codes. Apply the principles of recovering interrupted automation to establish a workable route when migration steps do not finish as planned.