A database migration is complete when the destination preserves the business meaning of the required information and the application can use it correctly. Copying records is one step. Mapping, relationships, late changes and verification need their own decisions and evidence.
This guide covers migration planning and the performance checks that often follow a move. It helps a business question a transfer plan without assuming that every database tool has the same capabilities.
Inventory the source and destination
List the tables or record types, important fields, identifiers, relationships and stored files. Database metadata can reveal implemented types, defaults and nullability where the account has access. It does not explain why the business collects a field or how staff interpret it.
Record the owner and purpose of important information. Include documents, images and references held outside the main database. Establish what is in scope, what will remain archived and what the destination must support before staff depend on it.
Map meaning rather than matching labels
A source field called status may use values with different meanings from the destination. Write an explicit mapping and have someone familiar with the business review it. Include conversion rules, default values and the treatment of unknown or obsolete values.
Test the actual import configuration. Automatic field matching or type conversion can be useful, but its behaviour depends on the tool and settings. Matching names do not establish matching meaning, and a successful conversion can still produce a misleading business record.
Define missing values and identifiers
Distinguish a missing value, an empty string and an explicit null. Formats such as CSV need an agreed representation because consumers may interpret blanks differently. Export a small controlled sample and inspect how the destination stores and returns each case.
Choose stable identifiers and a documented duplicate policy. Some platforms support unique combinations of fields as alternate keys; others need another approach. Check whether the intended key exists, is active and handles the actual data before relying on it for matching or updates.
Preserve relationships and file access
Verify that orders still refer to the correct customers and that attachments belong to the intended records. Import order may matter when related records depend on earlier identifiers. Maintain a reconciliation record of old and new identifiers where the destination generates replacements.
Check filenames, paths, characters and access rules against the destination storage and clients. A title accepted by a document editor may not be a safe filename across every system. Test representative long names and unusual characters without exposing private files through public addresses.
Account for changes during the transfer
Agree whether the source will stop accepting changes or whether ongoing changes will be captured and applied. Record the cut-off point and the evidence that the final relevant changes reached the destination. An active replication process can still have a delay.
Identify which system is authoritative at each stage. Staff should know when to stop using the source and how late entries will be reconciled. Avoid two writable systems accumulating different versions of the same customer information without an agreed conflict rule.
Verify data and business journeys separately
- Compare counts by useful record type and status.
- Reconcile important totals and identifiers.
- Compare selected values or complete rows where appropriate.
- Check relationships, attachments and permissions.
- Exercise staff tasks and customer journeys.
- Record exceptions, their owners and acceptance decisions.
Validation consumes time and resources, particularly when comparing substantial datasets. Include that work in the migration plan. A copy tool's completion message does not establish that every value, relationship or application behaviour has been verified.
Investigate performance with known evidence
If a task is slower after migration, capture the affected operation, representative input and timing. Separate application, network and database work. Compare under similar conditions, accounting for caching, data volume and concurrent activity.
A slow-query log only records statements that meet its configured conditions. An absent entry is not proof that no costly database work occurred. Review logging settings with the technical owner and protect personal data or secrets that diagnostic records might contain.
Understand whether diagnostics execute work
A query plan describes the database's intended processing approach. Execution-based analysis can run the statement to produce actual measurements. In MySQL, EXPLAIN ANALYZE runs the statement; it should not be treated as a harmless preview.
Have an authorised technical owner select a suitable method, environment and permissions. Assess workload and possible side effects before execution, then verify any optimisation against the same business task. Our backup and restore-testing guide supports recovery planning. Giraffe Digital's digital strategy service can connect the migration with data ownership and the workflows it needs to preserve.
