Blog · August 7, 2026
Taking over someone else's firmware without breaking it
The controller of a running device series of KODRA GmbH was left without its engineer; we took over hardware and firmware and have supported the series ever since. The experience in one sentence: a takeover rarely fails for lack of knowledge — it fails through impatience.
The temptation to change things immediately
The occasion for a takeover is almost never curiosity but a pressing wish: a fault in the field, a discontinued component, a customer requirement. So the temptation is always the same — implement the wish right away, in a code base you do not yet understand. That is exactly how takeovers break: the change works, but it works in three places, two of which you did not know about.
Understand first — and leave the running device alone
Before anything is touched, the behaviour of the running device is documented: what it does at power-on, how it reacts to every input, what happens in the corner cases. One reference device stays untouched — it is the truth against which every later change of ours is measured.
Reading the code, one rule takes real self-restraint: leave the oddities in place. The strange timer, the seemingly duplicated check, the constant without a comment — the previous engineer usually had a reason, and it lived in his head, not in any document. Whoever tidies up before understanding deletes knowledge that exists nowhere else.
The first milestone of a takeover is therefore unspectacular: a build of our own that behaves on the device exactly like the series state. Until that succeeds, every change is a blind flight.
Then secure the state: everything goes under version control
The state that is manufactured today goes into Git, versioned — source code, schematics, layout, production documents. From this point on, what ships is reproducible, and no knowledge hangs on a single hard drive or in a single head any more. From here, every change carries a reasoned entry in the history: what, when, where — and why.
Only then change — and start small
The first change of our own is deliberately a small one: one whose effect can be overseen completely. It is there less for the device than for the process — it proves that building, flashing, testing and rolling back all work before the change everyone is waiting for is attempted. If the source code is missing entirely, a takeover usually means rewriting the firmware against the documented behaviour of the running device — and then the behaviour documentation from the beginning is the most important tool of all.
And in your case?
Is there a series running in your company whose firmware only one person still understands — or nobody at all? Write to us — we are curious how you secure that state today, before it becomes urgent.
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.