Blog · October 23, 2026
Keeping legacy alive: when the design sources are no longer complete
Not every piece of electronics we look after was created here. Some of it we took over as legacy: service software written in Visual Basic 6, firmware sources in the Windows-1252 character set, circuit boards of which only the manufacturing data still exists. That is not the exception but the norm, as soon as a device is older than the tools it was built with. Here is what we have learned along the way.
Review first — and do not trust the file dates
Legacy rarely arrives as a tidy archive; usually it is a copy of a drive. The first temptation is to sort by date. That leads you astray: in one inherited collection, almost every file carried the same date — that of the copy — and some even showed 1 January 1980. That is the earliest date the old FAT file system can store; it usually appears where no valid date survived copying or zipping.
The order of the revisions is therefore not in the file system but inside the files themselves: in the title block of the schematic, in the version field of the layout file, in change lists. Names deceive, too. A folder called "REV1839" sounds like a board revision — but the number denoted the build of the layout program the design had been saved with. And several files of the same name in different folders had different contents: whoever discards the original path while sorting silently overwrites one state with another.
Once everything is sorted, we count whether it all arrived. Version control setups often exclude output folders such as "Gerber" or "Plot" on purpose — so when legacy is imported, files in folders of that name simply vanish, without any warning.
When the editable sources are missing
For one circuit board, no schematic and no layout could be edited any more — only the manufacturing data set from a different layout program remained: Gerber files, drill file, plots. For another, the header of a file showed that the layout had been stored on a network drive of the previous development PC — it is not part of what was handed over. In both cases, the manufacturing data is now the only technical record of the board. It is not tidied away but secured, even though manufacturing data does not normally belong with the design sources. If the board ever has to be re-made, that is where the work starts.
Where the documents contradict each other, what was actually manufactured counts. On one assembly, layout and bill of materials named different inductors for the same position; production had followed the bill of materials. Findings like this are recorded and clarified with the customer — not quietly "corrected" in one direction.
With firmware, the decisive question is not whether source code was handed over, but whether it is complete. Only a build of our own shows that: does the code build, and does the result behave on the device like the firmware used in production today? Until that is proven, the shipped file remains the reference. If the source code is missing entirely, this usually means rewriting against the documented behaviour of the running device — how we approach that is described on our page about taking over orphaned development and in the post on taking over someone else's firmware.
The character set: when one byte becomes two
Older firmware sources are often not stored in UTF-8 but in Windows-1252, with Windows line endings. Whatever is written there as text ends up as bytes on the display. Modern editors and tools assume UTF-8 and like to rewrite a file silently on saving — and then exactly these bytes change:
| Character | Windows-1252 | UTF-8 |
|---|---|---|
| ° (degree) | B0 | C2 B0 |
| ü | FC | C3 BC |
| € | 80 | E2 82 AC |
A display that renders the bytes as Windows-1252 then shows "25 °C" instead of "25 °C"; fixed-width texts shift, menu lines overflow. As a rule, compiling raises no error.
Our rule for such legacy: the sources stay in the character set they were created in — including the change documentation that sits next to the code. Changes are made byte by byte, and after every change we check that only the intended bytes have changed and that every line still ends with the Windows line ending.
Variants: one change, several devices
Firmware maintained across several device variants is full of conditional compilation: depending on the variant, a different part of the code is built. When something changes for one variant, there has to be proof that the others are not affected. To get it, we let the compiler's preprocessor resolve the code of every uninvolved variant and compare the result with the unchanged state — it must be identical. "0 errors" on building is no proof; the comparison is.
Every firmware file we ship carries variant, version and date in its name, and the version history records which source state it was built from. Once shipped, a state is never moved again. That way, even years later, we can answer which code is running on a device — the question on which legacy otherwise founders.
The service software belongs to the device, too
Nobody would write service software in Visual Basic 6 like that today. But as long as it is in use in the field, it is part of the product — and it is maintained like the firmware, instead of being rewritten at the first opportunity. A rewrite is a project of its own, with risks of its own. It pays off when the old software can no longer be kept going, not merely because it is old.
And in your case?
Could the firmware of your oldest device that is still being manufactured be built from its sources today — and who would check? Write to us — we are curious which piece went missing first in your company.
Transparency note: This article was written with the help of artificial intelligence and reviewed by the author before publication. The review applies to the German original; this English version is a translation.