An orphaned automation is a workflow still running in production after the person who built it left, with no documentation, no handover, and often no record of which accounts and credentials it depends on.
It usually keeps working for a while. The problem arrives the first time it needs to change, or the first time it breaks and nobody knows where to look.
Fixed scope, fixed price, and a 100% money-back guarantee for 7 days after handover.
The contractor stopped replying, or the arrangement ended, or the person who understood it moved on. What is left is something the business genuinely depends on that nobody can open, explain, or safely turn off. Every week it keeps working makes it more load-bearing and less understood.
Where does it run — whose account, whose infrastructure, whose card. What credentials does it hold, and are any of them still tied to a person who has left. What does it actually touch, in and out, including anything it writes to a third party. And what happens if it is turned off — which is the question that tells you how urgent the rest are. Answering these four is the first hour of any handover, and you can start it before you hire anyone.
The instinct is to work out what the automation does. The safer first move is to establish who can currently reach it. Credentials belonging to a departed person, a shared login nobody has rotated, or an unauthenticated endpoint left open for convenience are all common and all more urgent than the logic. Rotate first, understand second — an automation you do not yet understand is still safer than one a former contractor can still reach.
Not everything inherited is worth keeping. Sometimes the honest answer is that the process changed and the automation has been quietly solving a problem you no longer have, in which case turning it off is the whole project. Where it is worth keeping, the work is to get it onto your own accounts, readable by somebody who is not us, and written down. We would rather tell you to retire something than sell you a rebuild you do not need.
Yes, and reading it costs nothing — bring us whatever you have and the audit covers the assessment. We will tell you what it does, what it depends on, what is risky about it, and whether it is worth keeping, documenting, or replacing. That written assessment is yours whether you hire us or not.
It depends where it lives. If it is on a platform under an account you control, access can usually be recovered. If it was built inside a contractor's own account or a platform you cannot export from, recovery may not be possible — in which case rebuilding it on your accounts is often faster than fighting for the original, and it solves the underlying problem rather than repeating it.
Three things, and you can require all of them in writing from any vendor. It runs on your accounts and credentials, not theirs. It is readable by somebody who did not build it — no proprietary format holding it hostage. And there is a written handover naming what it touches and how to turn it off. We ship all three by default, not as an upsell, because a client who cannot leave is not a client who trusts us.
Often rebuilding, which surprises people. A readable build with a clear problem is usually a quick fix. But an undocumented build in an unfamiliar structure can take longer to understand than to replace — and at the end of a repair you still own something nobody can read. We size both options during the free audit and give you the honest comparison, including when the answer is to do nothing.
Thirty minutes, no charge. You leave with a written list of what is worth automating, what is not, and roughly what each would cost — and that list is yours whether you hire us or not.