Don’t trust a converter. Verify the migration.
An importer can’t be the only thing that certifies its own output — it can’t see what it silently dropped. Crosspad observes your source independently, compares it to the result, and produces evidence.
An importer can’t certify its own output — Crosspad reads the source independently.
The system that produces a migration can’t be the only one that certifies it.
If the importer both converts your board and declares the result “done,” nothing catches what it quietly changed — a dropped net-class membership, a stripped channel suffix, a keepout that turned into a DRC error. Crosspad breaks that loop: it reads the original Altium board directly, not through the importer, and holds the result up against it.
Independent observation, then proof.
- 01INDEPENDENT SOURCE ANALYSIS
Read the Altium board directly — components, nets, net classes, rules, layers, copper — with its own parser, not the importer’s.
- 02INDEPENDENT TARGET ANALYSIS
Read the KiCad result the same way, independently.
- 03SEMANTIC COMPARISON
Match source to target by meaning, not by file diff: does every net, rule and connection still mean the same thing?
- 04DETERMINISTIC VALIDATION
Check engineering invariants. A check only passes if it applies and passes — or is provably not applicable. “Unknown” is never counted as “fine.”
- 05REPAIR — OR ROLL BACK
Correct known discrepancies, then re-parse and re-validate. If a repair can’t be proven safe, it’s rolled back and flagged, never quietly kept.
- 06EVIDENCE
Produce a report: what’s verified, what was repaired, and what needs an engineering decision.
We try to break our own checks.
Detection is only worth trusting if it catches damage it hasn’t seen. Crosspad’s checks are stress-tested by mutation testing — deliberately injecting faults into known-good boards and confirming each one is caught — alongside negative controls (clean boards that must stay clean) and false-green monitoring, which actively looks for anything wrongly marked safe. Multiple independent parsers cross-check each other so no single reader’s blind spot becomes a silent pass.
Inject known damage; confirm every fault is caught.
Clean boards that must stay clean.
Actively hunt for anything wrongly marked safe.
Independent readers cross-check each other.
If we can’t verify it, we don’t mark it safe.
- Unknown critical semantics gate the result — they never become an optimistic “success.”
- An unsafe repair is rolled back and surfaced, not silently applied.
- Where target equivalence can’t be proven — high-speed rule intent, for example — Crosspad calls it an engineering decision instead of reducing it to plain connectivity.
- A file that was produced is not a migration that was verified.
Questions about how we verify.
How does Crosspad verify a migration?
It observes your Altium source and the KiCad result independently, then compares them by meaning — every net, net class, rule, layer and copper connection — instead of trusting whatever produced the file to grade its own work. The checks are deterministic: a result passes only if it applies and passes, or is provably not applicable, so "unknown" is never counted as "fine." Where a discrepancy can be corrected and the repair proven safe, Crosspad repairs it; where it can't, it flags it. The output is an evidence report of what's verified, what was repaired, and what still needs an engineering decision.
What is false-green monitoring?
A "green" result that's actually wrong — a migration marked safe while something was silently lost — is the most dangerous failure there is, because you'd trust it. False-green monitoring is the discipline of actively hunting for exactly those cases. Crosspad's checks are stress-tested with mutation testing (deliberately damaging known-good boards to confirm each fault is caught) and negative controls (clean boards that must stay clean), and the method keeps watching for anything marked safe that shouldn't be. The aim isn't to look green — it's to make a real loss unable to hide behind a green.
Does Crosspad guarantee a perfect migration?
No — and anyone who promises that isn't being honest. Some things can't be proven equivalent (high-speed rule intent, for example), some formats are out of scope, and a share of boards will always need an engineering decision. What Crosspad offers is accountability, not a guarantee: nothing is marked safe that wasn't verified, nothing is repaired unless the repair can be proven safe, and nothing is dropped in silence. You see exactly what's verified, what was repaired, and what's left for you to decide.
How is this different from running DRC/ERC in KiCad?
DRC and ERC check the KiCad file against itself — they confirm the board you ended up with is internally consistent. But they never saw your Altium source, so they can't tell you a standard migration dropped something on the way in. A net class that lost its members, a design rule that didn't carry over, a channel suffix that was stripped — these can look perfectly clean to DRC, because the information that would flag them is simply gone: the board passes precisely because the missing rules now constrain nothing (documented: KiCad #15584). Crosspad compares the result back to the independently-read source, so it catches what's absent, not only what's malformed.
Where to go from the method.
- Compatibility matrix
Exactly which Altium formats and constructs are in scope, gated, or named as unsupported.
- Altium → KiCad migration
The whole move, end to end — what a standard migration quietly leaves behind, and how Crosspad accounts for it.
- Is it safe to migrate?
The decision guide — what to check before you trust an Altium → KiCad move.
- Reference docs
File formats, the report vocabulary the method produces, viewer controls and how a migration runs — every public page, indexed.