Migrate a PcbDoc to KiCad — every net, fill, keepout and layer accounted for.
A standard PcbDoc → KiCad migration gives you a board that opens. What it doesn't give you is proof the copper came across. Fills, keepouts, layer mapping and the board outline can all change without a single error. Crosspad verifies your PcbDoc against its source — detecting every one, repairing what it can prove safe, and flagging the rest — so nothing disappears in silence.
A .PcbDoc that opens in KiCad isn't a board that's been verified.
The native importer opens your .PcbDoc and gives you something that looks like your board. The problem is everything you can't see at a glance: a zone whose clearance changed, a keepout that grew, a layer with no clean equivalent, an outline that didn't come across. The board opens, DRC may even pass, and the loss surfaces later — at review, at the fab, or not at all. Crosspad exists to check the whole board against your source and prove what survived, not just produce a file that loads.
A board that loads isn't a board that's verified.
What a standard PcbDoc → KiCad migration quietly leaves on the board.
These aren't hypotheticals — each is documented in KiCad's own import docs and public issue tracker, and several are version-specific (documented against KiCad 10.0.6, 2026-08-29). Crosspad checks every one against your source PcbDoc, and repairs or flags it.
Soldermask relief can be lost and zone clearances can arrive wrong — so a routine refill silently disconnects copper.
Polygon cutouts can come across as over-broad keepouts, triggering spurious DRC errors on copper that was fine.
A layer with no clean equivalent can be silently remapped, and an invalid layer name has dropped Edge.Cuts — the board outline itself.
Text on copper or mask layers can arrive mispositioned — a shifted part number or polarity mark you won't catch by eye.
Clearance and width classes survive, but which nets belong to them can be dropped — so the copper rules constrain nothing.
Channel suffixes get stripped (C33A / C33B → C33), collapsing distinct parts into duplicate references and breaking the board's BOM and netlist.
Complex or custom pad stacks aren't supported and don't come across — a long-standing, still-open gap.
A field like ${PCB_REVISION} can render as literal text on the fab drawing instead of its value.
An older ASCII .PcbDoc can import as nothing at all — no board, and no error to tell you.
Board-level failure modes reflect a standard Altium → KiCad migration as of KiCad 10.0.6 (2026-08-29). Behavior changes most releases; version-specific rows (e.g. copper/mask text #24504, seen in 10.0.3) are noted, and this page is updated per release.
Every net. Every fill. Every keepout and layer. Accounted for.
- 01ANALYZE SOURCE
Read your .PcbDoc directly — components, nets, copper, zones, keepouts, layers and the board outline.
- 02MIGRATE
Move the whole board to KiCad, using the strongest strategy for that project.
- 03COMPARE
Match the KiCad result back to the source, semantically: every net, zone, keepout, layer and outline geometry.
- 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 on the board, what was repaired, and what still needs an engineering decision.
If Crosspad can't verify a critical part of the board, it doesn't mark it safe.
Know exactly what changed on the board.
| OBJECT | SOURCE | TARGET | REPORTED AS |
|---|---|---|---|
| Components / footprints | every designator read | every designator matched | VerifiedVERIFIED |
| Nets | nets and pin connectivity read | all matched | VerifiedVERIFIED |
| Net-class membership | membership read | restored, then revalidated | Fixed and re-checkedREPAIRED_AND_REVALIDATED |
| Copper zones | net, layer, clearance read | restored with net, revalidated | Fixed and re-checkedREPAIRED_AND_REVALIDATED |
| Keepouts | regions read | regions matched | VerifiedVERIFIED |
| Edge.Cuts outline | closed outline | present | VerifiedVERIFIED |
| Layer map | layer roles read | mapped; the mapping is stated | Expressed differently in KiCadTRANSLATED_EQUIVALENTLY |
| Copper / mask text | text items read | repositioned where dropped, revalidated | Fixed and re-checkedREPAIRED_AND_REVALIDATED |
| Custom pad stack (BGA) | custom stack 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.
Which PcbDoc files we account for — and which we won't pretend to.
Crosspad targets Altium board files (.PcbDoc, V6 and later, typically alongside their .PrjPcb) in either form Altium writes: the binary file, or the ASCII text form, which is converted to the binary form and reconciled against an independent count of your board before anything is migrated — and where the two disagree the board is named unsupported rather than migrated on a conversion we can't vouch for. Pre-V6 (Protel) boards are named as unsupported, not silently skipped — the file a standard migration imports as nothing is reported as an explicit, named gap. And where board equivalence can't be proven — a layer with no KiCad equivalent, a custom pad stack — Crosspad marks an engineering decision and hands it to you, rather than quietly reducing it.
Frequently asked questions.
Can KiCad open an Altium .PcbDoc file?
Yes — KiCad's native importer opens .PcbDoc board files directly, and it improves almost every release. What it doesn't do is tell you what changed on the way in. Crosspad checks the imported board against your source PcbDoc and reports every difference.
What does a standard PcbDoc → KiCad migration lose?
On the board, most often: copper fills and zone clearances (so a refill can disconnect copper), keepouts, layer mapping and the board outline, copper/mask text position, net-class membership, and multi-channel reference designators. Each is documented in KiCad's own tracker or import docs.
Why does the board open fine if something was lost?
Because from the importer's point of view nothing went wrong — the copper still shows, and DRC may still pass when the rules that should constrain it came across empty. The loss is silent by nature; that's exactly why an independent check of the PcbDoc matters.
Can Crosspad convert an ASCII or pre-V6 .PcbDoc?
An ASCII .PcbDoc, yes: it is converted to the binary form and reconciled against an independent count of your board before anything is migrated, and where the two disagree the board is named unsupported rather than migrated on a conversion we can't vouch for. A pre-V6 (Protel) board, no — that one is named unsupported against your specific file. Either can be read as nothing at all by the native importer, with no error (KiCad #18467); neither is ever passed silently here.
Does Crosspad guarantee my PcbDoc migrates perfectly?
No one honestly can. What Crosspad guarantees is that nothing on the board is lost in silence: every net, fill, keepout and layer is detected, repaired where it can be proven safe, or clearly flagged for a decision.
How do I verify my PcbDoc came across correctly?
Point Crosspad at the .PcbDoc and get evidence of exactly what a KiCad migration keeps, repairs and flags — before you commit to the board.
See exactly what your PcbDoc keeps, repairs and flags — before you commit.
Point Crosspad at an Altium .PcbDoc and get evidence of what a KiCad migration keeps on the board, what it repairs, and what it flags for you.
Board-level failure modes reflect a standard Altium → KiCad migration as of KiCad 10.0.6 (2026-08-29). Behavior changes most releases; version-specific rows (e.g. copper/mask text #24504, seen in 10.0.3) are noted, and this page is updated per release.