Skip to main content
DESIGN RULES · ALTIUM → KICAD · AS OF KICAD 10.0.6 (2026-08)

What happens to Altium design rules in KiCad?

Your design rules are the intent that keeps a board manufacturable — clearances, widths, net classes, high-speed constraints. A standard migration can carry the rule names and quietly drop what they apply to. Crosspad checks which rules actually survived, and flags the ones that need a decision.

Free analysis on one Altium .PcbDoc — one board file, not a project. Files are processed as described in our Security policy.
WHY RULES ARE THE INVISIBLE PART

A ruled board and a board that looks ruled aren’t the same thing.

Nets and copper are visible — you’d notice a missing trace. Design rules are invisible: the board opens, the rule categories are even there, and nothing tells you they no longer constrain the right nets. That’s exactly the kind of silent gap Crosspad is built to catch.

THE SHORT ANSWER

Does KiCad import Altium design rules?

Partly — and the part that goes missing is the part that matters. A standard Altium → KiCad migration can bring across the rule categories — clearances, track widths, via sizes — as named entries. What it can drop is the net-class membership and bindings that tell each rule which nets to constrain (KiCad #15584). The result is a board that looks ruled: the rule list is there, but the rules govern nothing. So the honest answer is that the rules’ names can come across; what they actually enforce often doesn’t. Crosspad checks which rules still constrain the right nets in the migrated board, and clearly flags the ones that don’t.

The rule list survives. What it enforces is the part that quietly doesn’t.

THE SILENT PART

What can quietly go wrong.

  • Net-class membership

    Rule categories import, but which nets belong to them can be dropped — so a clearance or width rule ends up constraining nothing.

  • Rule bindings

    A rule that no longer knows its nets is a rule in name only; DRC then passes for the wrong reasons.

  • High-speed / xSignal intent

    Impedance, length-matching and differential intent don’t cleanly translate — the pair definitions themselves aren’t carried.

Each row links to the public doc or issue that documents it.

NET CLASSES

Rules that constrain nothing.

Net classes are the clearest example: after a standard migration the class list can be intact while its memberships are empty (KiCad #15584). The rule exists; the nets it should govern don’t belong to it. Crosspad independently rebuilds which nets belong to which class from your source and reports every gap — so a rule that “passed” because it constrained nothing is caught, not trusted.

A class list can survive intact while its memberships are empty — so the rule exists, but the nets it should govern don’t belong to it.

AT SCALE

The more rules your board has, the more a migration leaves behind.

On a small board you might rebuild a few rules by hand and move on. On a real project you can’t. Teams trying to import Altium design rules into KiCad on larger boards report dozens of rules — on the order of 40 to 80 — that don’t transfer at all, leaving no constraint set to keep developing the board against (KiCad.info forum #68522). This is also why “kicad custom design rules like altium” is a recurring search: KiCad’s custom-rule system is genuinely capable, but it isn’t a one-to-one match for Altium’s query-based constraint language, and a standard migration won’t rewrite one into the other for you (KiCad.info forum #45200). Crosspad doesn’t pretend the two rule systems are equivalent. It accounts for every rule in your source — which survived with its bindings intact, which came across as an empty shell, and which will need to be rebuilt — so the gap is a known list you see up front, not a surprise you hit mid-layout.

  • Rule volume

    On larger boards, teams report 40–80 design rules that simply don’t transfer — leaving nothing to keep developing against.

  • Custom rules

    KiCad’s custom-rule system is real, but it isn’t a one-to-one match for Altium’s constraint language — and a standard migration won’t translate your rules into it.

See the tracked rule and connectivity issues
THE CROSSPAD PROCESS

Verify what survived — and be honest about the rest.

  1. 01
    DETECT

    Read your Altium rules and net-class memberships directly from the source.

  2. 02
    COMPARE

    Check which rules and bindings actually carried into the result.

  3. 03
    REPAIR OR DECIDE

    Restore what it can prove safe (and re-validate); where a rule’s target equivalence can’t be proven — high-speed intent especially — flag it as an engineering decision rather than guess.

  4. 04
    EXPLAIN

    Report which rules are verified, which were repaired, and which need your call.

If we can’t prove a rule means the same thing after migration, we don’t mark it safe — we ask.

See the full migration process
THE HONEST LIMIT

We don’t claim rule equivalence.

KiCad’s rule system and Altium’s constraint system aren’t a one-to-one mapping, and behavioral equivalence isn’t something anyone can honestly promise across every rule. So Crosspad doesn’t. It accounts for every rule — verified, repaired, or surfaced as a decision — instead of asserting a match it can’t prove.

FAQ

Altium design rules in KiCad — the questions engineers ask.

Do Altium design rules import into KiCad?

Partly. Rule categories can come across, but net-class membership — which nets a rule applies to — can be dropped (KiCad #15584), so rules may constrain nothing. High-speed pair definitions aren’t carried at all.

Will my clearances and widths survive?

Often the values do, but only if they’re still bound to the right nets. Crosspad verifies the binding, not just the number.

Does Crosspad guarantee my rules migrate perfectly?

No. Rule equivalence isn’t something we can honestly guarantee. We verify what survived, repair what we can prove safe, and clearly flag what needs an engineering decision.

Can I import Altium design rules into KiCad?

You can import the project, but importing the rules themselves is the weak link. The rule categories may come across; the net-class membership that makes each rule enforce anything can be dropped (KiCad #15584), and on larger boards teams report dozens of rules that don’t transfer at all (KiCad.info forum #68522). Crosspad tells you exactly which of your rules survived with their bindings intact, and which need a decision.

Can KiCad do custom design rules like Altium?

KiCad has a custom-rule system, but it isn’t a one-to-one match for Altium’s query-based constraint language, and a migration won’t translate your Altium rules into KiCad’s custom-rule syntax for you (KiCad.info forum #45200). Expect to rebuild the more advanced rules by hand. Crosspad’s job is to hand you the exact list of what carried and what didn’t, so nothing is missed.

What happens to my design rules on a large board with a lot of rules?

The bigger the rule set, the bigger the loss: teams moving larger projects report 40–80 rules that don’t come across, leaving no rule set to keep working against (KiCad.info forum #68522). Crosspad accounts for every rule in your source so you see the full gap before you start laying out, not after.

Find out which of your rules actually survived.

Free analysis on one Altium .PcbDoc — one board file, not a project. Files are processed as described in our Security policy.

Design-rule behaviour reflects a standard Altium → KiCad migration as of KiCad 10.0.6 (2026-08-29). It changes most releases; version-specific claims above are scoped, and this page is updated per release.