The mapping lives in a spreadsheet
Conversion rules get written in prose, negotiated over email, and half-remembered. None of it is executable, so somebody re-types it into a script — and the script is now the only thing that knows what was agreed.
Enterprise data migration
Move data. Faster.
FerryMap compiles your mapping into a locked, executable rule file — then runs it on a deterministic engine. Same input, same rules, same output. Byte for byte, every time.
No model ever touches your data.
Sources
- DatabasesPostgreSQL · Oracle · SQL Server
- FilesCSV · Excel · Delimited · Parquet
- APIsREST endpoints
Compiled rule file
- LOC_CDLOCATION_ID
- SITE_NAMELOC_DESCR
- EFF_DTSTART_DATE
- STATUSLOC_STATUS
Approved by a human · executed byte for byte
Targets
- DatabasesPostgreSQL · Oracle · SQL Server
- FilesCSV · Excel · Delimited · Parquet
- APIsREST endpoints
- Runs inside your environment
- Every value traceable to the rule that produced it
- Nothing lands unvalidated
The problem
Migrations don’t fail on volume.
They fail on meaning.
Moving rows is the easy part. Agreeing what each column means in the target system, encoding that agreement so a machine can enforce it, and proving afterwards that it was enforced — that is where cutovers slip.
The script is a one-off
It was written for cutover weekend, under time pressure, by whoever was free. Run it again six months later and nobody can promise you get the same rows back.
Nobody can prove what landed
A value in the target looks wrong. There is no path from that value back to the rule that produced it, or the source row it came from. The investigation is archaeology.
FerryMap closes all three. The mapping becomes the program. The program is deterministic. Every value it writes carries its lineage.
How it works
Three steps. One of them is yours.
FerryMap proposes; you approve; the engine executes. The order is not negotiable, and the approval cannot be skipped.
1Process
Describe the mapping
Hand FerryMap your conversion rules in plain English, with your source and target schemas. No mapping document? Point it at matched source and target rows plus a confirmed business key, and it derives the mapping from the data itself — measuring every candidate rule against your real records rather than guessing at them.
- Plain-English rules, one workbook or separate files
- Schemas from a DDL file or read live from the system
- Source data over a database, an API or a file
2Validate
Review and approve
The mapping is compiled into a rule file, and every rule is checked in plain code against your real schemas: does the source field exist, does the target field exist, is the function permitted, do the code-map keys appear in the data, do the types and lengths fit. Rules that cannot be verified are rejected rather than softened. What survives arrives in a diff-style review carrying its confidence and the exact mapping sentence it came from.
- Provenance on every rule — which sentence produced it
- Ambiguity raises a question instead of a guess
- Below threshold, nothing executes until a person signs off
3Upload
Run it, and run it again
A deterministic engine executes the approved rule file. It validates against your target schema before anything lands, quarantines rows it cannot transform with a reason code, and writes a reconciliation report for the run. Run it today, run it at cutover, run it a year from now — the same inputs and the same rules produce the same output.
- Byte-identical reruns, proven by test rather than promised
- Quarantine with a reason code, never a silent drop
- Reconciliation report and manifest for every run
Who it's for
Built for the people who sign off the cutover
Migration leads
You have to put your name under the sentence “the data is correct.” FerryMap gives you the evidence to sign it — and the report that survives the question six months later.
Planning & ERP implementation teams
Master and transactional data has to move between ecosystems with different names, types, codes and formats for the same facts. The mapping is the deliverable; FerryMap makes it executable.
Systems integrators
You run the same migration shape across many clients. FerryMap turns that shape into something repeatable rather than heroic, and keeps the rules from each engagement.
Why you can trust the output
Correctness you can demonstrate, not assert
Every claim below is a mechanism in the product, not a promise about how carefully we work.
No model touches your data
AI reads your mapping document and proposes rules. A deterministic engine transforms the rows. The separation is structural, not a policy someone has to remember.
Every rule is verified mechanically
Field names, permitted functions, code-map keys and type and length feasibility are all checked in plain code against your introspected schemas. A rule that cannot be verified never reaches the engine.
A human holds the gate
Rules below the confidence threshold, or carrying an unresolved finding, block execution until they are explicitly approved. Rules derived from data can never auto-approve at any confidence.
Byte-identical reruns
Determinism is a tested contract rather than a claim: the same inputs and the same rules are proven to produce identical output, across two independent execution engines.
Complete lineage
Every target value traces back to the source row, the rule that produced it, and the version of the rule file that rule belonged to. Every action traces back to a person.
Fail loudly, quarantine gracefully
Rows that cannot be transformed or validated go to quarantine with a reason code. Silent drops and silent coercions are treated as defects, not as tidiness.
Connects to
Reads from. Writes to.
Source and target are independent choices. A database can feed a file, a file can feed an API, and the rules do not change because the transport did.
Databases
PostgreSQL · Oracle · SQL Server
- As a source
- Schema and constraints read live from the catalogue, so the rules are compiled against what the system actually holds.
- As a target
- The batch is staged, then merged into the target in a single transaction. Re-running converges instead of duplicating.
Files
CSV · Excel · Delimited · Parquet
- As a source
- Structural inputs can arrive as one workbook with tabs assigned to roles, or as separate files.
- As a target
- Output is written under versioned names. A rerun never overwrites an earlier run's output.
REST APIs
API key · Bearer · Basic auth
- As a source
- Endpoints are profiled to derive the source schema before any rule is compiled against them.
- As a target
- Every request carries an idempotency key, is rate-limited and sequential, and every attempt is recorded in the run manifest.
Validated before it lands. Whatever the target, output is checked against the target schema — types, lengths, nullability — before anything is written. Only clean, conforming data moves forward.
Security & deployment
Runs inside your walls
An enterprise migration touches the most sensitive data an organisation has. FerryMap is built so that data never needs to leave.
Deploys into your environment
FerryMap ships as containers and runs where your data already lives. There is no requirement to send rows to us, and no external service in the transformation path.
Credentials encrypted at rest
Connection secrets for source and target systems are stored encrypted, and are never rendered back into any screen, log, response or report.
Every action attributed
Who created the job, who approved which version of which rule, who started the load, and when. The audit trail is written as the work happens, not reconstructed afterwards.
Roles, separated
Administration — users, connections, settings — is separated from day-to-day operation, so running a migration does not require the rights to reconfigure one.
FAQ
The questions enterprise buyers ask first
Only the compile step involves a model, and only to read your mapping document alongside your schemas and a small number of masked sample values. It emits rules, never rows. The transformation itself is executed by a deterministic engine with no model anywhere in the path.
You fix the rule, not the row. Corrections are made by editing the mapping and recompiling, which produces a new version of the rule file that is re-run over the data. FerryMap never makes an ad-hoc per-row edit — a fix that applies to one row and not the next one is not a fix.
Yes. Every target value traces back to the source row, the rule id and the rule file version. Each run produces a reconciliation report and a manifest, and the quarantine file lists every row that did not make it along with the reason it did not.
Then supply matched source and target rows and a confirmed business key. FerryMap derives candidate rules from the data, executes each candidate through the real engine, scores it on rows it has not seen, and shows you what survived along with the statistical evidence. Rules derived this way always require explicit human approval — they can never auto-approve.
In your environment, as containers, alongside the systems it reads from and writes to. There is no requirement to move your data to us.
They go to quarantine with a reason code and are reported at the end of the run. They are never silently dropped, and never silently coerced into a value that happens to fit the target column.
Databases (PostgreSQL, Oracle, SQL Server), files (CSV, Excel, delimited, Parquet) and REST APIs — on either side of the move. Source and target are chosen independently of one another.
Get started
Tell us what you’re moving
Bring a real mapping and a real target schema. We’ll walk it through FerryMap end to end — compile, review, run — and you keep the rule file and the reconciliation report from the session.
Opens your mail client with a short template. Goes straight to the team — no newsletter, no sequence.
Helpful to include
- The systems you are moving between, on both sides
- Roughly how many rows, and how many tables
- Whether a mapping document already exists
- When you need to be live
Built by
YAE Services