When legacy industrial software becomes hard to maintain, the first question is usually whether to refactor or rewrite it. Refactoring improves the structure of existing code without changing what it does. Rewriting replaces it with new software built from the same requirements. Both can work; choosing wrong is one of the most expensive mistakes in industrial software modernization. This article explains the trade-offs and how to decide.
Refactoring vs rewriting at a glance
| Refactor | Rewrite | |
|---|---|---|
| What changes | Code structure, readability and organization | Everything: architecture, code and often platform |
| What stays | Behavior and most of the logic | Only the requirements, recovered from the old system |
| Risk | Lower; changes are small and testable | Higher; hidden behavior is easy to lose |
| Time to first benefit | Short; improvements ship in steps | Long; little value until cutover |
| Best for | Sound logic in messy code | Unsalvageable code or a dead-end platform |
Why rewrites are riskier than they look
Old industrial code is often ugly for a reason. Over years it absorbs fixes for timing problems, hardware quirks, unusual parts and operator habits that nobody wrote down. A rewrite that starts from a clean sheet tends to lose some of those fixes, and the problems return on the production floor. Rewrites also deliver nothing until cutover, so a long project carries the full risk to the end.
When to refactor
- The system works and production depends on it
- The logic is correct but the code is hard to read, change or test
- The platform can stay, or can be updated in place
- The team needs improvements now, not in a year
- Downtime for a big switchover is hard to schedule
Good refactoring works in small steps: add tests or recorded test cases around the behavior, restructure one part, verify, repeat. In LabVIEW applications this often means separating the user interface from hardware code, replacing tangled loops with a clear state machine or message-based architecture, and putting instrument access behind proper drivers.
When to rewrite
- The code cannot be understood or safely changed, even with effort
- The language, runtime or hardware platform is a dead end
- The system must do substantially more than it was designed for
- The original design is fundamentally wrong for the job
- Refactoring would touch nearly every line anyway
A successful rewrite starts by recovering requirements from the old system, not from memory. When documentation is missing, that means reverse engineering the existing software: reading what code exists, tracing signals and recording how the system actually behaves. Those recordings then become the acceptance tests for the new software.
The middle path: re-platform and refactor
Many industrial projects are neither pure refactor nor pure rewrite. A common pattern is to re-platform the hardware layer, replacing an obsolete DAQ card or PC, while refactoring the application around a new hardware abstraction layer. The logic that works stays; the parts that cause the trouble get replaced. See equipment obsolescence.
A simple decision checklist
Frequently asked questions
Refactoring restructures existing code without changing its behavior. Rewriting replaces the software with new code built from the same requirements, usually with a new architecture and often a new platform.
Refactor when the logic works and the code can be understood; rewrite when it cannot be safely changed, the platform is a dead end, or the system must do much more. Many industrial projects combine both.
They often lose undocumented fixes hidden in the old code, deliver nothing until cutover, and take longer than planned. Recovering requirements from the existing system and testing against its recorded behavior reduces that risk.
Yes. Typical steps are separating the user interface from hardware code, moving to a clear state machine or message-based architecture, and putting instrument access behind proper drivers, verifying behavior at each step.
