Expert knowledge for digital decisions

Can an existing system be taken over and further developed?

Short answer

In general, yes. The usual approach begins with an inventory: reviewing the code, checking dependencies, assessing security. Stabilization follows, without immediate restructuring. A complete rebuild is the exception – it seems attractive but often underestimates how much invisible knowledge is embedded in the old system.

The usual process

1. Inventory

What code is available, which dependencies are outdated, are there tests, how is it delivered, where is the data? This review takes a few days and answers the fundamental question: take over or rebuild.

2. Stabilization

First, address what carries risk: outdated dependencies with known gaps, lack of backups, unprotected access. No new features yet.

3. Securing

Automated tests for the most important processes – to ensure that later changes do not inadvertently break something.

4. Further development

Only now introduce new features, gradually.

Why rebuilding is usually the worse choice

An evolved system may appear messy from the outside. A large part of this mess consists of special cases that have arisen over the years and have been resolved. Those who rebuild do not account for these special cases – and encounter them all again, individually, in production.

Additionally: During the rebuild, the old system must continue to run and be maintained. You end up paying double.

When a rebuild is indeed the right choice

The technology used is no longer maintained and cannot be updated
There is no source code left
The business model fundamentally no longer fits the business
The effort for each small change is demonstrably higher than a rebuild

These are four clear criteria. "The code is ugly" is not one of them.

Key facts

Order: Review → stabilize → secure → expand
Rebuild only if: dead technology, missing code, or incorrect business model
Underestimated: The special cases that are resolved in the old system