Your old Altium .PcbDoc imports as an empty board — with no error.
Some older Altium boards are stored in a legacy ASCII or pre-V6 format. A standard Altium → KiCad migration can read one of these files and produce nothing at all — no board, no components, no warning — because the import silently does nothing (documented in KiCad's tracker). It's the most dangerous failure of all, because it looks exactly like success. Crosspad reads the file itself: the ASCII text form it converts and then checks against an independent count of your board, and the pre-V6 binary it names as unsupported with a reason — never an empty board reported as a success.
Free analysis on one Altium .PcbDoc — one board file, not a project. Files are processed as described in our Security policy.
Why does an old Altium board import as nothing?
The Altium .PcbDoc format has changed across eras. Older files were written as ASCII text or in a pre-V6 binary layout; current Altium writes a modern compound-binary file. A standard Altium → KiCad migration expects that modern layout. Handed a legacy ASCII or pre-V6 file, it finds nothing it recognizes to read — and instead of stopping with an error, it finishes and hands back an empty board. This is documented in KiCad's own public tracker: importing an ASCII Altium .pcbdoc throws no error and nothing happens.
Reported against KiCad 8.0.4. Still open as of KiCad 10.0.6 (2026-08-29). This is a tracked, still-open gap — not a claim that every legacy file fails identically on every version, and not something a newer KiCad has quietly fixed.
No error is not the same as no problem.
The most dangerous failure is the one that looks like success.
You point the migration at an old .PcbDoc. It runs. There's no red error, no warning dialog, no log line saying the file wasn't understood. KiCad opens — to a blank canvas. It's easy to assume the board was mostly empty, or that something is off with your view, and move on. The loss is silent: a file that clearly had a design in it comes across as nothing, and the tool that produced the nothing reported no problem. You may not notice until you go looking for a component, a net, or the board outline that isn't there.
No components, no tracks, no board outline — an empty .kicad_pcb.
No error and no warning — the import “succeeded.”
The original opens fine in Altium, so the design is intact — it just didn't come across.
A migration that produces nothing and says nothing is worse than one that fails loudly. At least a loud failure tells you to stop.
One of these two we migrate. The other we name.
“Legacy” covers two different files, and they no longer end the same way. The ASCII text form Crosspad migrates: it parses the text, writes a real binary .PcbDoc from it, and then counts the converted board independently and compares that count with your source — a conversion nobody checked is a guess, and a guess is what this page exists to argue against. Where the two counts disagree, the board is named unsupported instead of migrated. The pre-V6 (Protel) binary is the one Crosspad still cannot read, and it says so with a named reason and a remedy. What never happens, in either case, is the silent no-op: an empty board handed back as a success.
- 01DETECT
Read the first bytes of your file and tell the two legacy eras apart — the ASCII text form and the pre-V6 binary no longer end the same way.
- 02CONVERT
For the ASCII text form: parse it and write a real binary .PcbDoc, which then goes through exactly the same migration and validation as a board Altium wrote that way.
- 03RECONCILE
Count the converted board independently and compare it with your source. Agreement is what earns the migration; disagreement makes it unsupported, not a silent green.
- 04NAME
For a pre-V6 (Protel) binary, which Crosspad cannot read: mark it UNSUPPORTED with a named reason — ALTIUM_LEGACY_BINARY_PRE_V6 — and point at the one reliable remedy, re-saving it from a current Altium Designer.
A conversion nobody checked is a guess. Crosspad checks its own, against your board — and if the two disagree it stops rather than hands you the guess.
The pre-V6 path is still the honest gap. Re-saving from a modern Altium is the dependable way back, and if you no longer have Altium access for such a file, tell us about the project — recovering pre-V6 boards is exactly the kind of edge we want to hear about, and we'll be straight with you about what's possible.
Frequently asked questions.
Why did my Altium .PcbDoc import as an empty board in KiCad?
The most common cause is that the file is a legacy ASCII or pre-V6 Altium format. A standard migration expects the modern binary .PcbDoc, so it reads the older file, produces nothing, and — this is the dangerous part — throws no error (documented in KiCad's tracker, #18467, reported against 8.0.4 and still open as of 10.0.6). The design isn't gone; it just didn't come across, and nothing told you. Crosspad reads the file itself: if it is the ASCII text form, it converts it and checks the conversion against an independent count of your board; if it is a pre-V6 binary, it names that as unsupported with a reason. Either way you are told, instead of handed a blank board.
Can Crosspad migrate a legacy ASCII or pre-V6 Altium board?
The ASCII text form, yes. Crosspad parses it, writes a real binary .PcbDoc from it, and then counts the converted board independently and compares that with your source — where the two disagree it reports the board unsupported rather than migrate a conversion it cannot vouch for. A pre-V6 (Protel) binary, no, and we won't pretend otherwise: it is named unsupported (ALTIUM_LEGACY_BINARY_PRE_V6) with the reason, and the reliable remedy is to open it in a current Altium Designer and re-save it. Naming a gap honestly is the point: you find out before you've built on top of nothing.
Find out whether your board is a legacy format — before you trust an empty import.
Point Crosspad at your board. If it's the ASCII text form you get a migration whose conversion has been checked against your own file; if it's a pre-V6 binary you get a named, explained finding — never a blank board and a shrug.
Free analysis on one Altium .PcbDoc — one board file, not a project. Files are processed as described in our Security policy.
Last updated 2026-08-31. Anchored to KiCad 10.0.6 (2026-08-29). KiCad #18467 was reported against 8.0.4 and is still open as of 10.0.6; this page is refreshed on each KiCad point release that changes Altium import. Source: KiCad's public issue tracker.