ClientCentric

Switching · Data migration

Eight stages, one promise: every record accounted for.

This is the pipeline your files travel through — the same one, in the same order, for every agency. No stage is skipped silently, and nothing writes to your live workspace until the plan carrying your written approval executes.

How care agency data migration works in ClientCentric: files are scanned in quarantine, sorted and profiled automatically, mapped through reviewed rules, validated row by row into an exception queue, simulated in a dry run that produces a record-by-record confidence report, approved in writing by you, imported idempotently, and reconciled against the database with downloadable proof. A rollback window follows go-live.

The eight stages

  1. 01QuarantineEvery uploaded file is scanned before anything opens it: the bytes must match what the file claims to be, and an executable renamed to .csv is refused with the reason recorded.
  2. 02SortingThe platform reads your files and identifies what each table is — staff, clients, services, assignments — and what each column holds, with a confidence score and the reason shown. A human can override any guess, and the override is recorded.
  3. 03MappingYour columns are mapped to ClientCentric fields through reviewed rules. Columns that fit nowhere are never discarded — they are explicitly preserved in the archive. Approving the mapping freezes it under a fingerprint.
  4. 04ValidationEvery row is checked: impossible dates, duplicate IDs, staff sharing an email, assignments pointing at people who are not in the files, missing required fields. Every finding lands in an exception queue with a severity — blockers stop the show until resolved.
  5. 05Dry runThe entire import is simulated without writing anything. The output is the migration confidence report: per record type, how many import cleanly, how many carry notes, how many need work first — and the arithmetic must balance perfectly or the report refuses to exist.
  6. 06ApprovalYou approve the report in writing, in plain language, in your own workspace. The approval is cryptographically bound to that exact plan; change anything and it must be approved again.
  7. 07ImportRecords move in dependency order. The import is idempotent: if it is interrupted anywhere, re-running it continues without ever creating a duplicate. Records that already exist are linked, not duplicated.
  8. 08ReconciliationAfter the import, the platform re-counts everything from the database with two independent tallies and shows the result: every record you sent, in exactly one documented place. You can download the proof as spreadsheets.

What makes it safe

  • Write-once storage: an uploaded file is never overwritten; a re-upload is a new version with the old one kept
  • Privacy by construction: columns holding names, emails, or birthdates never display sample values to operators
  • Idempotent import: interrupted work resumes without duplicates — the database itself enforces it
  • A reconciliation identity that must balance: totals are proven with two independent counts
  • A rollback that removes exactly what the migration created, and nothing else
  • An append-only audit trail of every action, human or automatic

One honest limitation: an external malware-scanning engine and the production data gates (agreements, security review, retention sign-off) are completed per customer before any real agency data is handled. The pipeline described here is exercised end-to-end with synthetic data as part of the product’s own test suite.

Explore the product in the demoBook a switch walkthroughNo signup. Fictional data. Everything resets on refresh.

Keep reading

Written and maintained by the ClientCentric team from the working product. Last reviewed .