Your customer’s data, migrated by an agent you can watch
Vern reads whatever your customer can export — spreadsheets, CSVs, a zip of PDFs, a legacy API — drafts an import plan in plain English, stops to ask when something is genuinely ambiguous, and writes validated records into your product.
- ISO 27001 certified
- US & AU data residency
- Audit-ready logs
Reading your uploaded files
4 files · 18 sheets
4 source files
- owners_export.xlsx2 sheets · 1,204 rows
- lots.csv486 rows
- invoices_2019-2024.zip312 files
- insurance_certificates.pdf18 pages
| First name | Last name | Levies owing |
|---|---|---|
Import Brightside Strata off PropertyIQ into our schema. Reading your uploaded files Extracting tables from your file Profiling your source data Checking the target templates Owner names arrive as one `SURNAME, Given` column but the Owners template splits first and last. Lot references are zero-padded in one file and not the other. Searching the web about this source Saving what we learned about this source Drafting the import Testing the recipe on your data Reviewing the preview output Asking you a question Map `settled` → Paid `settled` now maps to **Paid**. I’ve saved that against PropertyIQ so every future migration off this source gets it right without asking. Importing your data Checking which fields came across **Unmapped or unavailable data:** nothing — everything mapped cleanly.
A real migration, replayed in the product’s own interface. The question the agent asks is live — pick an answer and watch the import change.
Onboarding teams at startups and publicly listed companies run their customer migrations on Vern
The problem
Customer data migrations stall in the messy middle
Getting the export is easy. Getting it correct — every record accounted for, every edge case decided by someone who actually knows the answer — is where onboarding timelines go to die.
01
The back-and-forth never ends
Every ambiguous field becomes an email. Your implementation manager waits days for an answer that turns out to be one sentence long, and the customer waits with them.
02
The data is worse than the demo suggested
Missing fields, three spellings of the same company, relationships that only exist implicitly in a filename. None of it appears until you try to load it.
03
Engineering becomes the bottleneck
Every new source system is a multi-week ticket. The backlog of "just add support for X" grows faster than anyone can drain it, and the migration tool starts gating product velocity.
How it works
Four surfaces, one job: your customer's data, correct, in your product
Vern is not a mapping wizard with an AI button bolted on. It is an agent that does the migration, and four places for you to check its work.
Step one
Connect the source, or let the customer upload it
Connect a source system once and reuse it for every customer on it. Or take whatever they can actually produce — Excel, CSV, a SQL dump, a zip of 312 PDFs — and send them a link so they upload it themselves.
- 502 source systems in the catalogue
- Credentials go to a vault, never into the agent transcript
- No connector? The agent reads the API docs and writes one
- 100msCommunication
- 7shiftsHR & Payroll
- ActiveCampaignMarketing
- Acuity SchedulingProductivity
- Adobe Commerce (Magento)E-commerce
- AgileCRMCRM
- AhaProject Management
Step two
The agent writes a plan you can actually read
It profiles the source, checks it against your templates, researches the source system on the web when the blocker is knowledge rather than data — then drafts a plain-English plan, tests it on a sample, and shows you the rows it would produce.
- Every plan states what did not come across, and why
- It asks rather than guesses — one pause, every open question batched
- The plan is a reusable recipe, not a one-off script
Owners — 1,204 rows
Split SURNAME, Given into first and last name. Trim the zero-padding off lot references so they match lots.csv. Levies come across as decimals, not the source’s cent integers.
Lots — 486 rows
One row per lot. Building and plan number are carried from the sheet header rather than repeated per row in the source.
Invoices — 38,918 rows
Unzipped from invoices_2019-2024.zip and joined to lots on lot reference. Status normalised to your enum.
Unmapped or unavailable data
Nothing — everything mapped cleanly. Every plan ends with this section, and it only says “nothing” when it’s true.
Step three
Nothing is written until you approve the diff
Ask for changes in the workbook the same way — "dedupe these owners", "split this column", "why is this lot missing?" — and the agent answers with a row-level diff. The approval card is the gate; it never writes directly.
- Cell-level validation with plain-English reasons
- Full version history: who changed what, before and after
- Trace any imported value back to the cell it came from
Normalise phone numbers to E.164 and fix the two company-name variants
3 columns · 40,196 cells affected
- Phone1,182 rows(02) 9 555 0114+61 2 9555 0114
- Company96 rowsBrightside Strata Pty. LtdBrightside Strata Pty Ltd
- Settled on38,918 rows31/07/242024-07-31
Step four
Land it in your product
Export a CSV, push a webhook shaped the way your API expects, or let a writer agent map every template onto your endpoints and confirm the records actually landed.
- Flat or relationship-nested payloads
- Writers verify each write by reading the record back
- Reuse the same writer for every customer on that destination
Flat by table, or nested by relationship
Nested mode reads the link rules on your templates and embeds each child inside its parent, so you receive whole records instead of tables to re-join.
{
"lot": "12B",
"owner": {
"first_name": "Tomás",
"last_name": "Ferreira",
"email": "t.ferreira@brightside.example"
},
"invoices": [
{
"number": "INV-20412",
"amount": 780.00,
"status": "Paid"
},
{
"number": "INV-20489",
"amount": 780.00,
"status": "Overdue"
}
]
}It compounds
Migration #50 takes a fraction of the time migration #1 did
Most migration tooling solves each customer in isolation, and the knowledge ends up in an implementation manager's head or in a script that drifts. Vern writes what it learns down, at two levels, and reads it before every run.
What Vern knows about this source
- How this software structures its exports — field formats, enums, ID and date patterns.
- These rules apply to every customer you migrate off this source, so you teach them once.
- Vern applies them automatically, so each new import starts from what you already know.
PropertyIQ writes settled for invoices closed before 2022 — map to Paid.
Teach Vern about this customer
- Capture data quirks and knowledge specific to this customer — reused on every import.
- Record decisions you made together (what to include, skip, or rename) so they’re not repeated.
- Vern writes here too, building memory as it learns from each migration.
Brightside’s lot 13 doesn’t exist. Blank levies mean nil, not unknown.
Extractor library
502 source systems — and the agent writes the ones we don't have
Connect a source once, and every customer you onboard off it reuses the same connection, the same recipe and everything Vern already learned. When a customer arrives on something obscure, the agent reads that vendor's API docs and authors the connector itself.
Migration API
Or run the whole thing from inside your own onboarding flow
Everything the app does is available over an API keyed to your organisation. Create a migration, upload the files, let the agent build a plan, approve it, stream the thread into your own UI, and pull the result out — without your customer ever seeing Vern.
API=https://app.vern.so/api/v1
KEY="x-api-key: $VERN_API_KEY"
JSON="Content-Type: application/json"
# 1 — create the migration
ID=$(curl -sX POST $API/migrations \
-H "$KEY" -H "$JSON" \
-d '{"name":"Brightside","source":"PropertyIQ"}' \
| jq -r .migration.id)
# 2 — the agent drafts a plan, stopping at a preview
curl -X POST $API/migrations/$ID/runs \
-H "$KEY" -H "$JSON" -d '{"kind":"generate"}'
# 3 — see exactly what it would produce
curl $API/migrations/$ID/preview -H "$KEY"
# 4 — approve, and write the rows
curl -X POST $API/migrations/$ID/runs \
-H "$KEY" -H "$JSON" -d '{"kind":"execute"}'Trust
Built for the security review, not just the demo
You are handing us your customers' data. Everything below is a product feature you can inspect, not a promise in a slide.
ISO 27001 certified
An information security program certified to ISO 27001, with enterprise-grade encryption and access controls. GDPR compliance is in progress; we handle personal information under the Australian Privacy Act and its Privacy Principles.
Every decision is on the record
Each clarification, mapping choice and automated fix is logged with a before and after, attributed to a person or the agent. Version history in the workbook goes back to the original upload.
Data residency you choose
Tenants are pinned to a region — United States or Australia — and every database, cache, and compute call for that tenant is scoped to it. Nothing crosses regions.
Retention you set
Workbooks auto-delete on your schedule — 7, 30, 90, 180 or 365 days, or never — with a preview of exactly what each setting would remove before you commit to it.
We do not use your Customer Data to train foundation models or any general-purpose AI models.
10M+
Records supported per migration
100M
Records imported since inception
100%
Customer clarifications actioned
Pricing
Pricing that scales with migration volume
Usage is metered in credits — how many a migration consumes depends on the volume of data and the extraction method. No per-user fees.
Partnerships
CustomFor companies that don’t treat migrations as core business and hand them to us end to end.
- Fully managed migrations
- White-label delivery
- A dedicated migration team
- Per-project pricing
- Priority turnaround SLAs
Need more? Add pay-as-you-go volume at any time, or talk to us about a committed onboarding program.
FAQs
The questions that come up on every call
Ready to migrate your next customer?
See Vern turn a real export — whatever shape it arrives in — into validated, customer-approved records in your product.