Knowledge /
Legacy systems
Maintain, integrate or rebuild?
← Legacy systems
Rebuilding is rarely the first choice. A system that has run for years holds business rules written down nowhere else, and you do not buy those back in an off-the-shelf package. First see whether maintenance suffices, then whether an integration solves the bottleneck, and only then consider rebuilding.
The three routes
- Maintain
- Fixing faults, small extensions, having someone to call again. The cheapest route and often enough while the system does what it should.
- Integrate
- The system stays but starts talking to the rest. This usually solves the real bottleneck: data that is stuck.
- Rebuild
- Only worthwhile when requirements have genuinely changed or the platform really cannot be maintained. Expect to rediscover rules nobody remembers.
Five questions that decide it
- How many business rules are in there?
- The more unwritten logic, the more expensive a rebuild. This is by far the heaviest factor.
- Who can still get in?
- If nobody has the knowledge any more, taking over the code is the first step whichever route you choose afterwards.
- Can the system be integrated?
- A system with an interface or a readable database rarely needs replacing.
- How critical is it?
- An application the whole operation runs on is not replaced in one go but step by step.
- What prompted the question?
- A supplier shutting down calls for something different than a functional wish. Name that first.
In practice it is often a combination: maintenance first to get breathing room, then an integration for the biggest bottleneck, and only after that a gradual replacement if needed.
More on this →