Data Migration Automation Mapping, validation and cutover without the spreadsheet
A move from one system to another, field by field, with a mapping you approve and a reconciliation report at the end.
- Installed for you · one-time$249
- Run for you$297/month
- Custom build · this process$5,000–12,000 one-time
- Starts whenManual trigger per phase
Migrations are project work; the subscription price applies to teams running repeated migrations (agencies, onboarding teams). One-off migrations are scoped by object count and complexity. Custom builds start at $2,000 site-wide; this band is for this process and its integrations.
Data Migration Automation is an automation Agentmelt installs in Target APIs (HubSpot, Salesforce, Zendesk…). The free template is a file you import yourself; the kit ($49) adds the setup guide and prompts. Installed for you costs $249 one-time and is live within two working days of access, with a recorded walkthrough and 30 days of fixes. Run for you costs $297/month, with setup and maintenance included. A custom build of this process is $5,000–12,000 one-time; custom builds start at $2,000 site-wide. No call is needed for any option. Written by Max Zeshut; last revised 2026-09-18.
Reference stack: Claude + n8n. Node names are on each step; the file is under the template.
Founder at Agentmelt
Reviews every build before it goes live; the workflow escalates to a person, never past one.
What is data migration?
Data migration automation is a workflow that makes a migration — CRM to CRM, help desk to help desk, database to warehouse — repeatable instead of a one-off spreadsheet of field mappings. It profiles the source (tables, fields, types, null rates, sample values), has an AI agent read both schemas and propose a field-by-field mapping with transformation notes — date formats, picklist translation, ownership — and has the migration owner confirm it; the mapping sheet becomes the versioned source of truth. Transformations generated from the sheet are applied to a sample, validated on record counts, numeric sums, referential integrity and picklist coverage, then dry-run into a sandbox with a reconciliation report. Cutover runs in batches with per-record error capture and a rollback path, and deltas can be re-run for data that arrived late.
- The field-mapping spreadsheet has 400 rows, three authors and no version.
- We found the broken picklist values after go-live, in the reports.
- Every migration is a first time; nothing from the last one is reusable.
- The consultant’s estimate was three weeks; the reconciliation took two months.
- Nobody can say whether every record made it, only that “it looks right”.
If two of these are yours, this is the process to look at first. Free audit — or read on.
What it looks like once it runs.
Migrations fail on mapping and validation, not on moving bytes. The workflow profiles the source, proposes the field mapping with an AI agent that reads both schemas and sample values, lets a person confirm it, applies transformation rules, validates on samples with a reconciliation report, dry-runs, and performs the cutover in batches with a rollback path. The spreadsheet of field mappings becomes a versioned artefact and the migration becomes repeatable.
- Day 1 The source is profiled: tables, fields, empties, sample values.
- Day 1 A field-by-field mapping to the target is proposed; the migration owner reviews and edits the sheet.
- Day 2 Transformations run from the sheet; counts, sums and references are validated; a dry run loads a sandbox.
- Cut-over Production loads in batches with every error captured; the final reconciliation and rollback procedure are handed over.
Mapping 300 fields between two systems is done in a spreadsheet by one person, transformations are ad-hoc scripts, validation is eyeballing, and cutover is a weekend with no way back.
A confirmed mapping with every field's transformation and validation rule, a dry run that reconciles record counts and sums, a batch cutover with progress and error reports, and a rollback plan that was tested. The migration runs on schedule; the team spends its time on the exceptions the validation found.
Trigger, then 8 steps.
Seven of the eight steps run without anyone. Step 03 waits for a person.
Manual trigger per phase
Profile the source
Tables, fields, types, null rates, distinct values and sample rows from the source system (database, CRM export, API).
Propose the mapping
Reads source and target schemas with sample values and proposes field-by-field mappings with transformation notes (date formats, picklist translation, splits/merges) and a confidence per field.
Confirm the mapping
The mapping sheet is reviewed and edited by the migration owner; it becomes the versioned source of truth for every later step.
Apply transformations
Transformations generated from the mapping sheet — type conversions, lookups, deduplication rules — applied to a sample batch.
Validate
Record counts, sums of numeric fields, referential integrity and picklist coverage compared between source and transformed target sample; failures listed per rule.
Dry run
Full transformed dataset loaded into a target sandbox; reconciliation report produced; errors per batch.
Cut over in batches
Production load in batches with progress, per-record error capture and retry; the source stays read-only during cutover.
Reconcile and hand over
Final reconciliation report, error log, the mapping sheet and the rollback procedure archived; the workflow can re-run deltas for late data.
A confirmed mapping with every field's transformation and validation rule, a dry run that reconciles record counts and sums, a batch cutover with progress and error reports, and a rollback plan that was tested
A confirmed mapping with every field's transformation and validation rule, a dry run that reconciles record counts and sums, a batch cutover with progress and error reports, and a rollback plan that was tested.
One decision, at step 03. Seven steps ran without you.
Each pattern page explains it in plain words and lists every automation that uses it.
The template is built on n8n (how the n8n AI Agent node works); the same steps run on Make, Zapier or plain code. The tool is chosen to fit your accounts, you own the result, and the template comes in all three formats.
Data it touches
- Source system (database, CRM/helpdesk export or API)
- Target system API or import
- Mapping sheet (owner-confirmed)
- Validation rules
Guardrails
- No phase runs without an explicit trigger; cutover requires a dry run that passed.
- The mapping is confirmed by a person; the agent proposes with confidence, it does not decide.
- The source is read-only during cutover and a tested rollback exists before the first production batch.
- Every transformed record carries its source id for traceability.
The mapping sheet is the deliverable
A migration's risk is concentrated in the mapping: which field goes where, how it is transformed, what happens to values that do not fit. The agent's proposal — reading both schemas and real sample values — gets a 300-field mapping to a reviewable draft in minutes, with confidence per field so the owner knows where to look. Once confirmed, everything else (transformations, validation, load) is generated from the sheet, which is why the migration becomes repeatable and the sheet is the artefact that matters.
Validate on samples, then reconcile the whole
Sample validation catches mapping errors cheaply; the dry-run reconciliation — counts, sums, integrity — catches what the sample missed. Cutover only starts when the dry run passes. This ordering is standard in data engineering and rare in business-system migrations, which is why those go wrong.
What it connects to.
| Tool | Role in this workflow |
|---|---|
| n8n | Profiling, transformation, validation, batch loading |
| Claude | Mapping proposals from schemas and samples |
| Postgres / BigQuery | Staging and reconciliation |
| Target APIs (HubSpot, Salesforce, Zendesk…) | Loading |
Want this running without building it?
$297/month
We set it up in your tools, run it on our servershost it on our n8n cloud (or deploy it to your own n8n, Make or Zapier), watch it, and fix it when something changes. Setup included, cancel monthly; the automation stays yours if you leave.
$5,000–12,000 one-time
Your systems, your rules, your edge cases. A one-off build delivered into your accounts to keepon Claude and n8n, delivered into your accounts to keep, with documentation and a recorded walkthrough.
Migrations are project work; the subscription price applies to teams running repeated migrations (agencies, onboarding teams). One-off migrations are scoped by object count and complexity.
Also sold one-time, installed in your own accounts, as part of the developers package and the data analysts package and the engineering teams package — do it yourself $49 · installed for you $249 · done for you $490.
When this becomes a custom build.
The subscription covers the standard version — $297/month, setup and maintenance included. Three things move it to a custom build ($5,000–12,000 one-time), delivered into your accounts to keep. If one of them is you, say so on the audit and the plan prices both.
A one-off migration — scoped by object count and complexity rather than run as a subscription.
Source or target systems without APIs, where export and import go through files.
Transformations that need business rules — deduplication policies, ownership mapping, historical fields.
Running the standard version first is the usual path: the exceptions it logs in the first month are the scope of the custom build, with your own numbers. How custom builds work.
Frequently asked questions.
Which systems can it migrate between?
Anything with an export and an import or API: CRMs (Salesforce, HubSpot, Pipedrive), helpdesks (Zendesk, Intercom, Freshdesk), databases, and spreadsheets. Legacy systems without exports need a custom extraction step.
Does it migrate attachments and history?
Yes — activities, notes, tickets and attachments are handled as related objects with their own mapping and integrity checks, which is where most migration effort goes.
Can it run a delta after go-live?
Yes — the same mapping applied to records changed since a timestamp, for a parallel-run period or late data.
What does an AI agent do in a data migration?
The mapping and the explanations: reading the two schemas with sample values and proposing which field goes where, with the transformation each needs — a date format, a picklist translation, a split or a merge. A person confirms every row. The moving, validating and loading are deterministic steps that run from the confirmed sheet; the agent never decides what to load.
How is the migration validated?
Four checks per batch, compared between source and transformed target: record counts, sums of numeric fields, referential integrity (every child has its parent) and picklist coverage (every value has a translation). Failures are listed by record, fixed in the mapping sheet, and the sample re-run before anything touches production. The dry run into a sandbox produces the same reconciliation for the full dataset.
Is data migration sold as a subscription or a project?
A migration is a project: scoped by object count and complexity, priced as a custom build, with the workflow, the mapping sheet and the rollback procedure handed over at the end. What stays useful afterwards is the delta run — late data after go-live — and the same workflow serves the next migration.
What this blueprint is built on.
Vendor documentation the steps rely on, and the rules the guardrails are written against.
- PostgreSQL — documentation www.postgresql.org/docs/
- HubSpot — API overview developers.hubspot.com/docs/api-reference/latest/overview
- n8n docs — Wait node (approval steps) docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.wait/