When to Build Your Own Data Importer (And When to Just Pay Someone)

Jeff called me last week with a problem I've seen a dozen times: a prospective client wanted to migrate from their legacy system to BelaStem's marketplace, but their old vendor—Comet—makes it difficult for farms to leave. No API. No clean data export. Just Excel files they can generate manually, in whatever format Comet decides to spit out.

The farm had years of customer data, product catalogs, order history. All of it locked inside a system that charges them monthly and offers zero portability. This isn't malicious; it's just how a lot of B2B SaaS works when the vendor has no incentive to make leaving easy.

Jeff's question was simple: do we build a data importer, or do we charge a higher onboarding fee and migrate each farm manually?

I told him it depends on one number: how many farms are we onboarding this year?

The Manual Migration Tax

When you onboard a client from a legacy system, someone has to do the work. You download their Excel export. You open it. You realize their "Product SKU" column is actually three columns (item code, size, grade) mashed together with hyphens. Their customer emails are mixed with phone numbers in the same field. Half the orders are missing ZIP codes.

Then you spend 4–6 hours cleaning it up, writing throwaway scripts to reformat dates, mapping their old category names to your new taxonomy, and manually importing it in batches to make sure nothing breaks.

If you're onboarding two farms a year, fine. Charge them $1,200 for data migration, spend an afternoon on it, move on.

But if you're onboarding ten? Twenty? You're now spending 40–120 hours a year doing the same work over and over, and every migration is slightly different because Comet's export format isn't standardized across clients.

The Importer Math

Here's the decision tree we walked through for BelaStem.

Option A: Manual migration every time

• 4–6 hours per farm
• $1,200 onboarding fee (covers the labor, barely)
• At 10 farms/year: 50 hours of repetitive work
• At 20 farms/year: 100 hours

Option B: Build a one-time importer

• 12–16 hours to build the importer (mapping logic, validation, error handling)
• Requires sample data first—5 anonymized orders, customers, products from a real Comet export
• After it's built: 30 minutes per farm to run the import and spot-check
• At 10 farms/year: 12–16 hours to build + 5 hours to run = 17–21 hours total
• At 20 farms/year: same build cost, 10 hours to run = 22–26 hours total

The importer pays for itself after farm number three. Everything after that is pure time savings.

But here's the catch: you can't build the importer until you have real sample data. You need to see what Comet actually exports—column names, date formats, how they handle multi-line addresses, whether they use numeric IDs or alphanumeric codes. You can't guess. You need a client who's willing to export a small anonymized dataset so you can build against the real structure.

The Blocker No One Talks About

Jeff identified a farm—San Francisco Gardens, handled by a contact named Juliana—who was ready to switch and willing to share data. The plan: schedule a demo, show them the new platform, then ask for a Comet export with five sample records. Anonymize the names and emails, keep the structure intact.

This is the part that kills most importer projects. You can't build it speculatively. You need a committed client who's already decided to migrate and trusts you enough to hand over their data. If you're still in the "maybe we'll switch someday" phase with prospects, you're stuck doing manual migrations until someone actually commits.

In BelaStem's case, they had the client. So we scoped the importer: a Laravel script that takes Comet's Excel export, validates the structure, maps their fields to BelaStem's database schema, and loads it into the system with error logging. It runs once per farm. It doesn't need to be pretty. It just needs to work reliably and save 4+ hours per onboarding.

When Manual Is the Right Call

If you're onboarding fewer than five clients a year from the same legacy system, don't build the importer. Charge the migration fee, do the work, and spend your engineering time on features that differentiate your product.

The importer only makes sense when:

• You're onboarding 10+ clients/year from the same source system
• The source system's export format is consistent enough to map reliably
• You have a committed client willing to share sample data
• You can afford 12–16 hours of dev time upfront

If any of those conditions isn't true, you're better off doing it manually and investing engineering time elsewhere.

The Onboarding Fee Strategy

One more thing Jeff and I aligned on: even with the importer, BelaStem is still charging a migration fee. Not $1,200—maybe $600–$800—but enough to signal that data migration has value and to cover the 30 minutes of QA time after the import runs.

Some operators waive migration fees to remove friction. I get it. But if you're solving a real problem—getting a farm out of a system that's holding them hostage—the fee isn't friction. It's a signal that you're doing work that matters.

The farms stuck in Comet aren't penny-pinching. They're trapped because migrating their data manually would take them days. If you can do it in 30 minutes with an importer, that's worth paying for.

Questions for You

How many clients are you onboarding per year from the same legacy system? And if the answer is more than five, what's the actual cost of doing those migrations manually instead of building the tool once?