Spreadsheet Data Migration Checklist: Move Records Without Losing Context

A spreadsheet data migration moves records from existing workbooks into a new application while preserving the information and relationships the team needs. Prepare the mapping, cleanup, validation, and cutover before importing production data. A successful upload proves that a file was accepted; it does not prove that the new system represents the business correctly. A new app should not inherit every duplicate just because the spreadsheet has grown attached to them.

Identify what the spreadsheets really contain

List the workbooks used in the workflow, their owners, and which one is authoritative for each kind of record. Look beyond visible columns: formulas, linked tabs, colors, comments, and file attachments may carry business meaning. Ask the people who maintain the sheets to explain the exceptions they handle from memory.

Example: the same client appears under three names

An illustrative project sheet contains “Northside Studio,” “Northside,” and “NS Studio.” Those rows might refer to one client, several locations, or unrelated businesses. Do not merge them based only on similar names. Create a reviewed mapping to stable client identifiers and preserve the original values for investigation. Then link the correct projects and contacts to those identifiers.

Rehearse with a representative sample

1. 01

   Keep a protected original

   Retain a read-only copy of the source as it existed before cleanup. Document who may access it.

2. 02

   Transform a sample

   Include ordinary records, duplicates, missing values, closed work, and unusual dates. Save the transformation rules so the import can be repeated.

3. 03

   Reconcile the result

   Compare source and destination counts, key fields, relationships, and any totals the business relies on. Keep a list of rejected or intentionally excluded rows.

4. 04

   Run the real workflow

   Ask users to find a client, update a job, view attachments, and produce an important report using the imported sample.

Plan what happens while the final import runs

Set a clear period when the source stops accepting changes, or define how changes made during migration will be captured. Name the person who decides whether to proceed or roll back. If people keep editing both systems without a reconciliation rule, differences can appear even when the original import was correct.

• Record which source version produced the final import.
• Prevent retrying the import from creating duplicate records.
• Resolve or explicitly accept every rejected row.
• Define how work entered after cutover would be recovered if the launch is reversed.

Check values as well as row counts

AWS’s database migration documentation describes validation by comparing source and target records. A spreadsheet project may use different tools, but the same distinction is useful: equal counts do not prove equal contents. Check a sample of important fields and relationships, and investigate unexplained differences before declaring the new application ready. AWS reference