August 14, 2026
Most data migrations don't fail because the target tool is bad. They fail because nobody wrote down what "good" looked like in the old system before hitting export. A spreadsheet doesn't enforce a schema, so ten years of contacts might have five different date formats, three ways of spelling the same company name, and a "Notes" column that's really three separate fields mashed together. If you migrate that mess as-is, you just get a nicer-looking mess. The fix isn't a bigger import button — it's treating migration as a short project with its own checklist, not a copy-paste task you do on a Friday afternoon.
Before touching your CSV export or your Airtable, HubSpot, or Zendesk account, build a simple two-column map: source column on the left, destination field on the right. This is where you decide things like whether "Company" in your spreadsheet maps to a text field or a lookup to a Companies table in your new CRM app, and whether "Status" values like "Won," "won," and "CLOSED-WON" all collapse into one option. Do this mapping exercise for every object you're moving — contacts, deals, tickets, inventory items — separately, because a spreadsheet that mixes people and companies in one tab needs to be split before it becomes two related tables. If you're not sure what a given field type should be, the glossary has plain definitions for things like lookups, rollups, and relations that make this decision easier.
Duplicates are inevitable when data has passed through multiple hands or multiple tools. The mistake most teams make is deduping by exact string match on name or email, which either misses obvious duplicates ("J. Smith" vs "Jane Smith") or merges records that shouldn't be merged (two different people who share an email alias). Before import, sort your source data by email and phone number, flag near-matches manually, and decide a merge rule in advance — usually "most recently updated record wins for field values, but combine all notes and attachments from both." Don't delete the losing record outright; tag it and keep it in an archive table for 30 days in case the merge was wrong. If you're bringing over a legacy CRM's deal history, this matters even more, since a botched merge can silently drop the deal that actually closed.
Standard CSV exports rarely include file attachments, and note history often gets flattened into a single timestamp-free blob of text. Two things help here. First, export attachments separately as a zip with filenames that include the record ID, so you can re-link them programmatically rather than by hand. Second, if your legacy tool has an API — most do, including the ones covered in Replace Salesforce, Replace monday.com, and Replace Notion — pull notes and comments through the API instead of the export screen, since the API usually preserves author and timestamp, which the CSV export drops. If preserving exact history matters for compliance or audit reasons, check the Trust Center for how ViibeStack handles data retention and access logs post-import, so you know what's captured going forward even if the old system's metadata is gone for good.
Never run your first import as your only import. Take a representative slice — 50 to 100 records that include your messiest edge cases, not just the clean ones — and import that first into a test app or a scratch table. Check three things: did dates land in the right timezone, did relational lookups actually connect to the right parent record instead of creating duplicates, and did any values silently get truncated or blank out because a picklist option didn't exist yet in the destination. This is also the moment to build any workflow automation rules you'll need — like auto-assigning new tickets or triggering a welcome sequence for imported contacts — so they don't misfire on thousands of historical records the moment the real import lands.
Once the trial import looks right, scale up, but validate again with fresh eyes before cutover. Pull row counts from the source and destination and reconcile the difference — if you exported 4,812 contacts and imported 4,790, find the 22 before you move on, don't assume they were duplicates. Spot-check a sample of records against the original source side by side, especially any record with attachments, custom fields, or a long note history. If inventory counts or deal values are involved, run a total: sum of inventory quantity or total deal value in the old system should match the new one to the cent. Only after that reconciliation is clean should you set the old tool to read-only and make the ViibeStack app the system of record — running both live in parallel for more than a week or two almost always leads to data drifting apart again.
One thing that makes migrations easier: designing the destination schema before you start mapping columns, rather than letting the old spreadsheet dictate the new structure. If your spreadsheet has