Inheriting someone else’s automation — audit, rebuild, or start again?

Audit it first, then decide component by component: retain or refactor what is correct, supportable, and testable; rebuild what has clear requirements but an unsuitable implementation; replace or retire what no longer serves the business. If the build poses an immediate operational or security risk, stabilize it before attempting either a repair or a rebuild. This component-by-component approach follows modernization guidance that treats retain, retire, replace, refactor, rearchitect, and rebuild as separate choices rather than one decision for an entire system (Microsoft; AWS).

Do you need to understand the old build before replacing it?

Yes. A confusing build is not, by itself, evidence that starting again will be cheaper.

The undocumented automation may be the only complete record of what the business currently does. It can contain decision rules, exceptions, integrations, timing assumptions, and manual workarounds that nobody remembers until they disappear. Replacement work therefore includes requirements recovery, not just new implementation. Guidance on incremental replacement emphasizes learning from existing behavior instead of assuming that the old implementation can be treated as a complete written specification (Martin Fowler).

There is a documented warning at a much larger scale. The FBI’s Virtual Case File replacement effort was terminated after three years and USD 170 million of development, as reported in March 2005 by the U.S. Department of Justice Office of the Inspector General. This was a large federal procurement, not a benchmark for a small-business automation. It is relevant only as a caution about rebuilding while requirements and governance remain weak (DOJ OIG).

The opposite mistake is preserving everything because replacement feels risky. An independent assessment of that same FBI implementation could not establish that its architecture, operating concept, and requirements were correct and complete. It concluded that remediation would require substantial work and recommended abandoning the implementation in favor of a commercial-product-based approach (independent assessment; DOJ OIG report). Sometimes starting again is the sound choice. The audit is what distinguishes that case from an emotional reaction to unfamiliar work.

What should the audit establish?

The audit should establish what the automation is meant to do, what it actually does, who controls it, what depends on it, how it fails, and whether it can be changed safely. Technical inspection alone cannot confirm the required business behavior. That requires users, real transaction samples, support records, and observed manual workarounds.

The result should not be a loose list of defects. It should include an as-is map, an ownership and credential register, a dependency inventory, risk-ranked findings, behavioral tests, a recovery plan, option estimates, and a written recommendation for each component: leave, stabilize, refactor, rebuild, replace, or retire. That form of deliverable combines system inventory and configuration controls with explicit business outcomes and modernization choices (NIST; GAO; Microsoft).

What belongs on the audit checklist?

What is the automation supposed to accomplish?

• Name the business owner and the people who currently use or depend on it.
• Write down the outcome it is supposed to produce.
• Record its triggers, inputs, outputs, decision rules, exceptions, manual interventions, failure consequences, and service expectations.
• Separate required behavior from behavior that merely happens because of the old implementation.
• Validate the description against users and production evidence rather than treating the build itself as a complete specification (Martin Fowler; GAO).

What components and dependencies exist?

• List every workflow, script, scheduled job, webhook, application, API, database, spreadsheet, queue, file location, library, runtime, hosting resource, and human handoff.
• For each item, record its owner, version, location, environment, upstream callers, and downstream consumers.
• Check execution evidence for dependencies that diagrams and former staff recollections missed.

NIST configuration and inventory controls call for an accurate inventory of system components together with accountability information such as owners and versions. OWASP’s dependency guidance also supports mapping relationships rather than recording components as an unconnected list (NIST; OWASP).

Who owns the accounts and credentials?

• Confirm business control of the platform tenant, source repository, hosting, domains, databases, billing accounts, service accounts, API applications, encryption keys, and recovery channels.
• Identify anything tied to a personal address or a former employee or contractor.
• Record each permission and reduce it to the minimum required.
• Locate hard-coded passwords, tokens, certificates, webhook secrets, and API keys.
• Determine what uses each secret, then check its scope, expiration, rotation history, and possible exposure in logs or repositories.

Do not revoke or rotate credentials merely because they look unsafe. First identify their dependencies, secure business ownership, and prepare rollback. OWASP recommends auditing secret use and administrative changes, assigning minimum privileges, and rotating secrets under a managed process (OWASP).

What does production evidence show?

• Inspect execution history, timestamps, transaction volumes, latency, retries, duplicate processing, authentication failures, rate-limit failures, timeouts, and partial completions.
• Record manual corrections and compare them with the automation’s reported successes.
• Look for dormant workflows, unexpected callers, and downstream consumers that are absent from documentation.

Logs and run histories can reveal actual use and undocumented dependencies. Their availability and retention will depend on the platforms involved, so the audit must check current vendor documentation for each named product rather than assume that every system keeps the same evidence (AWS; NIST).

How does data move through the process?

• Document every source, destination, field mapping, transformation, and system of record.
• Record retention rules, deletion paths, and reconciliation methods.
• Check workflow definitions, logs, and error messages for sensitive information.
• Confirm what happens with duplicate events, late events, malformed records, and partial writes.

This work determines whether a component can be changed without losing, duplicating, or exposing data. NIST controls address information flow, retention, configuration, logging, and recovery, while CISA guidance calls for protecting credentials and sensitive material throughout software delivery and operation (NIST; CISA).

Can the build be reproduced and tested?

• Confirm that workflows, code, configuration, and documentation can be exported and backed up.
• Determine whether a second person can reproduce the build from those materials.
• Separate development, test, and production environments where they exist.
• Identify configuration stored only inside a vendor interface.
• Document deployment, approval, and rollback steps.
• Create representative tests for normal paths, critical rules, exceptions, retries, duplicates, permissions, and vendor failures.
• Record current outputs before changing anything so they can be used as behavioral checks.

Missing tests are not a minor documentation issue. They make it harder to tell whether a cleanup preserved required behavior. A 2022 exploratory survey of 107 industry developers found that 19% cited a lack of behavior-preserving tests as a challenge in large-scale refactoring. That was a coded survey response, not a measured defect rate, and the study covered software systems broader and generally larger than small-business automations (ACM survey paper).

Can the business recover if a change fails?

• Export and back up definitions, code, configuration, and documentation.
• Define acceptable recovery time and acceptable data loss.
• Test whether selected functions can actually be restored from the backup.
• Write rollback steps before changing production.
• For high-risk components, assess phased replacement or parallel operation instead of one irreversible cutover.

Parallel operation is not free. It can require temporary integrations, duplicate infrastructure, and synchronization between old and new systems. An audit of a U.S. Social Security Administration modernization reported that the agency rejected one incremental approach because synchronization would increase costs, although the auditors considered the selected alternative still riskier (audit report). Phasing is an option to cost, not an automatic answer.

When should you keep or refactor the existing automation?

Keep it or refactor selected components when the automation produces the required outcomes, its dependencies remain supportable, business access can be recovered, defects are reasonably isolated, and tests plus rollback can make the work safe. A stable, low-change automation may need documentation, ownership repair, and credential cleanup rather than a rebuild. AWS explicitly recognizes retaining a system as valid when there is no business justification for major modification (AWS).

Refactoring is not automatically the cheap choice. The following 2022 survey results concern large-scale software refactoring and should not be used to estimate a small automation. They show why the word refactor does not describe a predictable amount of work.

2022 survey finding	What it does and does not tell you
2 to 20,000 staff-days of reported effort	The range demonstrates substantial variation. It is unsuitable as an estimate for a specific inherited automation.
86.4% of reported effort estimates fell in the months-to-years range	The studied systems often contained hundreds of thousands or millions of lines of code, so they are not directly comparable to small automations.
19% of 107 respondents cited missing behavior-preserving tests as a challenge	This was a coded survey response, not a measured failure or defect rate.

All three figures come from the same exploratory industry study and should not be treated as a representative census of automation projects (ACM survey paper).

When should you rebuild or start again?

Rebuild a component when its required behavior can be stated and tested, but the inherited implementation is structurally unsuitable, insecure, unsupported, or prohibitively difficult to change. Replace it with a standard product when that product meets the real requirements. Retire it when the business process is no longer needed. These are separate outcomes, and one automation can contain components that warrant different treatments (Microsoft; AWS).

Do not approve a rebuild until the team can describe acceptance tests, data migration, cutover, rollback, and decommissioning. Microsoft’s modernization guidance treats major architectural change as costly and risky, with extensive testing and, for complex or critical changes, phased or parallel deployment (Microsoft).

If the business cannot yet state the required behavior, the next step is discovery or stabilization, not a clean-slate build. If the process itself is inconsistent or no longer useful, automation may be the wrong answer; that decision belongs in “When automation is the wrong answer.”

How do you compare untangling with redoing?

Compare total transition cost on both sides. There is no credible universal percentage or cost ratio at which untangling becomes more expensive than rebuilding. No platform-independent audit duration or price was established by the supplied research either. Those numbers require the actual workflow count, integrations, data sensitivity, account access, logging, and operating constraints.

Existing-build option	Rebuild option
Discovery and behavior recovery	Requirements and behavior recovery
Account and ownership recovery	New implementation
Remediation and dependency work	Data migration and integrations
Missing tests and documentation	Acceptance testing and parallel operation
Rollback preparation	Cutover and rollback preparation
Expected future maintenance	User and process change
Eventual retirement costs	Decommissioning the old build

Comparing cleanup hours with coding hours understates the rebuild because it leaves out migration, operational transition, and retirement. Federal application-rationalization guidance and modernization guidance both frame the decision around business outcomes, dependencies, transition work, and lifecycle cost rather than implementation effort alone (Application Rationalization Playbook; Microsoft; GAO).

“What does it actually cost to automate a process?” covers estimating the wider build. “What your manual process actually costs per year” covers the cost of leaving work manual. For platform selection, see “n8n vs Make vs Zapier — and why we don’t have a favourite.” For the longer ownership and subscription comparison, see “Build once or subscribe forever — the five-year maths.”

What decision should the audit produce?

The audit should produce one recommendation for each component:

• Leave: It works, remains supportable, and does not justify disruptive work.
• Stabilize: Reduce an urgent operational or security risk before making a larger change.
• Refactor: Preserve required behavior while repairing an implementation with isolated, testable problems.
• Rebuild: Recreate specified behavior because the current implementation is unsuitable.
• Replace: Move to a standard product that meets the real requirements.
• Retire: Stop a process or component that the business no longer needs.

The final recommendation should also identify dependencies, tests, transition steps, rollback, and expected ongoing maintenance. Ownership after handover is a separate subject covered in “What you actually own when the build is finished.” Operational response after launch belongs in “What happens when an automation breaks at 3am.”

Do not force one verdict onto the whole automation. Keep the components that are sound, rebuild the ones whose implementation is the problem, and remove the ones the business no longer needs.

Book the call. Bring the inherited build, the accounts you can access, and two or three real examples of what the process is expected to produce. The first step is to establish what is there before deciding what should survive.