The situation
A field-service operator had a job that ran every night, moving completed work orders from its field-service platform into its ERP for billing. The person who built it had left the business years earlier. The job mostly worked, nobody was entirely sure how, and when it failed overnight someone reran it in the morning and hoped. Everyone treated it as fragile, so nobody touched it, and the not-touching had become its own risk. The operator was depending nightly on a job it was afraid of.
The knowledge had left with its builder. What the job assumed, which edge cases it quietly handled, why one particular step existed at all, none of it had ever been written down, because it had lived in one person’s head and that head was no longer in the building. What remained was behaviour without explanation, and the systems around the job kept changing while it sat untouched, drifting further from anyone’s understanding of it.
What we built
We resisted the pull to rewrite it on day one and took it over in order instead, leaving behaviour changes for last.
The first step was making the job visible. We added logging so the team could see exactly what it did on each run, and alerting so a failure surfaced immediately instead of being discovered by a technician standing in front of an unbilled work order. Only once the job could be seen did we touch how it behaved.
Diagram: adopting an existing integration runs left to right through four stages. First observe it with logging and alerting. Second make it re-runnable, so it is safe to repeat. Third document it in runbooks. Fourth hand it over. Only after all four stages do we change what the integration actually does.
Next we brought it up to the standard a durable job should meet, so that running it again was safe: matching completed work orders on a stable key and writing them through create-or-update, the same discipline that keeps any sync from duplicating on a rerun. Once a rerun reconciled instead of duplicating, the nightly fear started to drain, because the worst everyday failure now had a safe response. We documented what the job did, what it assumed, how to run it and what to do for each known failure into runbooks, rebuilding in the open the knowledge that had left with its original builder. Only then, from an understood baseline rather than a guess, did we change its behaviour.
Watching and documenting a job we did not build was deliberately slower at the start than a rewrite would have been, and that patience was the point: a rewrite would have thrown away the edge cases the original quietly handled, the ones the business had forgotten it relied on until they broke.
The outcome
The nightly job stopped being a source of dread and became one the operator’s own team could run without us. It is visible, safe to rerun, and written down, so the people who now own it are not carrying the same fear their predecessor did. Billing for completed work no longer waits on someone rerunning a job they don’t understand and hoping.