Rebuild, redesign or extend? How to decide what to do with an existing system

When a system feels slow, outdated or hard to change, the first instinct is often to start over. Sometimes that is right. But a working system also contains years of decisions, data and small fixes that nobody wrote down. Rebuilding throws those away along with the problems. A short, honest review usually shows that the answer is more nuanced.

Three options, not two

• Improve: keep the system and fix specific problems — design, performance, a missing feature, an integration.
• Refactor: keep what the system does, but restructure parts of the code or infrastructure so it becomes easier and safer to change.
• Rebuild: replace the system, or a clearly bounded part of it, with something new.

Most good outcomes combine these. A new design on top of a refactored core, or one module rebuilt while the rest is improved, is often cheaper and less risky than a full rewrite.

What to review first

A useful review looks at four areas. Code: is it readable, tested, and built on maintained technologies? Infrastructure: where does it run, how is it deployed, and how hard is it to recover from a failure? Data: how clean is it, and can it be exported and migrated? Users: what do people actually rely on every day, including the workarounds they have invented?

Signs that improving is enough

• The main complaints are visual or about specific screens
• The underlying technology is still supported and secure
• Changes are possible, even if slower than you would like
• The data model still matches how the business works

Signs that a rebuild deserves serious consideration

• Core dependencies are no longer maintained or receive no security updates
• Every small change breaks something unrelated
• Nobody can deploy or run it confidently
• The business has changed so much that the data model no longer fits

If you rebuild, protect what already works

List the features people depend on before writing new code, including the unglamorous ones: exports, email notifications, admin shortcuts. Plan the data migration as a project of its own. For websites, keep or redirect existing URLs so that visitors and search engines are not sent to dead pages. Where possible, replace the system in stages rather than in one large switch.

Redesign is not only visual

A redesign is a good moment to look at structure: which pages people actually visit, which questions they ask before contacting you, which forms they abandon. Changing colours and fonts on an unclear structure gives you a newer-looking version of the same problems.

If you are unsure which path fits your system, describe what exists and what is not working. A review of the code, infrastructure and data is the first step we take with existing systems, and it leads to a recommendation rather than an assumption.