Four routes through system change.

Track 01

Repair the weak link.

Use this path when the core system still earns its place but one component is unreliable, slow, insecure, or blocking the work. We isolate the failing route, reproduce the problem, document dependencies, and define the smallest safe repair.

• Best starting evidence: error examples, affected users, recent changes, logs, and a working comparison case.
• Decision gate: the failure has a bounded cause and a repair will not deepen dependency on an unsustainable platform.
• Proof: the original failure no longer reproduces and adjacent routes pass regression checks.

Track 02

Connect the handoffs.

Use this path when the expensive part is re-keying, status chasing, inconsistent records, or invisible handoffs between tools. An integration is only useful if both systems’ responsibilities are clear. We map the source of truth, identifiers, update direction, error queue, retry rules, permissions, and reconciliation.

Track 03

Automate a repeatable route.

Use this path when a process is understood and frequent, but repetitive coordination consumes attention. The workflow should make decisions more visible—not hide an unstable process inside code. We separate deterministic steps from human judgement, preserve approval points, and design an exception route.

• Define the trigger, completion state, owner, and service expectation.
• List exceptions before writing the happy path.
• Keep an audit history and a manual recovery route.
• Measure an operational result, not simply the number of automated actions.

Track 04

Replace in stages.

Use this path when the existing technology is end-of-life, unsafe, unmaintainable, or no longer useful enough to repair. Replacement begins with discovery: data, roles, reports, integrations, hidden calculations, critical dates, and the institutional knowledge surrounding the system.

A responsible transition may introduce a read-only proof, move one workflow, reconcile a limited data set, run old and new routes in parallel, and only then retire a component. The rollback point and decision owner must be explicit at every stage.