Known Altium → KiCad import issues — verified and tracked.
A curated index of the ways a standard Altium → KiCad migration silently goes wrong — each one documented in KiCad's own public issue tracker, scoped to the versions it affects, and mapped to what Crosspad detects, repairs or flags. Not a wall of bug reports: the verified families that actually cost you a spin.
Free analysis on one Altium .PcbDoc — one board file, not a project. Files are processed as described in our Security policy.
Every family here is a documented, reproducible failure — not an opinion.
Each entry names a way a standard Altium → KiCad migration can silently change or drop design data — the board opens, and you find out later, or not at all. Every one is grounded in KiCad's own docs and public issue tracker, cited as proof the failure is real, and scoped to the versions it affects. Several are version-specific and get fixed release to release — where a fix has shipped, we say so and give the version. This index is anchored to KiCad 10.0.6 and refreshed each release. It is curated, not exhaustive: these are the verified families that matter, with per-family breakdowns added as we confirm each.
- DETECTED
Crosspad checks this against your source, independently, and reports it.
- AUTO-REPAIR
Crosspad detects it and, where it can prove the fix safe, repairs it, then re-validates; an unsafe repair is rolled back and flagged.
- REPAIR / DECISION
Crosspad repairs what it can prove, and surfaces the unprovable part as an engineering decision instead of quietly reducing it.
- RECONSTRUCT
Crosspad rebuilds the structure from your source and confirms it still means the same thing; what it can't rebuild is flagged.
- FLAGGED
Crosspad names it as an action to take, never passes it as complete.
- NAMED UNSUPPORTED
Crosspad states the format/element cannot come across, as an explicit named gap rather than a silent no-op.
Each issue id links to the public KiCad tracker entry that documents it. A family that lives in your board file carries a free check on your own .PcbDoc — the families here are general, your board is specific. A family that only exists in a schematic is marked as not checked at launch and points at how it will be reported instead. Per-family breakdowns (versions, fixtures, detect/repair detail) are coming as we verify each.
Fourteen verified ways a standard migration silently goes wrong.
Ranked by how often they cost a real board, not alphabetically. Each is documented in KiCad's public tracker; each maps to what Crosspad does against your source. For the per-issue detail — affected versions, fixtures, the exact detect/repair — the family breakdown is coming as we verify it.
- 1AUTO-REPAIR
Multi-channel / repeated designators
open · seen in 10.0.0 / 10.99A standard migration can strip the channel suffix that keeps repeated parts apart (C33A / C33B → C33), collapsing distinct components into duplicate references that quietly break the BOM and the netlist.
Crosspad detects colliding and stripped designators and, where the original channel mapping is recoverable, repairs them back to unique references — then re-validates. Anything it can't prove is flagged, never silently renumbered.
- 2AUTO-REPAIR
Copper fills & zones
openSoldermask relief on fills can be lost and zone clearances can arrive wrong, so a routine zone refill silently disconnects copper — invisible until fabrication.
Crosspad compares fills and zones against the source geometry, auto-repairs what it can prove equivalent, and flags any pour it can't — so a disconnected copper region is a finding, not a surprise at the fab.
- 3AUTO-REPAIR
Legacy ASCII PcbDoc
openAn ASCII-format PcbDoc can import as nothing at all — no board, no error, no warning — the most dangerous failure because it looks like success.
Crosspad converts the ASCII text form to the binary form and reconciles the conversion against an independent count of your board before trusting it — and where the two disagree it names the board unsupported rather than migrating on a conversion it can't vouch for.
documentedKiCad #18467 - 4NAMED UNSUPPORTED
Pre-V6 (Protel) PcbDoc
openA pre-Version-6 PcbDoc can import as nothing at all — no board, no error, no warning — the most dangerous failure because it looks like success.
Crosspad names this format as UNSUPPORTED against your specific project — an explicit, named gap instead of a silent no-op you might not notice.
documentedKiCad #18467 - 5DETECTED
Keepouts
open · public SiFive HiFive1 fixtureA polygon cutout can arrive as an over-broad keepout, producing spurious DRC errors on a board that was clean at the source.
Crosspad compares keepout regions against the source and flags any that changed shape or scope, so a false DRC storm is explained rather than left for you to chase.
documentedKiCad #15587 - 6REPAIR / DECISION
Net-class membership
openNet classes can survive while their membership does not — the clearance class exists but constrains no nets, so the board passes DRC because the rules are effectively empty.
Crosspad accounts for every net-class binding, repairs membership where it can prove the mapping safe, and marks unprovable rule intent — high-speed constraints, diff-pair definitions — as an engineering decision rather than reducing it to plain connectivity.
Check my board — freeBreakdown page in progress — the KiCad issues are linked above - 7DETECTED
Buses (shared member name)
≤10.0.4 · fixed in 10.0.5Buses whose members share a name could arrive with those members unconnected — valid in Altium, silently disconnected in KiCad.
Crosspad rebuilds the connectivity graph from your source and compares it net by net, so a member that lost its bus is caught, not trusted — and version-scoped honestly, because this one is already fixed in 10.0.5.
documentedKiCad #20707Not checked at launch — how it will be reportedBreakdown page in progress — the KiCad issues are linked above - 8NOT YET IN SCOPE
Hierarchy & reference stability
openComplex hierarchical projects can fail to import where simple ones succeed, and hierarchical import can reset reference designators or collide on duplicate sheet names — quietly re-shaping the schematic or leaving a section missing.
Schematic structure is outside the launch scope: the migration service takes one .PcbDoc board file, and .SchDoc and .PrjPcb are named as unsupported by the free analysis. When schematic migration ships, Crosspad will reconstruct the sheet hierarchy from your source and confirm every sheet, port and reference is still present and still means the same thing — reporting what it rebuilt and what needs a human.
Not checked at launch — how it will be reportedBreakdown page in progress — the KiCad issues are linked above - 9DETECTED
Project variables & variant params
open · seen in 10.0.0Project parameters may not transfer, and a variable reference like ${PCB_REVISION} can render as literal text instead of its value — the copper is right, the revision on the fab drawing is wrong.
Crosspad accounts for project variables, revision and variant metadata against the source and flags any field that arrived unresolved.
Check my board — freeBreakdown page in progress — the KiCad issues are linked above - 10AUTO-REPAIR
Copper / soldermask text
seen in 10.0.3Text on copper or mask layers can arrive mispositioned — a marking that moved without warning.
Crosspad compares copper- and mask-layer text against the source placement, repairs what it can prove equivalent, and flags the rest.
documentedKiCad #24504Check my board — freeBreakdown page in progress — the KiCad issues are linked above - 11FLAGGED
Layer mapping & the board outline
openAn Altium layer with no clean KiCad equivalent can be silently remapped, and an invalid or unusual layer name has caused the board outline itself — Edge.Cuts — to be dropped on import.
Crosspad accounts for every layer and the board outline explicitly; a remapped or missing layer is named as an action, never passed as complete.
Check my board — freeBreakdown page in progress — the KiCad issues are linked above - 12FLAGGED
Custom / complex pad stacks
open · long-standingComplex pad stacks are documented as “not supported yet” — a long-standing, still-open gap a standard migration passes over without a clear warning.
Crosspad names unsupported pad geometry against your specific board rather than silently approximating it.
documentedKiCad #8182Check my board — freeBreakdown page in progress — the KiCad issues are linked above - 13NOT YET IN SCOPE
Harnesses
openHarness objects can come across only partially, and in some projects the harness import crashes outright — leaving a schematic that is subtly incomplete or won't finish importing.
Harnesses are schematic objects and sit outside the launch scope. When schematic migration ships, Crosspad will reconstruct harness connectivity from your source where it can prove it, and flag what it can't — honestly, this is a family we're still building fixtures for.
Not checked at launch — how it will be reportedBreakdown page in progress — the KiCad issues are linked above - 14DETECTED
3D / STEP models
openA standard migration can drop 3D and STEP models entirely — you open the board in KiCad and find no 3D bodies, and library 3D models may not carry either. It doesn't break the netlist, but it breaks mechanical review and enclosure fit.
Crosspad accounts for every 3D-model reference against your source and names what didn't come across — an accounting-and-flag check, not a claim to perfectly rebuild geometry.
documentedKiCad #15058
Also documented on the tracker and re-verified each refresh: symbol rotation reported as 0° (#19630), footprint refs shown as “UNK” (#18502), an imported schematic that fails to save (#11236). These are version-specific and fold into the families above as fixtures land.
The broad overview of what can breakAn issue on this page becomes a finding on your report.
A tracked issue tells you a failure is possible. It doesn't tell you whether it touched your board. Crosspad closes that gap: it reads your Altium board directly, migrates it, compares the result back semantically, and for every family above returns a verdict — verified, repaired, or flagged for a decision.
- 01ANALYZE SOURCE
Read the Altium board directly — components, nets, net classes, rules, layers, copper.
- 02COMPARE
Match the result back to the source, by meaning: every net, rule, designator, region and layer.
- 03REPAIR — OR ROLL BACK
Correct known breaks, then re-parse and re-validate. A repair that can't be proven safe is rolled back and flagged, never silently kept.
- 04EXPLAIN
Produce an evidence report: what's verified, what was repaired, and what still needs an engineering decision.
If Crosspad can't verify a critical part of the migration, it doesn't mark it safe.
Read the full methodologyCurated, not exhaustive — and honest about the floor.
This is a verified index, not the entire KiCad tracker. New families are added as we confirm them with fixtures; per-family breakdowns arrive one at a time. And detecting a break is not the same as fixing it. At launch the migration service processes one Altium .PcbDoc board file, version 6 or later — either form Altium writes: the binary file, or the ASCII text form, which is converted and checked against an independent count of your board before anything is migrated. A zipped project is accepted too, but only as a container for that one board: the .PcbDoc inside it is migrated, and the schematics, the project file and the libraries that came in the archive are not — they are listed in the report, not converted. .SchDoc schematics, .PrjPcb project files and libraries sent on their own are named as unsupported by the free analysis rather than silently skipped, and so are pre-Version-6 (Protel) boards. Where target equivalence can't be proven — high-speed rule intent, a layer with no KiCad equivalent, a custom pad stack — Crosspad marks an engineering decision and hands it to you. The promise here is that every board family is made visible for your own file, not that every one is solved.
Frequently asked questions.
What are the known Altium → KiCad import issues?
The verified families are: multi-channel / repeated designators, copper fills and zones, legacy ASCII PcbDoc files, pre-V6 (Protel) files, keepouts, net-class membership, buses, hierarchy and reference stability, project variables, copper/mask text, layer mapping and the board outline, custom pad stacks, harnesses, and 3D / STEP models. Each is documented in KiCad's own public issue tracker; several are version-specific.
Is the KiCad Altium importer buggy?
It's free, official, and improving almost every release — that's the honest framing. Some of the entries here are tracked GitLab issues, some are documented limits in KiCad's import docs, and several get fixed over time (the bus issue #20707 was fixed in 10.0.5). The gap isn't that the importer is bad — it's that a standard migration produces a file with no proof of fidelity, so a silent loss is on you to find.
Are these issues fixed in the latest KiCad?
Some are. The bus shared-member issue (#20707) is fixed as of 10.0.5. Many are still open as of 10.0.6 — net-class membership (#15584), multi-channel designators (#24861), variable literals (#24455), custom pad stacks (#8182). Scope changes per release, which is why every family is version-scoped and this index is refreshed each release.
Where do these issue numbers come from?
KiCad's public GitLab tracker (gitlab.com/kicad/code/kicad) and, where relevant, KiCad's own import documentation. They're cited as neutral evidence that a failure is real and reproducible — not as a claim about Crosspad's own internals.
Is this the full list of import issues?
No — it's a curated index of verified families, not the entire tracker. It's kept deliberately shallow-but-solid: the families that cost real boards, each confirmed, with per-issue breakdowns added as we verify them.
How do I know if my board hits any of these?
The families here are general; your board is specific. Upload one .PcbDoc board file and get evidence of exactly which board families affect it — what's verified, what it repairs, and what it flags. Schematic-only families (buses, hierarchy, harnesses) are not checked at launch, and the index marks them as such rather than implying otherwise.
Find out which of these actually touch your board.
Point Crosspad at an Altium project and get evidence of exactly which of these tracked families affect it: what's verified, what it repairs, and what it flags for you.
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-30. Anchored to KiCad 10.0.6 (2026-08-29). This index is refreshed on each KiCad point release that changes Altium import; every family is scoped to the versions it affects, and sources are KiCad's public issue tracker and import documentation.