A polygon cutout arrives as an over-broad keepout — and floods your board with DRC errors.
In Altium, a board cutout and a keepout are different things. A standard Altium → KiCad migration can conflate them — importing a polygon cutout as a keep-out rule area, with keep-out tracks, pads and vias switched on across a region that was only ever a hole. A board that was clean at the source opens to a storm of DRC violations. It's documented, reproducible on a public board, and version-specific. Crosspad detects the changed keepout semantics against your source and flags what moved — so a false DRC storm is explained, not left for you to chase.
Free analysis on one Altium .PcbDoc — one board file, not a project. Files are processed as described in our Security policy.
How a cutout becomes a keepout.
In Altium, a polygon cutout removes copper from a region; a keepout forbids objects there. They mean different things. A standard Altium → KiCad migration can import a polygon cutout as a keepout rule area instead — a keep-out region with keep-out tracks, pads and vias enabled across the whole shape (documented: KiCad #15587). The geometry looks right, but KiCad now believes routing and copper are forbidden where they are perfectly legal, so DRC lights up on a design that passed at the source. #15587 is reproducible on a public board — the SiFive HiFive1 — which makes it a checkable citation rather than an anecdote, and it is open as of KiCad 10.0.6.
A related failure sits one level down. On KiCad before 10.0.5, a footprint's origin and its keepouts could arrive mispositioned on Altium import (documented: KiCad #24847) — the keep-out area no longer sits where the part it protects sits. This one is fixed: #24847 was resolved in the 10.0.5 / 10.0.6 line, so it is scoped to KiCad ≤10.0.4. We call that out because scope is the honest part — some of these get fixed release to release, and a page that warned about a bug your KiCad already resolved would be a liability, not evidence.
- KiCad #15587open · public SiFive HiFive1 fixture
Polygon cutout imported as an over-broad keepout rule area → spurious DRC.
- KiCad #24847fixed in 10.0.5 · scope ≤10.0.4
Footprint origin and keepouts mispositioned on Altium import.
Sources: KiCad's public issue tracker (#15587, #24847) and its Altium import documentation. Cited as neutral, dated evidence that the failure is real and reproducible — not as a claim about how Crosspad works internally. This page covers one verified family; it is not the whole of KiCad's keepout behavior.
What the engineer actually sees.
You open the migrated .kicad_pcb, run DRC, and get a cluster of violations around what used to be a cutout — "track inside keep-out", "pad inside keep-out", "via inside keep-out" — on copper you know is fine. Nothing failed loudly; the import "succeeded". So the time goes into hunting: is the board wrong, or is the rule wrong? On the ≤10.0.4 origin case the tell is subtler still — a footprint's keep-out region sits offset from the part, so the violations don't even line up with the geometry. Either way you're debugging KiCad's interpretation of a board that was already correct, with no signpost telling you the keepout semantics changed in translation.
The keepout that changed becomes a finding, not a mystery.
Crosspad reads your Altium source directly and compares every keepout and cutout region against what landed in KiCad — by scope and shape, not just presence. A cutout that came across as a keep-out rule area, a keepout whose enabled object types changed, an origin-shifted keep-out on an older KiCad: each is surfaced as a named finding tied to the region it affects, so a false DRC storm is explained at its source instead of chased across the board. Where the correct mapping is provable — a cutout that should be a plain void or a board edge, a keepout whose original scope is recoverable — Crosspad repairs it and re-validates; a repair it can't prove safe is rolled back and flagged for you, never silently kept. And because #24847 is version-specific, Crosspad scopes it to the KiCad version in play rather than warning about a bug your release already fixed.
If Crosspad can't prove a keepout still means what it meant in Altium, it flags it — it doesn't mark it safe.
Frequently asked questions.
Why does my Altium board throw DRC errors in KiCad only after import?
A common cause is a polygon cutout being imported as a keep-out rule area (KiCad #15587): KiCad then treats a region that was just a hole as forbidding tracks, pads and vias, so DRC fires on copper that's actually fine. The board didn't change — its keepout semantics did, in translation. Crosspad detects the changed region against your source and flags it, so you're not left guessing whether the board or the rule is wrong.
Is the Altium keepout import problem fixed in the latest KiCad?
Partly, and it depends which one. The mispositioned footprint-origin-and-keepouts issue (#24847) is fixed as of KiCad 10.0.5. The polygon-cutout-as-keepout issue (#15587) is still open as of 10.0.6 and reproducible on the public SiFive HiFive1 board. Scope changes per release, which is why this page is version-scoped and refreshed each KiCad release.
Find out if a cutout became a keepout on your board.
Point Crosspad at your Altium project and get evidence of exactly which keepout and cutout regions changed on the way to KiCad — 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.
RELATED
- All tracked Altium → KiCad import issues
- How copper fills & keepouts silently break
- Migrate Altium to KiCad — every net, rule and region accounted for
Last updated 2026-08-30. Anchored to KiCad 10.0.6 (2026-08-29). #15587 (cutout → keepout) is open as of 10.0.6 and reproducible on the public SiFive HiFive1 board; #24847 (mispositioned origin + keepouts) is fixed in 10.0.5, scope ≤10.0.4. Sources: KiCad's public issue tracker and Altium import documentation. This page is refreshed on each KiCad point release that changes Altium import.