Altium copper fills and zones can silently disconnect after a KiCad import.
A standard Altium → KiCad migration can drop the soldermask relief on filled regions (KiCad #13750) and import zone clearances incorrectly (KiCad #18408) — so a routine "refill zones," the ordinary thing every engineer does before a fab release, quietly pulls copper back from the pads it used to connect. The board opened green; a plane is now split, and nothing warned you. Crosspad detects fills that were dropped or altered, restores component-owned fills with their net, and re-validates — so a disconnected pour is a finding, not a surprise at the fab.
What a standard Altium → KiCad migration quietly does to copper fills.
Two documented, reproducible faults — not opinions. Each is in KiCad's own public issue tracker, and both are open as of KiCad 10.0.6 (2026-08-29). They compound: the first changes what gets fabricated, the second is the one that silently disconnects copper.
- Soldermask relief on regions is droppedopen as of 10.0.6
The relief that keeps a filled region clear of the solder mask can be lost on import — so what actually gets fabricated no longer matches the source.
documented: KiCad #13750 - Zone clearances import incorrectly → a refill disconnects copperopen as of 10.0.6
A zone's clearance can come across wrong. Because KiCad recomputes zones on refill, the next routine "refill zones" recomputes the pour with the wrong clearance and pulls it back from pads it used to connect — splitting a plane that was solid.
documented: KiCad #18408
Both remain open as of 10.0.6. Fill and zone behavior changes most releases; this page is re-verified and re-scoped each KiCad point release, and where a fix ships we say so and give the version.
How does a clean import silently disconnect a plane?
- 01
A standard migration imports the board. It opens. The copper pour is visibly there; DRC looks fine.
- 02
- 03
You refill the zones — or KiCad refills them automatically — the ordinary step before a fab release.
- 04
With the wrong clearance, the recomputed pour pulls back from the pads it used to connect. The plane splits; a net that was solid is now broken.
- 05
Nothing warned you, because the board was "imported successfully." You find out at DRC on the next spin — or you don't, and it ships.
This is the exact class of failure this page exists to make visible: copper on screen is not proof of copper that's connected.
documented: KiCad #18408
Every fill, on its net, accounted for.
A tracked issue tells you this failure is possible. It doesn't tell you whether it touched your board. Crosspad closes that gap for the copper-fill family specifically: it reads the fills from your Altium source and checks each one against the migrated result.
- 01DETECT
Read the fills from your Altium source — solid fills, regions and polygon pours — with their net and layer, and compare each to the migrated result: present, on the right layer, on the right net, connectivity intact?
- 02RESTORE WITH ITS NET
Where a fill was dropped or altered — including component-owned fills — restore it with its net association, not as an anonymous shape.
- 03RE-VALIDATE — OR ROLL BACK
Re-parse and re-validate after the repair. A restoration that can't be proven safe is rolled back and flagged, never silently kept.
- 04FLAG
Where equivalence can't be proven — a clearance whose intent can't be matched, a cutout that changed meaning — surface it as an engineering decision instead of quietly accepting the geometry as correct.
A capability verb, not a score: Crosspad detects it and, where it can prove the fix safe, repairs it and re-validates; an unsafe repair is rolled back and flagged.
If Crosspad can't prove a fill is still connected on its net, it doesn't mark it safe.
The promise here is that this family is made visible for your board — detected, restored where provable with its net, the rest clearly flagged — not that every fill break is solved. Where a clearance or relief intent can't be proven equivalent in KiCad, it becomes a decision handed to you, not a silent pass.
Frequently asked questions.
Why does my copper plane disconnect after importing an Altium board into KiCad?
A common cause is that the zone's clearance imported incorrectly (KiCad #18408). KiCad recomputes zones on refill, so the next routine "refill zones" recomputes the pour with the wrong clearance and pulls back from pads it used to connect — splitting a plane that looked solid on import. Crosspad compares your fills back to your Altium source and flags any whose connectivity changed, instead of trusting that copper on screen is copper that's connected.
Are these Altium fill and zone issues fixed in the latest KiCad?
As of KiCad 10.0.6 (2026-08-29), both are still open: soldermask relief on regions can be lost (#13750) and zone clearances can import incorrectly (#18408). Fill and zone behavior changes most releases, so this page is re-verified and re-scoped each KiCad point release — if a fix ships, we scope it to the version. Either way, "the board opened" isn't proof the pours are still connected.
Find out whether this touched your board — before you trust it.
The tracked issues are general; your board is specific. Point Crosspad at an Altium board and get evidence of which fills survived, which were restored with their net, and which need a decision.
Free analysis on one Altium .PcbDoc — one board file, not a project. Files are processed as described in our Security policy.
RELATED
- All known Altium → KiCad import issues
- How Altium copper fills migrate to KiCad — original research
- Altium → KiCad migration, accounted for
Last updated 2026-08-30. Anchored to KiCad 10.0.6 (2026-08-29). Both cited issues (#13750, #18408) are open as of this release. This page is re-verified on each KiCad point release that changes Altium import; sources are KiCad's public issue tracker and import documentation.