An operational-data migration needs agreement on what moves, how it changes, what evidence proves completion and who authorizes the switch. A successful file import is not sufficient if work orders lose their customer relationships or employees continue editing both systems. Include the transition period in the scope, not just the copying process.
This guide concerns defined operational records, such as open maintenance jobs or branch requests. Internal Operations Portals & Dashboards does not automatically include migrating an entire ERP or accounting system. Specialist systems and their archives require separate scope and qualified review when involved.
Decide what operations actually need
Divide information into active records needed on launch day, reference records they depend on and history that could remain in a readable archive. Moving everything may add work without a useful outcome. Moving only active records may remove essential context. The process owner defines the required use, then the technical team identifies its dependencies.
Create an inventory recording source, owner, approximate volume, extraction date, sensitivity and authorized access method. Do not assemble employees’ files indiscriminately into a public folder. Resolve which version is authoritative when branch files disagree. The newest file is not necessarily the approved one.
Record exclusions before migration. A deliberate decision to retain historical documents elsewhere differs from unexplained missing data. Users need to know where excluded records remain, who can access them and whether that route will still work after the old workflow is retired.
Specify mapping before cleaning
For each source field, define the destination, data type, transformation and permitted treatment of missing values. Preserve the original identifier or an explicit mapping between old and new identifiers. If “closed” sometimes means cancelled, do not automatically translate every closed record into completed work.
Be cautious when merging. Similar customer names do not prove that two entries describe the same customer. Agree reliable keys and send ambiguous cases to human review. Do not invent dates or owners to satisfy an import validator.
Where interfaces are used, API Integration & Development should specify transfer behavior, fields, errors and permissions. It does not require unrestricted access to every available dataset. Product Discovery & Requirements should also record what will not move, why it is excluded and how the team can retrieve it later.
Worked hypothetical: maintenance jobs before cutover
Suppose a spreadsheet contains 240 rows that appear to represent open work orders. The data owner confirms that 12 rows are duplicates and eight other orders are cancelled and outside the new operating scope. That leaves 220 unique orders to migrate. The owner approves the exclusion list and its reasons; an automated deletion rule does not make the business decision.
The first rehearsal imports 214 orders and rejects six because a required site identifier is missing. The import mechanism has operated, but migration acceptance has not been achieved. An authorized data owner corrects the six records from an approved source. The team retries without duplicating the 214 already accepted records.
The expected result is now 220 orders, each traceable to its origin. The operations lead then checks a deliberate sample: an order with attachments, a reopened order and one whose responsible employee changed. They verify site, state, attachment relationships and dates, not merely the total.
All quantities are illustrative. They are neither a client case study nor a forecast migration-success rate.
Reconcile at several levels
First compare entity counts after agreed exclusions. Then compare meaningful operational aggregates, followed by important fields and relationships. Equal work-order counts can conceal swapped sites. Matching totals can coexist with duplicate attachments. Establish acceptance rules for each layer and keep unresolved differences visible rather than burying them in a single success percentage.
AWS DMS documentation provides one example of a tool comparing source and target rows and reporting mismatches, while consuming additional resources. That does not mean your project needs AWS DMS or that row comparison validates business-state meanings. Choose tooling around actual sources and transformations.
Software Quality Assurance should cover retrying after partial failure, rejecting invalid inputs, archive-access permissions and discrepancy reporting. Sensitive records should not enter a rehearsal environment without authorization and appropriate safeguards.
Make cutover an explicit decision
Agree when source editing stops, how incoming work is recorded during the interruption and when the destination becomes the working system. If both sides remain editable, define authority for each field and a conflict rule. “We will synchronize later” is not a reconciliation strategy.
Set no-go conditions, such as active orders without valid locations or an unverified critical permission. Name the person who can authorize the switch. Record the evidence they will review rather than asking them to approve a general impression that the import looked successful.
Returning to the old system after the new one starts accepting work requires handling records created during that interval. Restoring an earlier snapshot alone can discard those new operations. Rehearse the recovery route or its safe component steps in an appropriate environment before describing it as ready.
The handover should identify who monitors outstanding discrepancies and who resolves records arriving late. A migration can pass its initial checks while still needing a controlled process for these agreed exceptions.
Frequently asked questions
Are matching record counts enough?
No. Check important fields, relationships and exclusions as well. A count detects some differences but cannot reveal an owner or state attached to the wrong record.
Must all historical data be cleaned before launch?
Not necessarily. Prioritize cleaning by its effect on required use. History outside the new workflow can remain in a documented archive with appropriate access, if the process owner agrees.
Who corrects missing information?
The data owner or an authorized person with the relevant source. The technical team identifies the error and enables correction; it should not fabricate information to make an import pass.
When should the old source be deleted?
Do not make deletion an automatic launch-day action. Agree retention, access and disposal after acceptance and appropriate review of archival needs. Any destructive action needs explicit authority.
Ask for an inventory, field mapping and reconciliation rehearsal before committing to a cutover date. Those outputs provide evidence of operational readiness beyond an “import complete” notification.
Technical reference
- AWS DMS data validation, reviewed 26 October 2026. The maintenance scenario and calculations are hypothetical.