When a business moves from spreadsheets or an old system to a new app, the build gets the attention. But the success of the move often depends on something less glamorous: whether the existing data arrives clean, complete and correctly connected.

Bad imports create a painful first week: duplicate clients, missing documents, wrong dates and staff who stop trusting the new system. This checklist shows how to plan and run a migration that avoids that.

Why data migration goes wrong

• The old data was never clean. Spreadsheets hide years of inconsistencies.
• The same thing is recorded in several ways, such as three spellings of one client.
• Relationships were implied, not recorded, such as which contact belongs to which company.
• Dates, currencies and phone numbers use mixed formats.
• Nobody decided what to leave behind.

The checklist

1. Decide what to migrate

Not everything needs to move. Old closed records, abandoned drafts and obsolete clients may be better archived. Decide what the new system needs on day one and what can stay in a safe archive.

2. Audit the current data

List every source: spreadsheets, a previous system, email attachments. For each, note what it contains, who owns it and how reliable it is.

3. Clean before you move

4. Design the target structure first

Know exactly how the data will be organised in the new app before you import. This is the data model from your PRD. Our database design guide explains why structure matters.

5. Give every record a stable identifier

Unique IDs let you connect related records, such as clients to matters, and let you re-run or correct an import without creating duplicates.

6. Map old fields to new fields

Create a simple table: each old column, the new field it goes to and any transformation needed. Review it with the people who know the data.

7. Handle relationships and files

Decide how links between records are rebuilt, and how documents or attachments are moved and attached to the right record.

8. Import a small test batch

Start with a sample. Check that fields, relationships and files look right in the new system before importing everything.

9. Validate the full import

• Compare record counts between old and new.
• Spot-check a sample of records against the originals.
• Check totals, such as balances or numbers of open items.
• Have the people who use the data review it.

10. Keep the original safe

Retain an untouched copy of the source data for reference and as a fallback.

11. Plan the cut-over

Decide when the old system stops accepting changes, how final updates are captured and how you will handle anything that arrives during the switch. Many teams run both systems briefly in parallel to build confidence.

12. Protect personal data

Migration files often contain sensitive information. Handle them securely, limit who has access, delete temporary copies when finished and respect data protection rules. See our security guide.

Who does what

Plan it from the start

Migration is easiest when it is planned alongside the build, not after it. It belongs in the PRD. Our Discovery Sprint covers data structure and migration scope as part of the plan: $345, delivered in 24 hours and credited toward the build. See also our guide for teams moving off lighter no-code tools.

Frequently asked questions

Can you import from Excel or CSV files?

Yes. Spreadsheet files are a common source and can be cleaned and mapped before import.

How long does a migration take?

It depends on the volume and condition of the data. Clean data moves quickly. Messy data needs time for cleaning, which is worth doing.

What if some data cannot be migrated?

Archive it in a safe, searchable form and decide what needs to be recreated.

Will there be downtime?

A planned cut-over can keep it short. Running in parallel for a short period reduces risk.