Beyond the migration headline
Migration is the last step. Most of what it does happens before that.
The pitch usually lands on "it migrates VB6" because that's the hardest problem to solve and the biggest payoff. But the graph, the dead-code detector, and the agent tool server are useful on day one, on a codebase you have no plans to migrate at all — you can point UnspoolCode at a VB6 project purely to understand it.
01Understand it
A dependency graph you can query, not just view
Every module, form, and call, resolved
The parser reads your VB6 source and builds modules/functions-as-nodes, calls/reads/writes-as-edges — no manual mapping, no diagramming tool to keep in sync by hand.
A 3-panel IDE to walk it
Click a module in the graph view and jump straight to it in an integrated editor. Built for the "what does this even do" pass before you touch a line.
Impact analysis before you change anything
Ask "what breaks if I change this procedure?" and get every transitive caller back — sorted by depth, deduplicated, cycle-safe — instead of grepping and hoping you caught every call site.
Dead-code detection
Procedures unreachable from any entry point get flagged automatically — the analysis that used to take an engineer a week of careful grepping runs as a query, even on a multi-million-edge graph.
02Hand it to an agent
A 37-tool MCP server, not raw file access
Point a coding agent at a legacy VB6 tree with no tooling and it starts grepping and guessing at call graphs from raw source — burning context on files it doesn't need and hallucinating dependencies it can't see. UnspoolCode gives it purpose-built tools instead: read tools to explore the graph, plan and batch tools to run a migration, a translation review queue, and write tools for graph edits — all gated behind dry-run previews and hash checks against stale reads. See thefull list of all 37 tools, grouped by what they do.
03Migrate it, when you're ready
Batch execution, not just a plan document
When you do decide to move off VB6, UnspoolCode doesn't stop at a migration plan — it drafts one in dependency order, runs translation batches with a scheduler that resumes cleanly after a restart, and routes every low-confidence translation through a review queue before it can ship. Destructive graph edits — dead-code removal, in-place replace, scope-advice fixes — sit behind an explicit preview-then-confirm step; direct source writes are hash-checked against the last-read version to catch anything stale. Seesupported languages & targets for what TypeScript and C# migration each specifically include.
04Measured, not marketed
Every number above is a real, reproducible run
41K+ nodes and 610K+ edges on a real production VB6 codebase, byte-identical across successive engineering milestones. A synthetic stress corpus at 2M lines (4,070 files, 419,580 nodes, 7.7M edges) holds peak memory under 8GB and starts the service in 404ms. Query latency, memory, and dead-code timing are all recorded from the same runs — see the homepage's measured scalesection for the methodology.
Early access
Be first to run it on your codebase.
UnspoolCode is real, working software, currently pre-GA. Join the waitlist and we'll reach out when early access opens — no commitment, no spam.