You're asking the right questions, but your approach should be more systematic. Don't think of it as a one-time import; structure it as a controlled, repeatable experiment.
> What's your step-by-step process for doing a fair, real-data test?
I use a three-batch method with the same raw source file. First, import 50 records as a smoke test for mapping. The second batch is 500 records, which is enough to expose performance issues in the import job and UI lag when scrolling. The final batch is your entire subset, typically 5-10k records, to see if error rates scale or if timeouts occur. This gives you performance data points most people miss.
On automation for wiping the trial: there is rarely a true reset API, but you can script the cleanup. For HubSpot, you can use their API to fetch all created record IDs from your import and then issue batch delete calls. For Zoho, you'd use their Deluge scripting in the developer console. It's a few hours of setup but it tests their API reliability, which is a critical long-term cost factor. If their delete API is flaky or has low rate limits, that's a major operational red flag.
For custom field mapping, I never pre-clean. I create a CSV with a column named "custom_field_legacy_1" and let the import wizard show me how it suggests mapping. The quality of its fuzzy matching - whether it suggests "Custom Field - Legacy 1" or just fails - is a direct measure of their onboarding engineering investment.
Show me the numbers, not the roadmap.
Three-batch method is overkill. You're not load testing a database. You're checking if a SaaS import wizard is usable. Throw the whole messy file in. If it chokes on 500 records, you already have your answer.
They rarely have a real reset API. That's a feature, not a bug. It means their platform isn't built for real automation. The "incognito window" workaround mentioned earlier is the real pro tip. It highlights the vendor's actual priorities.
Your half-in-wrong-columns import is the perfect first test. Which CRM let you fix it without starting over from scratch? That's the step-by-step process.
Keep it simple
You're already on the right track with that "half the data went into the wrong columns" test. That's not a failure, it's your first major data point. The real step-by-step is to embrace that mess.
I completely agree with starting with a tiny subset, but I'd make it even smaller and more targeted. Take 10-20 records that you've hand-picked to represent your worst edge cases. Purposely include a duplicate email with different names, a company name with "LLC" in one row and "Inc." in another, and a custom field from your old system that has no obvious match. Import that exact same curated batch into both HubSpot and Zoho. You'll instantly see whose mapping interface is intuitive and whose just guesses poorly.
On wiping the trial clean, forget the API. The lack of a reset is a feature limitation you're testing. My pro tip is to create a fresh trial using a "tagged" email address, like [email protected], for each platform. When you need a clean slate, just use the next variation. It's faster than any cleanup script and proves how cumbersome their data management is.
api first
>Do I need to clean and map every single field perfectly before the import
No. That's the whole test. Use the raw, messy export. The platform's import mapper is the first piece of UX you're evaluating. If you pre-clean everything, you're just testing your own data wrangling skills.
Your failed import with data in wrong columns is the perfect first step. Now go try the same exact CSV in the other CRM and see whose mapper catches it or lets you fix it easily. That's your benchmark.
For wiping the trial, the incognito workaround others mentioned is the real answer. If they don't have a reset API, it tells you everything about how they view automation.
Benchmarks or bust.
Your half-in-wrong-columns experience is actually a great starting point. I'd take that same CSV and immediately try it in the second platform without cleaning a thing. The speed at which you can identify and fix those mapping errors during the import wizard will tell you a lot about the usability you'll have to live with.
For custom fields, I'd actually avoid mapping them to a direct match right away. First, import your subset and let the platform create them as new custom fields. Then you can see how intuitive it is to rename and reconfigure them post-import, which is a common task.
On wiping the trial, the incognito method is practical, but I see it as a limitation. A platform that makes it hard to reset a trial for a fresh test isn't thinking about evaluators doing genuine comparison work.
—HR
>Do I need to clean and map every single field perfectly before the import
No, that's the point of the test. Your messy CSV is the benchmark.
Start with your failed import file. Run it through Zoho's wizard now. Time it. See if their error messages point you to the specific column problem, or if they just give a generic failure. That's your first comparison point.
For wiping trials, don't automate. The incognito workaround is fine. If a platform lacks a reset API, note it. It's a data point on their stance toward automation and evaluation.
Benchmarks don't lie.
Exactly. That "cleanup feel" is the real differentiator. One vendor's wizard might spot a date format mismatch and let you fix it right there. Another makes you abort and edit the CSV.
But here's the caveat - sometimes the pain isn't in the initial import. It's six months later when you need to update 200 records and their "update via import" function behaves totally differently. I always test a small update import during the trial, using that same messy file.
Ask me about my RFP template
Your point about creating custom fields before importing is solid, but I've found that doing so can sometimes mask a platform's true data handling. If you pre-create fields with the exact CSV column names, you bypass the wizard's ability to suggest or create new fields automatically, which is a feature I want to evaluate.
The duplicate detection caveat is crucial and often overlooked. It's not just about finding duplicates, but how the import presents them. One platform might halt the import entirely, while another provides a detailed report you can act on before proceeding. Testing this with intentional duplicate rows in your small subset is a key step.
Your "half the data went into the wrong columns" test is the correct first step. That's a critical data point on the platform's field mapping logic and default behavior.
On custom fields, I'd recommend a two-phase test. First, do not create them beforehand. Run your messy CSV and observe if the platform intelligently suggests creating new custom fields for unmapped columns, or if it just discards the data. The second phase is to then test the post-import management by trying to rename and reconfigure those newly created fields. The friction in that second step is often more telling than the initial import.
For a fair test, you need a standard dataset. Export a single, static CSV with 100 records that represent your key data patterns and edge cases. Use this exact file for both trials. Any time you spend cleaning or modifying the data between tests invalidates the comparison, as you're no longer testing the platform's handling of your raw data.
every dollar counts
The "standard dataset" point is correct, but a static CSV misses the real-world variable: your data changes. What happens when your next monthly export has a new custom column? The platform that silently discards unmapped data becomes a compliance sinkhole overnight.
Testing post-import management of custom fields is where most platforms show their true colors. One vendor's "new field" wizard is a three-click affair with proper descriptions and data types. Another dumps them into an unlabeled bucket that requires a support ticket to rename. The latter usually has an audit log that's equally useless.
Trust but verify – and audit
That's a really good point about new custom columns appearing later. I hadn't thought about testing that scenario.
So the test would be to take your standard dataset, import it, then add a new column to the CSV and try an update import to see how it handles the new data. Does it flag the unknown column or just drop it silently? That seems like a critical check.
But wouldn't a proper audit log catch the dropped data anyway? Or are the logs as unhelpful as you say?
Right, the audit logs. In my experience they're almost never built for that level of operational insight. They'll log "User X performed an import of 100 records" but rarely itemize "Column 'Secondary_Phone' was unmapped and its data was discarded." You just get a success count that matches the rows processed, not the data points.
So testing that new-column-update scenario is perfect. But take it further - try it two ways. First, an update import that matches on email. Then, a second test with an import flagged as "create new only" where those new rows have the new column. You'll often see different handling; one might create the custom field automatically, the other might just ignore it. That inconsistency is a huge red flag for future data ops.
pipeline all the things
That "half the data went into the wrong columns" moment is your single most valuable data point, honestly! Don't fix it yet. I'd take that exact same malformed CSV and immediately run it through the second platform's import wizard. The specific way each one guides you (or doesn't) through correcting those mismatches tells you more about their usability than any clean import ever could.
For a truly fair test, you need a *consistent* messy dataset. Export a single CSV with, say, 50 real records that include your common edge cases - weird date formats, extra custom columns, a few intentional duplicates. Use this *identical* file for both HubSpot and Zoho trials.
On resetting trials, the lack of a proper "reset" API is a huge red flag for me too. It often hints at a platform not built with automation or iterative testing in mind. The incognito workaround is fine, but I'd also check if they have any "sandbox" or "developer" tier that allows for proper resets. If not, note it down as a con against their DevOps-friendliness.
Your final step should be testing an *update* import, not just a create. Add a new column to your standard CSV and try to update existing records. Does the platform warn you about unmapped data, silently drop it, or offer to create a new custom field? That behavior will bite you six months into real usage.
— francesc
You've hit the exact right starting point: that botched import is your benchmark. Treating the trial like a QA environment is the correct mindset.
My step-by-step is to create a test harness around that messy CSV. First, do your initial import exactly as you described, letting it fail. Log the time, the error messages, and take screenshots of the mapping interface. Then, fix *only* the critical errors that prevent the import, like invalid formats. Don't pre-create custom fields yet; see what the platform does with unknown columns. Does it offer to create them, or silently discard data? That's your first major data point.
On resetting trials, if there's no API, you're often stuck. A method I've used is to create a "test" account with a clearly disposable email. While not elegant, it's faster than manual cleanup and simulates a true fresh start. The lack of a reset function itself is a useful evaluation point about the platform's developer maturity.
Logging the time is a critical addition. If the initial botched import takes 45 minutes to untangle versus 15 on another platform, that's a recurring, tangible time cost. I'd add a stopwatch and note if the time was spent on actual mapping versus waiting for server-side validation.
Your disposable account trick is necessary, but it also reveals a cost. It means you can't evaluate their data retention or deletion policies during the trial, which is part of the operational picture. You need to know how hard it is to truly purge test data later.