Data Architecture

Source to Target Mapping Generator

Two column lists in, a draft STM out with the gaps and the dropped columns called out explicitly.

Loading the tool…

Processing happens locally in your browser. What you paste or load is processed by this page and is not uploaded to a server. Nothing is stored unless you use a control that says it stores something, and you can clear anything this site has kept from the privacy page.

How to use this tool

  1. Paste the source columns in the first box: one per line, a CSV header row, or CREATE TABLE statements.
  2. Paste the target columns in the second box, in any of the same three forms.
  3. Select Build mapping.
  4. Go straight to the unmatched and dropped rows, then write the real transformation rules over the placeholders.

What source to target mapping generator does

The matches are the easy half of a mapping document and you could have done them by eye. What matters is the two lists at the end: target columns that nothing feeds, which are the gaps in the design, and source columns that go nowhere, which are either dropped on purpose or dropped by accident — and an accidental drop looks exactly like a deliberate one right up until reconciliation fails.

Paste the source columns in the first box and the target columns in the second, as one name per line, a CSV header row, or CREATE TABLE statements. Names are matched exactly first, then loosely if you leave near matching on, with anything more than a small edit distance left unmatched rather than guessed at. Every near match is labelled as needing confirmation, and every transformation rule in the output is a placeholder until someone who knows the data has written the real one.

Frequently asked questions

By name. Exact matches are made first after stripping case, underscores and punctuation, so CustomerID and customer_id pair up. If near matching is on, the remaining columns are paired by edit distance with a deliberately tight limit — a quarter of the name and never more than three characters — so cust_id will not silently claim customer_id and every near match is labelled as needing confirmation.

Because a source column that goes nowhere is either deliberate or an oversight, and the two look identical in a mapping document. Naming them explicitly forces the question while it is cheap to answer, rather than during reconciliation when a figure does not tie out and nobody remembers why the column was left behind.

Yes. Either box accepts one name per line, a CSV header row, or CREATE TABLE statements — the columns are read out of the DDL for you. The two boxes can use different forms, so a CSV header on the source side and DDL on the target side works.

No, and the output says so. Every rule is a placeholder: direct copy for an exact match, a request for confirmation for a near one. The transformation logic is exactly the part that requires someone who knows what the data means, and a tool that invented it would produce a document that looks finished and is not.