Business systems / Checklist
Moving customer records into a new CRM: what needs checking?
Imagine a spreadsheet containing customers on one tab and their jobs on another. A new CRM needs to preserve which job belongs to which customer, as well as the information in each row.
We build bespoke CRMs around the way a business works. I want the import brief to give the existing records that same attention, including the awkward rows someone will need to resolve.
Agree what each field means
Keep an authorised export of the original data and work on a controlled copy. Map each source field to its intended destination, with examples of dates, statuses and blank values. Keep unnecessary personal information out of development examples.
A column called “date” could mean when an enquiry arrived, when a job was booked or when it was completed. The person who uses those records should confirm the meaning before an importer assigns the values.
| Fictional source item | Decision before import |
|---|---|
| Customer reference | Which destination customer it identifies |
| Job reference | Its identity and its linked customer |
| Status | Which agreed CRM status it represents |
| Blank completion date | Whether the job is unfinished or the date is unknown |
Decide how records will be recognised
Agree the rules for matching an existing customer, creating a new one and flagging an uncertain match. Two rows with similar names may need a person to check them; two people sharing an address are not automatically the same customer.
Keep the relationships explicit. If a job refers to an old customer identifier, the migration needs a reliable way to find the corresponding customer in the new system.
PostgreSQL documents constraints for required values, uniqueness and valid relationships between tables. Those rules can reject structurally invalid data. They do not decide the business meaning of a duplicate person or an ambiguous status.
Rehearse the move and inspect the exceptions
Use an isolated rehearsal with representative records, including awkward cases. Identify accepted records, rejected records and anything needing a decision. Do not silently discard a row because it does not fit the first mapping.
Supabase’s import guidance describes several methods and advises planning production imports for integrity and application impact. Choose a method that fits the data and the system; a successful upload is only one step in establishing the result.
Compare the intended source records with the destination. Check a sample of customers and their linked jobs, and account for every exception. Keep the mapping and the correction decisions with the rehearsal record.
Plan what happens to changes made during the move
Agree who controls the final export, when staff switch systems and how changes made during the transition will be handled. Keep the recovery route and the old system’s access arrangements in that plan.
Define the checks and sign-off before the live import starts. Staff should know where to work afterwards and where to report a record that looks wrong. Keep unresolved items visible until someone has dealt with them.
Sources
Checked on 23 October 2026.
- PostgreSQL: data constraints and relationships
Required values, uniqueness and foreign-key relationships enforce defined structural rules, with limits on what those rules establish.
- Supabase: planning and importing data
Import methods differ; production work needs planning for integrity and application impact.