Good technical work often begins before anything is changed.
I begin by understanding how the system behaves, what it depends on, and which constraint actually matters. That prevents an immediate symptom from becoming the definition of the problem.
Understand the system
The first pass is investigative: observe behavior, map dependencies, identify assumptions, and separate evidence from explanation. Existing documentation is useful, but the running system has the final word.
Name the real constraint
Reliability, continuity, privacy, recovery time, maintainability, and limited attention lead to different decisions. Making the constraint explicit gives the work a standard against which choices can be judged.
Make the smallest useful change
A change should remove uncertainty or improve the system in a way that can be verified. I prefer a sequence of understandable changes over a large intervention whose effects are difficult to separate.
Verify before removing the old path
Migrations and integrations need explicit checks. The new path is tested, dependencies are confirmed, and rollback remains available until confidence is earned.
Leave the system easier for the next person
Documentation, naming, recovery notes, and clear boundaries are part of the work. A solution is not complete if it only makes sense to the person who implemented it.
Use the failure-sized recovery
Code rollback, content or configuration restoration, and full-system reconstruction solve different failures. Restore only as much of the system as the problem requires.