Migrate Altium to KiCad — every net, rule and layer accounted for.
A standard Altium → KiCad migration quietly loses nets, design rules and design intent. Crosspad's migration detects every one, repairs what it can prove safe, and flags the rest — so nothing disappears without you knowing.
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 — the format pages below document what those migrations involve.
Converting your files isn’t the same as migrating your design.
The usual way to move an Altium project to KiCad produces a file that opens — and quietly leaves things behind. Net-class memberships, design rules, bus connectivity, channel designators, copper fills: each can go missing with no warning. A board that opens is not a board that’s correct. Crosspad exists to migrate the whole board and prove it — not just produce a file.
A converted file isn’t a verified migration.
What a standard Altium → KiCad migration quietly leaves behind.
These aren’t hypotheticals — each is documented in KiCad’s public docs and issue tracker. Crosspad detects every one against your source, and repairs or flags it. Four of them here; the full ranked index, with the versions each affects, lives in the issue database.
Net class membership
Rule categories survive, but which nets belong to them can be dropped — so rules constrain nothing.
Multi-channel designators
Channel suffixes get stripped (C33A / C33B → C33), producing duplicate references.
Copper fills & keepouts
Fill relief and keepout areas can change — and a routine refill can silently disconnect copper.
Layers
A layer with no clean equivalent, or an odd name, can be remapped or drop the board outline.
Every component. Every net. Every rule. Accounted for.
- 01ANALYZE SOURCE
Read your Altium board directly — components, nets, net classes, rules, layers, copper.
- 02MIGRATE
Move the whole board to KiCad, using the strongest strategy for that file.
- 03COMPARE
Match the result back to the source, semantically: every net, net class, rule, layer and copper connection.
- 04REPAIR
Correct discrepancies automatically, then re-parse and re-validate. A repair that can’t be proven safe is rolled back and flagged, never silently kept.
- 05EXPLAIN
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.
Know exactly what changed.
| OBJECT | SOURCE | TARGET | REPORTED AS |
|---|---|---|---|
| Components | every designator read | every designator matched | VerifiedVERIFIED |
| Nets | nets and pin connectivity read | all matched | VerifiedVERIFIED |
| Net classes | membership read | restored, then revalidated | Fixed and re-checkedREPAIRED_AND_REVALIDATED |
| Design rules | rule set read | mapped where a KiCad rule exists | Expressed differently in KiCadTRANSLATED_EQUIVALENTLY |
| Differential pairs | pairs and intent read | intent not provable in the target | Needs your callENGINEERING_DECISION_REQUIRED |
| Copper fills | net, layer, clearance read | restored with net, revalidated | Fixed and re-checkedREPAIRED_AND_REVALIDATED |
| Legacy layer (Eco1) | present | no KiCad equivalent — confirm a mapping | Needs your answerACTION_REQUIRED |
One file, and everything needed to trust it.
- Your board as a .kicad_pcb
- The component and net inventories
- The DRC and import reports
- The full migration report
All of it in one file, crosspad-migration.zip.
The analysis is free. A credit is spent only when you unlock a completed migration — a failed or unsupported job never costs anything.
What the migration does not promise: an identical one-to-one result, manufacturability, or electrical or regulatory correctness. The delivered board can still carry KiCad DRC violations, which the report names. A qualified engineer must review the files before manufacturing — checkout states this again before you pay.
The part of your design you came here about.
What we accept today — and what we don’t pretend to.
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 — the format pages above document what those migrations involve. Pre-Version-6 (Protel) boards are named as unsupported. The ASCII text form is not: it is converted to the binary form and reconciled against an independent count of the board — and where the two disagree the board is named unsupported rather than migrated on a conversion we cannot vouch for. Where target equivalence can’t be proven — high-speed rule intent, for example — Crosspad marks it an engineering decision rather than quietly reducing it to plain connectivity.
One credit, one board.
The analysis is free on your own .PcbDoc. You read the evidence report before you spend anything — a credit is only consumed when you unlock the delivery of a completed migration. 1 credit is $249; packs of 5 and 10 cost less per migration.
See pricingFrequently asked questions.
What does Crosspad do that a standard Altium → KiCad migration doesn’t?
A standard migration produces a file and tells you nothing about what it dropped. Crosspad migrates your board, then independently checks the result against your source — detecting lost nets, rules and intent, repairing what it can prove safe, and flagging the rest with evidence.
Is Crosspad a converter?
No. Converting is the easy part. Crosspad’s value is that it accounts for the whole board — it detects and repairs what a standard migration silently loses, and proves it.
What does a standard Altium → KiCad migration lose?
Commonly: net-class membership, design rules, bus connectivity on KiCad ≤10.0.4 (fixed in 10.0.5), multi-channel designators, project variables, some fills and keepouts — each documented in KiCad’s public tracker. See our tracked failure modes.
What file does Crosspad accept, and what do I get back?
At launch you upload 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. What comes back is crosspad-migration.zip: your board as a .kicad_pcb, the component and net inventories, the DRC and import reports, and the full migration report.
Does Crosspad guarantee nothing is lost?
No one honestly can. What Crosspad guarantees is that nothing is lost in silence: everything is detected, repaired where it can be proven safe, or clearly flagged for a decision.
Is it safe to migrate from Altium to KiCad?
Often yes — but “the file opened” isn’t proof. See our decision guide for what to check first.
See everything Crosspad accounts for — before you commit.
Upload one .PcbDoc board file and read the evidence of what a KiCad migration keeps, repairs, and flags for you. You decide about the delivery afterwards.
Free analysis on one Altium .PcbDoc — one board file, not a project. Files are processed as described in our Security policy.
Failure modes reflect a standard Altium → KiCad migration as of KiCad 10.0.6 (2026-08-29). Behaviour changes most releases; every reference above is scoped to the versions it affects, and this page is updated per release.