September 15, 2026
Most data migrations don't fail during the import -- they fail two weeks earlier, when someone exports a spreadsheet without checking what's actually in it. Merged cells, inconsistent date formats, phone numbers stored as text in one column and numbers in another, deal stages that were renamed three times over two years. If you carry that mess into a new system, you don't get a fresh start -- you get the same mess with a new coat of paint. The goal of this guide is to get your contacts, deals, and operational spreadsheets into ViibeStack's CRM and related modules with their history intact and their duplicates gone, not just their rows copied over.
Before touching an import tool, open your source files and answer three questions: What fields actually get used? Which ones are empty, stale, or duplicated in another sheet? And which records have relationships you need to preserve -- a deal tied to a contact, a contact tied to a company, a task tied to a deal? Spreadsheets rarely enforce these relationships explicitly, so you have to reconstruct them by looking at shared IDs, matching email addresses, or repeated company names across tabs. Write this down as a simple map: source column -> destination field -> relationship. This is tedious but it's the single highest-leverage hour you'll spend in the whole migration.
Excel and Google Sheets exports cause the same handful of problems every time. Dates get stored in whatever regional format the original author's machine used, so 03/04/2024 might mean March 4th or April 3rd depending on who typed it -- standardize to ISO format (YYYY-MM-DD) before export. Phone numbers and zip codes with leading zeros get silently stripped when a column is formatted as a number; reformat those columns as text first. Merged cells in Excel export as blank cells in every row except the first, which breaks row-by-row imports -- unmerge everything and fill down before exporting. And multi-select fields (like tags or product interests) often get crammed into a single cell separated by commas, semicolons, or line breaks inconsistently across rows -- pick one delimiter and enforce it everywhere before you save the CSV.
When you upload a CSV, most import tools will auto-map columns based on header names, and it will get some of them wrong -- "Company" might map to a free-text field when you actually want it linked to an existing account record. Go through the mapping screen line by line rather than trusting the defaults. Pay particular attention to status and stage fields: if your old spreadsheet had "Won," "Closed-Won," and "Deal Closed" as three different values for the same outcome, decide now which single value they all map to, rather than importing three inconsistent labels that will wreck your analytics and reporting later. The same logic applies to lead sources, priority levels, and any dropdown-style field -- consolidate variants before import, not after.
Deduplication is far easier in a spreadsheet than in a live database. Before import, sort your contact list by email address (your most reliable unique identifier) and flag exact matches, then sort by name and company to catch near-duplicates with typos or different formatting ("Bob Smith" vs "Robert Smith"). Decide your merge rule in advance: usually the most recently updated record wins, but notes, tags, and activity history should be combined rather than overwritten. If you're pulling from multiple sources -- say, a sales spreadsheet and a separate mailing list -- dedupe within each source first, then dedupe across sources using email as the match key. Most CSV importers, including ViibeStack's, let you set a dedupe field on import; use it, but treat it as a safety net, not your primary cleanup method.
A spreadsheet usually only shows you the current state of a deal or contact -- not how it got there. If history matters to you (and for sales pipelines, it usually does), you need a separate export of activity logs, email threads, or notes, and a plan for attaching them to the right record after the core import. This is where a lot of teams cut corners and regret it six months later when someone asks "when did this account go quiet?" and there's no answer. If your old system supports an activity or notes export, bring it over as a secondary import mapped by contact ID or email, even if it takes an extra pass. It's also worth checking your integrations options -- if your old CRM has a live connector, a direct sync can sometimes preserve more context than a CSV round-trip.
Never point your whole team at the new system the same day you finish importing. Run a validation pass first: check record counts against your source (if you exported 4,200 contacts and imported 3,950, find out why before assuming dedupe explains the gap). Spot-check a sample of records across different sources -- pick ten contacts, ten deals, and confirm every field, tag, and relationship landed where it should. Have someone unfamiliar with the migration try to complete a real task, like finding a specific customer's deal history, to catch mapping issues you're too close to notice. Only after this validation should you archive the old system and treat ViibeStack as the source of truth -- and even then, keep a read-only copy of your original exports for at least a few months in case something surfaces later.
If you're doing this migration because you're leaving a specific platform, it's worth reading the tradeoffs specific to that move -- we've written detailed comparisons for teams coming from Salesforce, HubSpot, and Airtable, each of which has its own quirks around field types and relationship exports. And if the spreadsheets you're migrating were never meant to be a real system in the first place -- just a workaround that grew too big -- it might be worth rethinking the structure entirely with ViibeStack's AI app builder rather than replicating the spreadsheet's shape as-is.