How do you inventory and control years of accumulated PowerShell automation?

A central automation platform or RMM tool can prevent this problem from growing. Keep scripts off individual servers, run them from a protected host, control permissions there, and provide an audit trail for scheduled and manually triggered jobs. Jenkins or a similar system works well when its configuration, pipelines, modules, and scripts are all stored as code.

I’d start with an environment-wide discovery pass: enumerate scheduled tasks, services, script files, service-account usage, and PowerShell history where available. Then inspect the scripts for database, API, file-share, and remote-server references. Build a simple inventory with the script location, schedule, credentials, dependencies, owner, business purpose, and last observed execution. Even an initially incomplete spreadsheet is better than relying on memory.

After discovery, consolidate the useful automation onto a small number of controlled execution hosts. Remove duplicate scripts, replace obsolete modules with supported PowerShell and Graph equivalents, eliminate unnecessary manual parameters, and review the remaining jobs on a regular cycle. Tooling such as workflow automation or agents can replace many one-off scripts, but only after their actual purpose and impact are understood.

The biggest improvement is establishing a rule that anything used more than once—PowerShell, Python, Bash, SQL, or otherwise—must live in version control. Centralize execution through a job runner or automation host, and use scheduled task and service-account audits to find whatever is still running locally. For legacy systems, review each script and dependency individually; undocumented automation should be treated as a retirement candidate until someone proves it is needed.

In some inherited environments, the honest answer is that the automation is too tangled to preserve safely. If a script has no owner, documentation, or evidence of use, isolate it and monitor for dependencies before deleting it. A staged disablement process—document, observe, disable, then retire—usually gives you a safer path than trying to understand every old script perfectly.