Build vs buy for data migration comes down to how often you migrate a customer. If every deal you close starts a migration, buy. If you build, your engineers own a new script for every customer, usually for a system with no clean export, while onboarding waits.
Brivity's team faced this choice. They looked at building it in-house and found it would have needed significant engineering resources and cut into the product roadmap. This guide is for people in their seat: you run onboarding, implementation or customer success at a software company, you need the data moved, and you don't write the code.
Build vs buy data migration: the short answer
Most build vs buy advice treats a migration as one project: one old system, one new one, one cutover. Build if you have the engineers, buy if you don't. That advice is written for a CTO moving their own company, once.
You're in a different spot. The source is whatever your new customer is leaving: a competitor's product, a legacy app, a stack of PDFs. Next month it's a different one. So the question isn't "can our engineers write this script?" They can. It's "do we want them writing one for every customer, forever?"
If every customer shows up with a clean export your importer already reads, you don't have this problem. In Rubie's data, that's rare: 95% of the source systems we see don't have a clean API or export that captures all the data a migration needs.
What in-house data migration scripts really cost
Here's the job, for every new customer:
- Get in. The data sits behind your customer's login, often with two-factor authentication.
- Find it. Records are spread across screens, reports and attachments. Our guide to legacy system data migration ranks the ways to get data out.
- Clean and map it. Fix duplicates, date formats and missing values, then match their fields to yours, one by one.
- Check and load it. Someone proves nothing is missing before go-live, then it goes into your product without breaking what's already there.
Then the old system changes a screen, the script breaks, and the ticket goes back in the engineering queue.
And none of it carries over. One SaaS company described it on Reddit: each new customer's data "turned into a week or two of someone on our side mapping fields by hand." Later in the thread: "Right now every mapping dies with the account."
Put a number on it. The US Bureau of Labor Statistics puts the median software developer's pay at $135,980 a year (May 2025). Wages make up 70% of what private employers spend on pay and benefits (June 2026). That puts a developer's full cost at about $194,000 a year, or roughly $3,700 a week, by our estimate, before recruiting, equipment and management.
Now say each migration takes one engineer-week, the low end of that poster's "week or two." At 50 new customers a year, that's about $187,000: close to one engineer's full year, spent on nothing but migrations.
Engineering time spent on migrations in a year, at one engineer-week per customer
At about $3,700 per engineer-week, 10 new customers a year cost about $37,000 in engineering time, 25 cost about $93,000, and 50 cost about $187,000, close to one engineer's full year.
That's only the time you can count. It leaves out the go-live date that slips while the ticket waits, and the roadmap work those engineers didn't ship. Rubie customer Cariina, which connects to schools' student information systems (SISs), felt the second one. As its team put it: "we couldn't work with a lot of SISs out there because we knew it was going to take a lot of our engineering team to adapt all of those exports."
Can Claude Code or Codex write your data migration scripts?
Yes, and that's why people are asking this again. Anthropic describes Claude Code as "an agentic coding tool that reads your codebase, edits files, runs commands, and integrates with your development tools." OpenAI calls Codex CLI a "lightweight coding agent that runs in your terminal." Your engineers are likely using or planning to use one: 84% of developers use or plan to use AI tools, in Stack Overflow's 2025 Developer Survey.
Now read the fine print. Claude Code's security docs say: "You're responsible for reviewing proposed code and commands for safety before approval." OpenAI says Codex works inside a sandbox, with "an approval policy that controls when it must stop and ask you before acting." Both keep a person answerable for what the agent does. That's the right design for a coding tool. It also means a person on your team stays on the hook.
Developers know the catch. In the same survey, 66% named "AI solutions that are almost right, but not quite" as their biggest frustration. Almost right is fine for a first draft. It isn't fine for a customer's years of history on go-live day.
So an AI coding agent makes the script cheaper to write. It doesn't make it cheaper to own.
Build vs buy data migration, side by side
Same job both ways: one new customer's history, out of the system they're leaving and into your product.
| Question | In-house scripts | Rubie |
|---|---|---|
| Who runs it | Your engineers, with or without an AI coding agent. | Your onboarding team. |
| Where the data comes from | Whatever the old system's API or export lets out. | Systems with no API or clean export too: the screens behind the login, legacy apps, PDFs. |
| Logins and 2FA | Handled in code, source by source. | Handled in Rubie's Authenticate step, including 2FA and captchas. |
| The next customer | A new script, or an old one bent to fit. | Rubie maps the new source and builds its workflow. |
| Checking the data | Whatever checks the engineer wrote. | Doubtful records go to a review queue. Every approve, reject and edit is logged. |
| Customer credentials | Wherever the script keeps them. | AES-256 encrypted at rest and scoped to a single workflow run. |
| Control of the code | All yours. | Rubie runs the workflow. Your team controls the review queue. |
| What you pay | Engineering time, on every migration. | A platform fee, in place of that engineering time. |
The first row is the one your team feels. Curbwaste put it plainly: "The conversational mapping took the technical piece away from our implementation managers. They can just explain what they want to do." Behind that, there are six steps: Authenticate, Navigate, Clean, Transform, Review, Load.
No-code and self-service alternatives to custom data migration scripts
Look for alternatives to in-house migration scripts and you'll find three kinds. Each one covers part of the job:
- CSV importers. A self-service upload screen inside your product. They work once the customer has a clean file. Getting that file out of the old system is still someone's job.
- ETL and integration platforms. They move data between systems through APIs and prebuilt connectors. The system your customer is leaving usually has neither.
- Migration services firms. People do it for you, one project per customer. Prospects tell us those projects run to six figures each.
Rubie does the whole job, from logging in to the old system to loading clean records into your product, and your onboarding team runs it without engineering time. We call that a Migration Playbook.
How to decide between build and buy
Three questions you can answer this week, without reading a line of code:
- How many migrations will you run next year? Take the new customers in your sales forecast and multiply by the engineer-weeks each migration took last quarter.
- How many new customers arrive with a clean export? Look at the last ten. Every one that didn't is a script, or a go-live that slipped.
- Who answers for the data on go-live day? If it's "the engineer who wrote the script," ask what happens when that engineer is busy on roadmap work, on vacation or gone.
If your answers are "a lot," "few" and "an engineer," you're already paying for a migration team you never hired. Our customer onboarding guide shows where that work sits in the rest of onboarding.
Customer data migration software: onboard more customers without hiring
Brivity chose not to build. With Rubie, its average import turnaround dropped from 10.6 days to 5.3 days, and the team saved approximately 4,500 business hours, more than two years of one person's full-time work. Cariina went from 3 supported student information systems to 23+. And Granum can now work with files it once couldn't:
"We've had (customers) who give us those 250 page PDFs, and in the past we couldn't even work with them, but now we have Rubie."
In Rubie's data, the average reduction in migration timelines is 50 to 90%. Your engineers get their sprints back. Your onboarding team gets a finished migration, not a toolkit someone else has to maintain.
