Legacy System Data Migration: Getting the Data Out When There's No API

Most legacy migration guides start with a plan: assess, map, test, migrate, validate. Then they assume you can connect to the old database. One of Google's top results jumps from mapping fields straight to a test run in a staging environment. No step says how the data leaves the old system. Another top guide's customer examples are all database to database: SQL Server to Snowflake, Redshift to Snowflake. Not one of the top results we read covers a system that has no API or export.

Fair enough when your own IT team holds the database password. Not when your new customer is leaving a hosted system that someone else runs. Then you get what the old system lets out, and that's rarely everything. In Rubie's own data, 95% of the source systems we see don't have a clean API or export format that captures all the data a migration needs.

So pick the way out first. It decides how long the migration takes, what you'll fill in by hand, and what your customer loses.

You can shrink the problem by moving less. CRM Switch, a CRM consultancy, suggests a cutoff date for old history and asks, for example, whether "history records over five years old need to be in the new system." Older history can stay readable in the old system or an archive. But core records, open work and the history your customer reports on or has to answer for still have to come over. Our customer onboarding guide has a rule for drawing that line.

Start at the top and go down only as far as the gaps force you. Each step down costs more work and gets you closer to everything your customer actually entered.

In practice you'll combine two or three: the export for the core records, then reports, the screens or PDFs for whatever the export leaves out.

Before anyone opens a single screen, have your customer request their data from the old vendor, in writing. It costs one email, and the answer tells you which ways out you'll need. Have them ask for:

• A full export of every record type, custom fields included.
• Notes, activity history and attachments, and the format each comes in.
• A full backup, if the export leaves anything out.
• The date their access ends, and how long they can still download their data after that.

If your customer is in the EU, the law backs that request. The EU Data Act has applied since 12 September 2025 to providers of "data processing services" that serve customers in the EU, wherever the provider is based. The European Commission's FAQ says that covers software as a service, though not every rule applies to it. The Act gives the customer:

• A notice period of no more than two months to start switching.
• Then up to 30 calendar days to switch, unless the provider shows that's technically unfeasible and sets a longer period.
• At least 30 calendar days after that to retrieve their data.
• When they move to the same type of service and no common standard has been published, an export of their data "in a structured, commonly used and machine-readable format."

Switching charges are capped at the provider's direct switching costs until 12 January 2027 and banned after that. Standard service fees and early termination penalties still apply.

The law has limits. It doesn't make the old vendor build an export it doesn't have: providers "shall not be required to develop new technologies or services." And the right belongs to your customer, who holds the contract, not to you. GDPR's data portability right won't fill the gap either. It belongs to individuals and their personal data, not to a business and its records.

Outside the EU, the contract is what counts. Have your customer find the termination and data-return terms before they give notice. None of this is legal advice.

Once the data is out, check it before anything goes into your product. The National Archives of Australia's migration guidance puts the goal well: automated data validation will help you check "the volume, format and quality of the data being migrated to ensure no data is lost, and the data is fit for purpose." In practice, that's four checks.

1. Count both sides. Count every record type in the old system's own screens and in the extract: accounts, contacts, open invoices, notes, attachments. The numbers should match, or you should know why they don't.
2. Open the files. A line break in a note can split one record across two rows, and a stray comma in an address can add an extra cell. Our free CSV viewer lists the rows whose cell count doesn't match the header, and if an export arrives as JSON, the JSON to CSV converter flattens it first.
3. Check random records, not famous ones. Your customer's admin will check their biggest account anyway. The software agency makandra suggests mapping "a random record of the old application to its new counterpart" because "this prevents a certain bias." Ask for five records nobody would pick.
4. Keep the old ID on every record. CRM Switch recommends storing each record's legacy ID in a field in the new system, so linked history "can be imported at any time." When something turns up missing in week three, you can find it and bring it over.

Do these before go-live, not after. A project manager on a 2001 forum thread about legacy migrations described what happens otherwise: "we'll just dump the information and audit it later," and then "the audit is never done."

Then load a sample and have the customer sign off before you set the go-live date, as the onboarding guide describes.

Rubie is an end-to-end data migration platform for customer onboarding, built for the bottom of the ladder above, where the work is. It gets a new customer's history out of the system they're leaving, even with no API or clean export. That includes web apps behind a login (2FA and captchas too), legacy apps and large PDFs.

“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.”

Rubie uses computer use agents to map each source and build deterministic workflows. Then it cleans and transforms the data, puts it in a review queue with an audit trail, and loads it into your product. Your onboarding team runs it: no clicking through screens, no engineering time, no consultants or new headcount. In Rubie's own data, the average reduction in migration timelines is 50 to 90%.

See how Migration Playbooks work, or how the platform handles each step.

Legacy data is information kept in a system a business is replacing or no longer supports, or in a format its current software can't read. In a migration, it's the history the business has to bring along: customers, transactions, notes and documents built up over years.