When to rebuild and when to repair

A full rebuild can look like the clearest way to improve an existing system. Yet the current code holds data relationships and integration behaviour. It also carries operating knowledge that may never have been written down. Rebuilding is not primarily a choice of new technology. It is the work of moving that knowledge without losing it.

Record what the current system knows

Examine the interface and business rules separately. Map the data model and external integrations. Include deployment and the way operators detect and handle failure.

When documentation is missing follow the real workflow. Record who uses each function and what stops when it fails. Identify where operating knowledge currently lives.

Separate age from the reason to change

Age alone is not a reason to replace a technology. Check whether security maintenance has ended. Ask whether a small change requires a full deployment and whether useful test boundaries can be created.

A newer system can still be difficult to change. Risk remains high when the design depends heavily on one provider or only one person understands its operation.

Make a choice for each component

Keep parts that are stable and rarely change. Wrap necessary parts that are difficult to modify directly. Replace parts with high failure or change cost. Retire functions that no longer have a current use.

These choices do not need to apply to the whole system at once. The interface, data model and integrations can follow different paths.

Define data authority and migration state

Decide which system is authoritative before moving data. Define how changes remain aligned while both systems are active. Keep a record that makes failed items discoverable.

Matching record counts is not enough. Compare critical relationships and financial or status totals. Review source samples and the failure list as well.

Design the period of coexistence

The existing and replacement systems may operate together for a time. Make it clear which users are served by each system. If data can change in both places then define how a conflict is handled.

Give each implicitly handled exception a named owner and a documented path. Logs, alerts and operator tools need to arrive with the critical function rather than after it.

Write the cutover and reversal conditions

Divide the transition by user group or function or data type. Give each unit an entry condition and a set of signals to observe. Write the stop condition and the reversal method before deployment.

Reversal is more than a general contingency. Identify the code and data point to restore. Define how changes created after cutover will be reconciled.

Finish with a system someone can own

Operational readiness is part of the transition. Hand over the status checks, incident path and change procedure. Make remaining constraints and deferred functions visible.

The next change is easier when the team can explain what stayed and why something else changed.