A CRM migration can appear successful while important data is still missing.
That was the problem I faced while diagnosing a Base44 CRM migration. The application loaded, some records were present, and the import process had completed without an obvious failure. However, contacts, leads, reminders, candidates, and their relationships did not look complete.
Instead of immediately changing the importer, I investigated what had actually been exported and processed.
The first clue: the archive was incomplete
I inspected the migration archive and found only six entries. The main data file was TeamMember.json, while the manifest identified the export as the team_members phase.
The archive did not contain the expected files for:
- Contacts
- Leads
- Reminders
- Candidates
- Other related CRM records
This changed the diagnosis completely.
The importer had not randomly lost the data. It had processed the information it received, but several migration phases had never been included in that archive.
Why the problem was misleading
From the user interface, the symptoms looked like an application bug:
- Some records appeared while others did not
- Relationships between profiles and team members were incomplete
- Screens displayed different totals
- The migration itself appeared to have finished
It would have been easy to blame the dashboard or rewrite the importer. That would not have fixed the actual problem.
The real issue was an incomplete, single-phase export.
Completing and verifying the migration
After identifying the missing phases, I completed the remaining migration jobs and verified their status.
The completed migration included:
- 525 per-user jobs
- 69 all-user jobs
- No jobs left running, queued, or pending
I then checked the live records instead of relying only on the migration status.
The verified totals were:
- 20,949 contacts
- 16,344 leads
- 3,096 team members
- 10,393 reminders
- 1,522 candidates
Completing a job is not enough proof that a migration is correct. The destination data must also be counted and inspected.
Repairing broken relationships
One remaining issue involved relationships between profile records and team-member records.
Some records could not be matched using only the primary email address. I added a safer matching process that also considered secondary and additional email fields.
After repairing the relationships, I checked for:
- Duplicate records
- Orphaned records
- Incorrect profile-to-team-member links
- Screens still referencing old or temporary data
- Security rules accidentally changed during the repair
The final verification found zero duplicate records and zero orphaned records. The application screens were connected to the live tables, and the existing row-level security rules remained intact.
What I learned
Here are the main lessons I would apply to any CRM or SaaS data migration:
1. Inspect the source archive first
Before rewriting an importer, confirm that every expected entity and migration phase exists in the source files.
2. Separate export problems from import problems
If data never entered the archive, the importer cannot restore it. These are two different failure points and should be investigated separately.
3. Verify live totals
A “completed” status only confirms that a process stopped. Compare the source and destination counts for every important entity.
4. Validate relationships, not only records
Having every contact and team member in the database is not enough if the links between them are broken.
5. Use fallback matching carefully
Secondary email fields can help repair relationships, but matches should be deterministic and checked for duplicates.
6. Preserve security during repairs
Migration fixes should not require weakening authentication or row-level security. Always verify access controls after changing production data.
A practical migration checklist
Before declaring a migration complete, I now check:
- Are all expected files present?
- Are all migration phases represented?
- Did every job finish?
- Do source and destination totals match?
- Are duplicate and orphan counts zero?
- Are relationships correctly connected?
- Are application screens reading from the live tables?
- Are authentication and security rules still working?
The most important lesson is simple: diagnose the data pipeline before changing the application.
Sometimes the visible bug is only the final symptom of an incomplete export several steps earlier.
Top comments (0)