Pascal, old C, assembly: how we modernize unreadable code

When source code is missing and documentation never existed, modernization looks impossible. In practice, it’s often doable — if you work systematically and control risk.

1) Inventory: what do we actually have?

• hardware, interfaces, IO, fieldbuses
• firmware/software versions, dumps, backups
• operational workflows: what is critical vs optional?

2) Dynamic analysis: understand behavior

We instrument the system (logging, tracing, traffic capture) to observe states, timing, and failure modes — without disrupting production.

3) Static analysis: binaries & protocols

With tools like Ghidra/IDA we identify:

• state machines
• security-sensitive routines (auth, crypto, input handling)
• communication paths and checksums

4) Reconstruction: write a real specification

The key deliverable is often not code, but a testable spec: inputs/outputs, states, timing assumptions, and error behavior.

5) Modernize incrementally (testable + rollbackable)

• start with small, isolated components
• golden-data tests (same inputs → same outputs)
• staged rollouts with monitoring

Conclusion

“Unreadable legacy code” is rarely a hard blocker — it’s a risk that can be managed with method, tests, and instrumentation.