Data Mapping for Customer Migrations: A Worked Example

Wikipedia calls it "the process of creating data element mappings between two distinct data models." Accurate, and no help when you're staring at a customer's export. In plain terms, every map has three parts:

• The source: a field in the system your customer is leaving.
• The target: the field in your product where it lands.
• The rule: what happens on the way. Copy it, split it, reformat it, or look it up in a value map that turns an old code into one of your options.

Field rules are what most guides show. In a customer migration, the value maps matter just as much: what "HLD" in the old status column means in yours, and which old user owns an account now.

You'll also see data mapping in ETL (extract, transform, load), where it describes a standing pipeline that copies data between systems on a schedule. A customer migration is different: it runs once, and there's a customer on the other end who has to agree to the result.

Here's a data mapping example. A new customer runs a plumbing business and is moving their client list into your product. Below is one client record from their old system, and where each field goes.

Your team can write most of those rules without asking anyone. Just don't get these wrong:

• IDs stay text. An account number like 000418 looks like a number, and spreadsheets treat it like one. Microsoft says that when you add a value like 00123, "by default Excel converts it to the number 123." So the rule says "keep as text," and nobody's spreadsheet gets a vote.
• Dates need their format written down. 03/04/2025 is March 4 in New York and April 3 in London. Read it the wrong way and nearly every date up to the 12th lands in the wrong month, with no error to tell you.
• Some fields only live on a screen. The account number in this example never made it into the export. That's common: by Rubie's own data, 95% of the source systems we see don't have a clean API or export that captures all the data a migration needs. So map from everything the old system shows, not the export alone. Our guide to legacy system data migration covers how to get the rest.
• Your required fields need a source too. The old system never had a region. Your product requires one. Decide the default before the first load fails on it.

Before any of this, open the export and check it reads cleanly. Our free CSV viewer lists the rows whose cell count doesn't match the header.

Four rows in that table need your customer, because only they know the answer:

• Codes with no match. What does HLD mean to them, and which of your statuses fits?
• How much history moves. All 212 notes, or the last few years? Our customer onboarding guide has a rule for drawing that line.
• Who owns what. Which user takes over accounts from reps who've left.
• What stays behind. The fax numbers, and every other field with no place in your product.

Bring them those four, and nothing else. One data analyst writing about migrations put it best: "Do not send a spreadsheet with four hundred rows and ask for approval. You will get silence, and silence is not approval."

Instead, send each decision with real values from their own data: "23 clients have status HLD, including these five. Should they be Inactive or Prospect?" Send a handful at a time, as you find them. The plain one-to-one rows, like Client Name to Account name, your team approves itself.

Once the decisions are in, load a sample and have your customer check it before you set the go-live date.

Partly, and the part it does well is the field matching. A 2024 study found that language models can help speed up schema matching "solely based on schema element names and descriptions without the need for data instances." Asking a model to do the whole job at once is another matter. On one healthcare benchmark, prompting a model to transform a source table straight into the target database got 14.35% accuracy, against 54.78% when the researchers split the work into steps.

Even then, a model can't know what HLD means to your customer. CurbWaste ran into exactly this before Rubie. Most of the ETL tools it tried "could map columns but couldn't handle the business logic transformation required before data was even ready to map."

“Rubie gets the business logic and recommends things, versus us having to tell a system exactly where to put it.”

If you're mapping by hand, write every rule down in one place. This template is your team's record of decisions. Your customer never fills it in. They see only the rows marked for them.

Download the data mapping template (CSV). It opens in Excel or Google Sheets, and it comes filled in with the nine rows from the example above. The columns:

• Old field and where it lives: the label your customer sees, and whether it's in the export or only on a screen.
• Sample value: a real value from their data, so the rule is checked against something.
• Your field and the rule: where it lands, and what happens on the way, in plain words.
• Mapping type: one to one, split, value map, reformat, one to many, default, or not migrated.
• Value map: old code to new option, one pair after another.
• Required in your product: yes or no.
• Who decides and status: your team or your customer, and whether it's approved yet.

Fill it in backwards: start from your product's required fields and work back to the old system.

Every migration teaches you something about the system your customer left. With Rubie, that knowledge stays: Rubie remembers mapping rules, transformation logic, and validation checks so repeated migrations become faster every time. I've argued before that mapping knowledge should compound, not disappear when the project closes. This is what that looks like.

Rubie uses computer use agents to map each source and build deterministic workflows. It reshapes every record to fit your product's fields, with field mapping, type conversion and value maps. Anything that needs a human look goes to a review queue, where your team approves, rejects or edits it. Every change is logged. Your onboarding team runs it, with no engineering time and no spreadsheet of four hundred rows. By Rubie's own numbers, migration timelines come out 50-90% shorter on average. See how the steps fit together on the product page, or how Migration Playbooks run a customer migration end to end.