What to check before moving data between tools

Decide what moves

List the records, files and history you need in the new tool. Be explicit about what you will leave behind, such as old inactive customers, and where that archive will live. A move is a good moment to stop carrying data nobody uses, but only if the decision is deliberate and written down.

Check the quality of what you have

The UK Government Data Quality Framework describes several dimensions that are useful as a checklist. Completeness is the degree to which records are present. Uniqueness is the degree to which there is no duplication. Consistency means values do not contradict other values for the same entity. Timeliness means the data is up to date. Validity means it is in the range and format expected. Accuracy is the degree to which it matches reality.

Run a quick check for each: how many records have blank required fields, how many appear twice, which values are written several ways, and which look out of date. Fix what you can before the move, because a new tool will faithfully preserve old mistakes.

Check how the data can leave

Look at what the old tool can export and in what format. The ICO guidance on data portability uses the phrase structured, commonly used and machine readable formats when describing how personal data should be provided, and also lists secure transmission methods among its checks. That guidance concerns individuals asking organisations for their data and is under review following changes in law, so treat it as a useful standard of good practice, not as advice on your own obligations.

In practice, prefer a format such as CSV that keeps the data in rows and columns, check that dates, accents and long text survive, and move files through a secure channel rather than by email.

Map every field

Make a simple table with the old field name, the new field name, any change needed and an example. Watch for fields that combine two things, such as a full name in one column when the new tool wants two, and for values the new tool will not accept, such as a status that does not exist there.

• Required fields in the new tool that the old data leaves blank
• Date and number formats
• Pick list values that need translating
• Links between records, such as which contact belongs to which company
• Attachments and where they will live

Do a trial import and compare

Import a small sample first, perhaps fifty records chosen to include awkward ones. Compare the number of records before and after, check a handful in detail side by side, and look specifically at the cases that worried you, such as accents, long notes and linked records. Only then run the full move.

Keep a way back

Leave the old data untouched and read-only until you are satisfied, and take a dated copy of the export. Agree who may use which tool during the switch so that two people do not update two systems. Decide the date the old tool stops being used, and who confirms the move is complete.

Old exports, originals and test copies

Old exports, the read-only original and test copies often contain personal data, so give each a purpose, a named reviewer and a date when that person will decide whether to keep, erase or anonymise it. The ICO's storage limitation guidance says personal data must not be kept longer than needed, that the period should be justified by purpose, that standard periods in policy are preferable where possible, and that data should be reviewed periodically. This is UK guidance, not legal advice or a fixed timer, and it cannot override legal record-keeping duties. The ICO page is marked as under review because of the Data (Use and Access) Act and may change.

A hypothetical example

Imagine a small property manager moving tenant records from a spreadsheet to a database tool. A quality check finds two spellings of the same tenant and several blank phone numbers. The team fixes those, maps a combined address column into street and town, imports fifty records and finds that dates arrive in the wrong order. They adjust the mapping, repeat the sample, and only then import everything. Counts match, and the spreadsheet is kept read-only for three months. The three months is only an illustration, not a recommendation; the owner would need to justify the retention period, the review date and the end action. This example is hypothetical.