Private beta · email for a demoNo VFP runtime · reads the binaries

The map of your Visual FoxPro codebase.

Point Carta at a VFP 9 project and in minutes you have the screens, the data model, the call graph, and the answer to "what breaks if I change this?" — whether you're maintaining the app or scoping a move off FoxPro. It reads the binary .scx / .vcx / .frx / .dbc ordinary tools can't open, with no VFP runtime needed. Get your bearings in hours, not the weeks it takes by hand.

Email us for a demo See it in action

runs entirely local · offline license keys · no cloud, no telemetry

Built by Pivoten — a team that keeps 30-year Visual FoxPro systems running in production. This is the tooling we built for our own work.

Reads .scx forms .vcx classes .frx reports .mnx menus .dbc / .dbf data .prg source no runtime · local only

The Carta dashboard the moment a project opens: a readiness strip, then the Understanding funnel (Discovered → Read → Parsed → Resolved, 60% resolved of 237 units) and the runtime-resolution cards — the whole app's comprehension at a glance

That 60% is static call resolution, not "60% done." Carta reads and parses 100% of the code; 60% of calls pin to a definite target without running anything. The other 40% is VFP's own dynamic dispatch — macros, EVAL, runtime‑decided calls — and Carta doesn't guess at it: it itemizes every one of those sites, what each depends on, and what would prove it — a runtime contract you could hand to a test harness, not a blind spot. No VFP runtime needed to know exactly where the runtime matters.

01 · See

See the screens

Open any form, report, or menu straight from the binaries — and walk the app like a user. No VFP.

02 · Follow

Follow the data

Every table, the schema and relationships, and a query you run over your own rows.

03 · Judge

Judge the risk

Complexity hotspots, data-correctness hazards, and where to be careful — whether you're changing the app or moving off it. Plus a convertibility verdict and quick wins.

04 · Dig

Dig into the code

Search everything (binaries included), trace calls hop by hop, and answer "what breaks?"

Product tour

See it work on a real codebase.

A quick tour on the fictional Meridian Trading Co. demo project — captured straight from the cockpit, nothing staged. Below it, the whole app in the order you'd actually use it: land on the dashboard, read the screens, follow the data, judge quality, then dig into the code.

01 · Navigate

A language server for a language that never had one.

Hover GetNextID: signature, defining file:line, its own doc comment, and a ◂ 6 callers inline count — with an outline and go-to-definition.

Editor at GetNextID with a 6 callers CodeLens above the function and a Call Hierarchy panel listing all six callers across four files, plus its one call and seven references

02 · Understand

Follow a screen to its data.

frmOrderEntry (a complex, high-traffic form) → a live data-flow diagram to its 6 tables, with per-method behavior. Click any table to see every screen that touches it.

frmOrderEntry data-flow diagram to its six tables — customers, orderlines, orders, products, stock, warehouses — drawn from the form's data environment and code

03 · Impact

"What breaks if I change this?"

Impact on orders: 5 screens, 162 code references (7 writes / 33 classified reads) across 18 files, 5 FK-related tables — one query.

Impact analysis of the orders table: 5 screens, 162 code references (7 writes / 33 reads) across 18 files, and 5 FK-related tables

Start

Land and get your bearings

Point Carta at a project — even a locked .pjx — and it maps itself. The dashboard briefs you the moment it opens.

The Dashboard briefing: a charts strip (SQL lanes, migration hazards, parse confidence), project stats, entry points, load-bearing code, busiest routines and tables — the whole app at a glance, with a narrated-tour offer — **Dashboard** the whole app at a glance the moment it opens: a **charts strip** (SQL lanes, migration hazards, parse confidence), entry points, load-bearing code, busiest routines and tables — plus a **narrated tour** whose every sentence is drawn from this app's real numbers.

UI · Designer

One designer for every screen — form, report, menu

The same three-pane Designer — an object tree, a faithful render straight from the binary, and a full property sheet — switches across the app's forms, reports, and menus. One click opens any of them in the real VFP IDE.

The Designer: a three-pane view of the Order Entry form — an object tree of every control on the left, the form rendered faithfully from the .scx binary in the center, and a full property sheet on the right showing the selected combobox's real ControlSource, RowSource, geometry, and font. Run and Open-in-VFP sit in the toolbar. — **UI Designer** the whole screen in one place: an **object tree** of every control, the form **rendered faithfully from the binary**, and a **full property sheet** with the real `ControlSource`, `RowSource`, geometry and fonts. Carta is a **sidecar to VFP** — one click **opens the same form in the real IDE** when you want to edit it.

Menu view read from the .mnx: an interactive VFP-style menu bar with a drop-down and a Stock cascade, above an item-by-item tree showing what every choice runs — DO FORM launches, REPORT FORM reports, an inline procedure, and a SKIP FOR guard — **Menu** the app's launch surface, read straight from the `.mnx`: a live, clickable menu bar over an **item-by-item map of what every choice runs** — which screen it opens, which report it prints, the inline code it executes, and when it's disabled.

carta · report designer

Report designer the same three-pane Designer, now on a report: an object tree of every band and field, a pixel-exact wireframe of the .frx, and its complexity profile, callers, cursor fields and data environment — then one click opens it in the real report designer in VFP.

UI · Flow

See how the screens connect

Your app's screens arranged by how users actually reach them — walk it screen to screen like a user would.

Compass Storyboard: the application screens arranged by how users reach them from the menu, with navigation paths drawn between real form layouts — **Storyboard** your app's screens, **arranged by how users actually reach them** — every card the real form drawn from its binary, every line a navigation path. Walk it screen to screen like a user would.

Data

Follow the data

The tables, how they relate, and a query you run straight over your own rows.

Entity-relationship diagram parsed from the .dbc, centered, with green foreign-key relationship lines joining every table — **Database schema** every table, column, and FK relation, straight from the `.dbc` — the relationships drawn as lines so the whole data model reads at a glance.

Data-model graph: base tables as boxes with parent-to-child relation arrows, each edge tagged by where it was found — declared in the DBC, recovered from code SET RELATION, or a form's DataEnvironment — **Data model** **how the tables actually connect**, in one graph: the relations declared in the `.dbc`, plus the ones recovered from **code** (`SET RELATION`) and a form's **DataEnvironment** — every edge tagged by where it was found, and a macro-computed link left out rather than **guessed**.

Data browser showing live orders.DBF rows with FK-linked key columns — **Browse tables** live rows straight from the `.dbf`, with **key columns linked** so you can follow a record across the database — no FoxPro. Open any table in VFP in one click.

Query builder: a base table with its columns, foreign-key badges to follow into related tables, a generated SELECT, and the result rows returned from the data — **Queries** build a query by **following the foreign keys** between your tables, then **run it straight over your data** and see the rows — no FoxPro needed.

Quality

Judge quality & convertibility

What's risky, what's easy to clean up first, and how portable the whole thing is.

Convertibility scorecard: preliminary effort bands (SQL-backend vs full rewrite, in hours), complexity and health, a UI control census, and the SQL-lanes parse-rate bar (green/yellow/red) — **Convertibility** the portability verdict: **SQL "lanes"** (green/yellow/red parseability), effort bands with their inputs shown, complexity & health, a control census, and the data-model shape — every number measured from a static scan.

Migration hazards grouped by kind — macro substitution, row buffering, global event traps — each at a file and line, with every & macro resolved to what it expands to: a proven literal, a closed candidate set, a caller-supplied parameter, or an honest dynamic — **Migration hazards** the constructs a transpiler **can't mechanically convert** (macro `&` substitution, row buffering, global event traps), each at a file and line. And Carta doesn't just flag a macro — it **resolves what the `&` expands to** where it can prove it: a literal in scope → "duedate", a closed set → one of …, even a **parameter read from every call site** · via callers — and stays honestly **dynamic** when it can't.

Quick Wins: a ranked list joining dead code, duplicates, unused and missing reports, and lint in hazard files — each with a file:line, an effort badge, a measured saving, and an evidence link — **Quick Wins** one ranked list that **joins dead code, duplicates, report cleanup, and lint in hazard files**. Every row is a lead with a `file:line`, an effort badge, a measured saving, and an **evidence** link that proves it — **the low-hanging fruit, already picked out.**

The guided assessment: a plotted waypoint trail — take the snapshot (28 files, 10 tables), read the convertibility verdict (85% SQL parse), survey the risk surface (11 hazards), check the SQL lanes (20 SELECTs, green/yellow/red) — each waypoint carrying its live number and a link into the page that does the work — **Guided assessment** a plotted route through an unfamiliar app for **either job** — audit it for a client, or scope a move off FoxPro. Every waypoint carries **its live number** (snapshot, convertibility verdict, hazards, SQL lanes, quick wins) and links into the page that does the work. Collect findings as you go and **leave with a Markdown deliverable**.

Code & Logic

Dig into the code

Search everything — including inside the binaries — trace calls hop by hop, and read the class model.

Project-wide search for 'custid' returning 65 hits in code, grouped by Program / Screen / Class Lib / Report / Menu, with matches highlighted — including inside the binary frmorderentry.scx (a method body and a control's ControlSource) — **Search — the Go Fish replacement** text or regex across **every file at once**, and — the part grep can't do — **inside the binary `.scx/.vcx/.frx/.mnx`** too. Ranked so **exact identifier matches lead** and the looser hits follow. Here `custid` turns up in a form's method body and a control's `ControlSource`; double-click any hit to open it in VFP.

A focused call-graph view of one routine, GenerateInvoice — its 2 callers and 4 callees one hop out (ShipOrder → GenerateInvoice → GetNextID, NextBusinessDay, LogEvent), with recovered macro/global-dispatch edges drawn dashed — **Hop-by-hop calls** **focus any routine** and see just its neighborhood — who calls it and what it calls, one hop out — instead of a whole-project hairball. Here `GenerateInvoice` with its 2 callers and 4 callees; even **macro / late-bound dispatch** is recovered and drawn dashed.

Class view showing an inheritance chain, what instantiates the class, and its methods — **Class inheritance** the full inheritance chain for any class, **who creates it**, and every method with its exact location — the object model ordinary tools can't read out of a `.vcx`.

A System Context diagram of the Meridian app: the User, the meridian application, its Database (10 tables, 11 relations), and the external systems it touches — Printer/reporting and External files — with an evidence panel on the right listing the real call sites (REPORT FORM in meridian.mnx, STRTOFILE in apputils.prg) — **Architecture overview** the altitude view: a **System Context** of the whole app and **every system it touches** — its database, its printer/reporting, the files it reads and writes — each one **evidence-backed** with a real call site, never a guess. A second tab maps the app's **subsystems** and the calls between them.

…and more

Everything above is one app. A few of the other views it ships with:

App Walk click through the running app screen by screen — every navigation path, driven from the binaries, no VFP.

Recovered calls dynamic macro dispatch tracked down to the routine it actually calls — so the call graph stays complete — drawn dashed, "via macro."

Architecture vs. reality the structure you expect vs. the real dependency structure, side by side — where the code drifted from the design.

Report lineage every report's printed columns traced back to the base tables they come from.

Hotspots complexity ranked per routine, so you know what to touch carefully.

Duplicates copy-pasted code found across programs, clone group by clone group.

Lint hard-coded paths and leftover TODOs, caught before they bite.

Why Carta

Nobody else reads FoxPro this way.

VFP has had no modern tooling since 2007 — and half of every FoxPro app is locked inside binary DBF artifacts. Carta was built for exactly that.

Answers the maintenance question

"What breaks if I change this?" Table → screens, classified read/write references, FK ripple. Symbol → transitive-caller blast radius. The question every legacy dev asks daily, answered in one query.

Static by design

Everything Carta knows comes from the project's artifacts alone — the whole analysis needs no running VFP. It works on any machine, and on projects VFP itself can't currently open (a locked .pjx included). When you want to edit or run something, Open in VFP bridges into your own licensed VFP — the one place anything live happens, and only when you ask.

Reads the binaries

.scx / .vcx / .frx / .dbc are DBF containers; Carta parses them directly. That means form previews without opening VFP and method-level search inside binary forms — not just your .prg files.

No runtime, no install footprint

No cloud, no agent, no telemetry — and no VFP runtime of its own (the optional bridge drives the VFP you already have). Carta reads your project right on your machine — your source never leaves the building, which is exactly how confidential legacy code should be treated.

Dynamic VFP, head-on. Macros (&lcField), DO (lcProg), data-driven menus — where static tools give up. Carta resolves the dynamic calls it can prove (drawn dashed, "via macro") and flags the rest honestly, so you see the moving parts instead of a blank.

No VFP required — but it plugs in if you have it. Carta understands your app with no VFP installed. Have a licensed VFP 9? Carta integrates with it: open any form, report, or menu in the real VFP IDE with one click — and automate the IDE and your standalone VFP .exe apps, so an AI can drive them, exercise the real business logic, and write your tests.

By the numbers

Measured, not promised.

Every figure below renders in the screenshots above — captured from the Meridian demo project, never customer code.

~5 s

to map Meridian: 28 files, 10 tables, 9 binary forms, ~2,400 data rows.

~2–3 min

first full map of a 2,600-item production app — instant refreshes after that.

65 hits

for custid — including matches inside binary .scx forms.

162 refs

impact on orders: 5 screens, 7 writes / 33 classified reads across 18 files, 5 FK-related tables — one query.

24 controls

frmOrderEntry — grid, combos, bound totals — rendered straight from the .scx binary. No VFP needed to draw it.

52 max

the hottest routine (CalcExtendedPrice) — cyclomatic complexity ranked per routine, so you know what to change carefully.

Independently verified

How do you know the read is correct?

Carta reads the binaries directly — so we cross‑check that read against FoxBin2Prg, the FoxPro community's own converter, running in real Visual FoxPro. On the structural facts we diff — class and form parents, members, control classes, field expressions, menu items, database schema — the two agree on every comparable item, on public projects and real apps.

5 types

every VFP binary cross‑checked: classes, forms, reports, menus, databases (.vcx .scx .frx .mnx .dbc).

seconds

reads & decodes a whole app's binaries in seconds — no VFP install, so it runs in CI or on a locked project.

public

reproducible on code you can download — the check runs on open‑source FoxPro projects, not just ours.

We even checked the computed call graph against a real app's actual startup: of the 822 calls it made, 69% were predicted statically — the rest are VFP's own dynamic dispatch no static tool can see — and not one went to a routine Carta didn't know. The product never runs your app; the runtime was only a yardstick.

Carta + your AI

Chat with your codebase. Then let AI drive it.

Connect an AI assistant to Carta over the MCP server and chat with your codebase — grounded answers about your own app. Then, if you want, take it a step further: let the server drive the VFP IDE and your standalone VFP apps to navigate, explore, and understand the system in motion — and write your tests for you.

Chat with your codebase

Connect an AI assistant over the MCP server — Claude, or any MCP-capable agent — and ask your app anything: where a symbol lives, what touches a table, how a screen works. Answered from the real project, with the evidence — not a guess.

Let AI drive VFP, not just read it

Take it a step further: the MCP server can drive the real VFP IDE and your standalone VFP apps — navigating, exploring, and exercising the system in motion — so the AI learns the business logic the way a user would and writes down what it finds.

Let it write your tests

Point the AI at a workflow and it writes the unit and end-to-end tests for you, grounded in what it just exercised in the live app — regression coverage for a 30-year codebase that never had any.

In control, on your machine

You decide what the AI may touch — read-only by default, actions opt-in. It all runs locally against the VFP you already have, and your source and data never leave the building.

Assessment

Scope it before you touch it.

You can't plan what you can't see. Carta turns a 30-year black box into a scoped, shareable assessment — what's there, what's hard, and where to start — whether you're auditing the app to maintain it or scoping a move off FoxPro. It comes from a static read, so you get a confident plan before anything changes.

What Carta is — and isn't. Carta maps and scopes: it reads the app, measures convertibility, and pins the hazards at file:line. It does not auto-convert your code. You leave with a shareable assessment — SQL lanes, effort bands, hazards, quick wins, exportable to Markdown — to plan the move with your own team, on your timeline. Understanding is the deliverable; the rewrite stays yours (with your AI, if you like).

Convertibility scorecard

A portability verdict over the whole app: size, complexity, health, and the SQL "lanes" — how much of your queries translate cleanly (green), need work (yellow), or fight you (red) — with effort bands you can put in a plan.

Quick wins, ranked

One triage list that joins dead code, duplicates, unused & missing reports, and lint in hazard files — each with a file:line, an effort badge, and a measured saving. The low-hanging fruit, already picked out.

A guided assessment you can hand off

A step-by-step expedition through the app that collects findings as you go — with your own notes — then exports to Markdown you can drop into a proposal or a stakeholder review. The map outlives the one dev who knew the system.

The FoxPro landmines, flagged

Migration hazards generic tools never see: macro-expansion &, runtime EVAL, SCATTER/GATHER, buffering and SET-state traps — and reports that saved a printer environment, the classic deployment landmine. Each located, effort-weighted, and honest about what it can't prove.

Get Carta

Carta is in private beta.

It's early days. Email us and we'll set up a demo.

Everything Carta does

The full map, plus the bridge into a real, licensed VFP 9 IDE on your machine.

Search everything — full-text + regex across source and binaries
Go-to-definition, find-references, hover docs, call hierarchy, outline
Call graph, schema/ERD, complexity hotspots, dead-code view
Duplicate-code detection and lint — clones, hard-coded paths, leftover markers
Impact analysis — tables and symbols
Static form previews from the .scx
Convertibility scorecard — size, complexity, SQL lanes, effort bands
Quick Wins triage + a guided assessment with Markdown-exportable findings
Migration hazards — the FoxPro traps and printer-environment landmines, located
Narrated tour & dashboard briefing — the app explains itself on first open
Architecture vs. reality — your intended architecture vs. the real dependencies
Signed, self-updating standalone app — double-click to run, no install, no editor required
Open in VFP — any form, class, report, menu, or table jumps into its native designer
Save & Recompile — edit a method in Carta, write it back into the binary form (guarded, backed up), recompile in VFP
Live Console — a FoxPro REPL against a warm VFP session, plus compile-check and build APP/EXE
Priority support from the team that builds it

Email us for a demo sales@pivoten.com · we read every message

FAQ

Fair questions, straight answers.

We're not migrating — we just need to understand and maintain the app. Does Carta help?

Yes — that's the primary use case. Carta gets a developer productive in an unfamiliar VFP app fast: search everything (binaries included), go-to-definition, the call graph, the ERD, form/report/menu previews, and "what breaks if I change this?" impact analysis. No migration required — just faster, safer day-to-day work on the app you already run.

How does licensing work? Do I need to be online?

No. Carta uses offline, signed license keys — a self-contained statement of who bought what. There's no activation server and no phone-home. Your key covers every build released while it's current; when it lapses, those builds keep working forever — only newer builds ask you to renew.

Does any of my code leave my machine?

Never. Carta runs entirely on your machine — no cloud, no telemetry, nothing to sign in to. It reads and analyzes by default; anything that changes your project — an edit you save, or an action you let an AI take — is explicit, local, and backed up.

We're migrating away from VFP. Why would we buy tooling for it?

That's exactly when you need the map most — and Carta is built for it. Scoping a move means knowing what's actually there: the ERD, the dead code, the dependency tangles, the complexity hotspots. Carta adds a convertibility scorecard (with SQL "lanes" and effort bands), a quick-wins triage, and a guided assessment you can export to Markdown for a proposal or stakeholder review. It turns "we can't estimate what we can't see" into hours of work — and the map outlives the one developer who knew the system. Note: Carta scopes and assesses the move — it doesn't auto-convert your app. It makes the move estimable and hands you the map; the rewrite is yours (with your AI, if you like).

How is Carta delivered?

A signed, self-updating standalone app you double-click — no install, no editor required. Add the optional MCP server to let an AI assistant drive the VFP IDE and a live VFP app alongside it.

What platforms does it run on?

Windows x64 and Windows arm64, as a signed standalone app. The optional MCP server drives a real VFP 9 IDE and a standalone VFP app — both Windows — so that's where Carta ships.

Do we have to leave FoxPro to use it?

No — Carta meets VFP developers where they live. Every view has Open in VFP: forms open in the Form Designer, classes in the Class Browser, tables in a Browse window. The real IDE stays for what it's uniquely good at; Carta adds everything it never had.