What can break when migrating from Altium to KiCad?
A standard Altium → KiCad migration gives you a board that opens. What it doesn't give you is a list of what it changed. Nets, design-rule intent, reference designators, copper and layers can all go missing without a single error. Crosspad detects every family of failure below, repairs what it can prove safe, and flags the rest — so nothing disappears in silence.
A break you can see is a break you can fix before the fab.
A board that opens is not a board that's correct.
Almost everything on this page is invisible at first. The migrated board opens, the ratsnest looks clean, DRC passes — and the loss is only found later, at review, at fabrication, or not at all. That's what makes these failures dangerous: a standard migration doesn't warn you, because from its point of view nothing went wrong. Every family below is documented in KiCad's own public tracker or import docs — real, reproducible, and often version-specific. Crosspad exists to make each one visible before it costs you a spin.
The problem isn't that things break. It's that they break silently.
Eight ways a standard migration silently goes wrong — and what Crosspad does about each.
These are the families, not the full catalogue. Each is grounded in KiCad's public issue tracker or its own import documentation, cited as proof the failure is real. For the per-issue detail — affected versions, fixtures, fixes — see the tracked issue database.
- DETECTED
Nets & buses
The ratsnest looks clean, so connectivity feels safe. But buses whose members share a name can arrive with those members unconnected — valid at the source, silently disconnected after. KiCad documented exactly this in #20707 (affecting ≤10.0.4; fixed in 10.0.5) — proof the failure is real, and a reminder that behavior shifts release to release.
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.documented: KiCad #20707 (≤10.0.4) - REPAIR / DECISION
Design-rule intent
Rule categories can survive while the thing that gives them meaning does not: net-class membership can be dropped, so a clearance class exists but constrains no nets (KiCad #15584). Trace widths, clearances and via rules generally have to be rebuilt by hand, and KiCad's own import docs list differential-pair definitions among the elements it does not import — the pair rules may carry, but the pairs themselves don't. The board passes DRC because the rules are effectively empty.
Crosspad accounts for every rule and 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 quietly reducing it to plain connectivity.documented: KiCad #15584 + import dev-docs - AUTO-REPAIR
Reference designators
Multi-channel designs repeat a sheet across channels; the channel suffix is what keeps C33A and C33B apart. A standard migration can strip that suffix (C33A / C33B → C33), collapsing distinct parts into duplicate references (KiCad #24861, #23709). Hierarchical projects hit the same class of problem — refdes reset on import (#11412), duplicate hierarchical sheet names (#19281) — and duplicate references quietly break the BOM and the netlist.
Crosspad detects colliding and stripped designators and, where the original mapping is recoverable, repairs them back to unique references — then re-validates. Anything it can't prove is flagged, never silently renumbered.documented: KiCad #24861 / #23709 / #11412 - NOT YET IN SCOPE
Schematic structure
Toy projects import cleanly; real ones are where structure breaks. Complex hierarchical schematics can fail to import where simple ones succeed (KiCad #20936), harness objects come across only partially and can crash the import outright (#16852, #8741), and an imported schematic has been reported failing to save at all (#11236). The result is a schematic that is subtly re-shaped — or one section quietly missing.
Schematic structure is outside the launch scope: the migration service takes one .PcbDoc board file, and the free analysis names .SchDoc and .PrjPcb as unsupported rather than billing for them. When schematic migration ships, Crosspad will reconstruct the sheet hierarchy from your source and confirm every sheet, connection and hierarchical port is still present and still means the same thing — reporting what it could rebuild and what needs a human.documented: KiCad #20936 / #16852 / #8741 - AUTO-REPAIR
Copper regions
Copper is where “it opens fine” is most dangerous, because the differences are invisible until fabrication. Soldermask relief on fills can be lost and zone clearances can arrive wrong, so a routine zone refill silently disconnects copper (KiCad #13750, #18408). Polygon cutouts can become over-broad keepouts that trigger spurious DRC errors (#15587), and copper- or mask-layer text can arrive mispositioned (#24504).
Crosspad compares fills, zones, keepouts and copper text against the source geometry, auto-repairs what it can prove equivalent, and flags any region it can't — so a disconnected pour is a finding, not a surprise at the fab.documented: KiCad #13750 / #18408 / #15587 - FLAGGED
Layers & the board outline
Altium layer roles don't all have a clean KiCad equivalent. A layer with no equivalent can be silently remapped (KiCad #17351), and an invalid or unusual layer name has caused the board outline itself — Edge.Cuts — to be dropped on import (#18756). A board with no outline, or a plane on the wrong layer, is not an error a standard migration reports.
Crosspad accounts for every layer and the board outline explicitly; a remapped or missing layer is named as an action, never passed as complete.documented: KiCad #17351 / #18756 - DETECTED
Variables & metadata
The fields that identify a board are easy to lose. Project parameters and variables may not transfer, and a variable reference like ${PCB_REVISION} can render as literal text instead of its value (KiCad #24455). KiCad's import docs also list parameter sets and map/implementation definers among elements it does not import. 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.documented: KiCad #24455 + import dev-docs - NAMED UNSUPPORTED
Named-unsupported (the honest floor)
Some things a standard migration simply cannot carry — and the distinction that matters is whether you are told. KiCad's own import documentation lists elements it does not import: SPICE model data (parsed but not simulated), 3D package placement data (read but not applied), complex/custom pad stacks (#8182), embedded boards, coordinate markers, IEEE symbols — plus older files whose code-page/encoding isn't preserved, which can mangle text. Worst of all, legacy ASCII / pre-V6 PcbDoc files can import as nothing at all, with no error (#18467).
Crosspad names each of these as UNSUPPORTED or FLAGGED against your specific project — never a false green. The ASCII text form is the exception: rather than ignoring it, Crosspad converts it and reconciles the conversion against an independent count of your board before migrating it. A pre-V6 board it cannot migrate is named as an explicit gap, not silently skipped.documented: KiCad #18467 / #8182 + import dev-docs
Failure families reflect a standard Altium → KiCad migration as of KiCad 10.0.6 (2026-08-29). Behavior changes most releases; version-specific families are noted, and this page is updated per release.
Board's already in KiCad and something looks wrong? Match the symptom to what silently dropped.
If you've run the import and you're now staring at DRC errors that weren't there, nets that read as unconnected, or a board that just looks wrong, the cause is almost never on screen — it's what a standard migration left behind without a word. This is the reverse lookup: find your symptom, see the failure it usually points to, and confirm it on your own board. Each cause links to the tracked issue with KiCad's own evidence. Behavior is version-specific — this reflects a standard Altium → KiCad migration as of KiCad 10.0.6 (2026-08-29).
| SYMPTOM IN KICAD | WHAT LIKELY DROPPED — SILENTLY (evidence) | VERIFY IT |
|---|---|---|
| DRC flags clearance or keepout violations on copper that was legal in Altium. | An Altium polygon cutout can re-import as an over-broad keepout rule area, so DRC now objects to copper that never violated anything. A standard migration reports the errors, not the reason. documented: #15587the keepouts breakdown | Check my board |
| Pads or whole nets show as unconnected — a ratsnest reappears where Altium had solid copper. | A copper zone can lose its connection on the first refill: the pour looks unchanged but no longer ties the net together. Connectivity was valid at the source and broke silently after. documented: #13750 / #18408the copper-fills breakdown | Check my board |
| The same reference designator appears twice — or the BOM quantity doesn't match the schematic. | In a multi-channel design the channel suffix is what keeps repeated parts distinct. A standard migration can strip it, collapsing C33A and C33B into a single C33 and quietly breaking both the BOM and the netlist. documented: #24861 / #23709the multi-channel designators breakdown | Check my board |
| The 3D view is empty, or components have no body / STEP model. | Altium 3D package placement data is read but not applied on import, so the board arrives with no component bodies — nothing errors, the models are simply absent. documented: #15058the 3D-models breakdown | Check my board |
| The board opened empty — no board, no components, and no error message. | A legacy ASCII / pre-V6 .PcbDoc can import as nothing at all. A standard migration produces an empty board and reports success. documented: #18467the ASCII / pre-V6 breakdown | Check my board |
Don't see your symptom? These are the common ones — the tracked issue database has the rest, per version and per fixture.
Every one of these becomes a finding, not a surprise.
Crosspad doesn't hand you a longer worry list — it resolves it. 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.
A break you can see is a break you can fix before the fab.
| FINDING | DETAIL | OUTCOME | REPORTED AS |
|---|---|---|---|
| Bus SPI_DATA | shared-member connectivity | rebuilt from source, revalidated | Fixed and re-checkedREPAIRED_AND_REVALIDATED |
| Net-class membership | classes with no bound nets | empty classes named for a decision | Needs your callENGINEERING_DECISION_REQUIRED |
| Channel designators | R*_CH2 collided → R* | restored unique, revalidated | Fixed and re-checkedREPAIRED_AND_REVALIDATED |
| Copper zone GND | refill delta detected | disconnect flagged — confirm the clearance | Needs your answerACTION_REQUIRED |
| Edge.Cuts outline | closed outline | present | VerifiedVERIFIED |
| ASCII .PcbDoc | ASCII text form | converted, then reconciled against an independent count | Fixed and re-checkedREPAIRED_AND_REVALIDATED |
| Pre-V6 board | Protel / pre-Version-6 | cannot import — named, not skipped | Out of scopeUNSUPPORTED |
What we surface — and what even we can only report.
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. And detecting a break is not the same as fixing it: where target equivalence can't be proven — high-speed rule intent, a layer with no KiCad equivalent — Crosspad marks an engineering decision and hands it to you, rather than quietly reducing it. The promise on this page is that every problem is made visible, not that every problem is solved.
Frequently asked questions.
What can break when you migrate from Altium to KiCad?
Most often: bus and net connectivity, design-rule intent (net-class membership, differential-pair definitions), reference designators in multi-channel and hierarchical designs, copper fills and keepouts, layer mapping and the board outline, and project variables. Legacy ASCII/pre-V6 files may not import at all. Each is documented in KiCad's own tracker or import docs.
Why doesn't the board show an error if something broke?
Because a standard migration produces a file that opens, and from its point of view nothing went wrong — nets still route, DRC still passes when the rules that should constrain them came across empty. The loss is silent by nature; that's exactly why an independent check matters.
Are these KiCad bugs?
Some are tracked issues with GitLab IDs; some are documented limits in KiCad's own import documentation. Several are version-specific and get fixed over releases — the bus issue #20707, for example, was fixed in KiCad 10.0.5. The importer improves almost every month, which is why the check has to be per-project and per-version.
Can Crosspad fix everything that can break?
No — and no honest tool can. What Crosspad guarantees is accountability: every break is detected, auto-repaired where it can be proven safe, or clearly flagged for a decision. Nothing disappears in silence.
How is this different from the tracked issues list?
This page is the overview of what can break. The tracked issue database has the per-issue detail — affected versions, fixtures, and Crosspad's detect/repair for each.
How do I know if my project is affected?
The families here are general; your project is specific. Point Crosspad at it and get evidence of exactly what would break, what it repairs, and what it flags.
Why do I get DRC errors in KiCad after importing from Altium?
A common cause is an Altium polygon cutout that re-imported as an over-broad keepout rule area, so KiCad's DRC flags copper that was always legal — the errors are real to KiCad but the geometry changed on import, not your design. Empty net-class rules can also make DRC pass on nets it should constrain. Both are documented in KiCad's tracker; confirm which one applies to your board rather than clearing errors blind.
Why are nets unconnected after importing an Altium board into KiCad?
Most often a copper zone lost its connection on the first refill: the pour looks identical but no longer ties the net together, so pads that relied on it read as unconnected (KiCad #13750 / #18408). The connectivity was valid at the source and broke silently after — which is exactly why the result has to be checked against the original, net by net.
Why does my board look wrong in KiCad after importing from Altium?
Because a standard migration produces a board that opens without telling you what it changed. Duplicate reference designators from stripped multi-channel suffixes, keepout areas that ballooned from polygon cutouts, a copper pour that shifted or lost its relief, a missing 3D view, or an empty board from a legacy file each look like a KiCad problem but trace back to a silent drop on import. Match the specific symptom to its cause above, then verify it on your own board.
Find out what would break — before it does.
Point Crosspad at an Altium project and get evidence of exactly which of these 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.