TL;DR: To keep endpoint automation running when an admin leaves, make a list of jobs, files, connections, and alerts tied to the departing admin. Transfer dependencies to supported identities and shared infrastructure, then have another authorized admin verify scheduled execution and endpoint results. Revoke the admin's access at the agreed cutoff.
You may never get over the traumatic experience of losing an exceptional sysadmin. Some scheduled tasks, scripts, credentials, and integrations might depend on their account or workstation, so trouble starts when those go away. Luckily for you, this IT automation handover checklist will help keep workflows running smoother than the notice period ever did.
Which automation dependencies should you check before an admin leaves?
During sysadmin offboarding, look for anything tied to the departing admin's account or workstation, starting with jobs behind time-sensitive work.
Because automations run behind the scenes, a failure after an admin leaves might go unnoticed for weeks. Some jobs keep working at first, which makes the eventual break seem unrelated to their departure. Then, on a hectic Monday, new hires wait on remote-access software, half the laptops still need the weekend update, and the failure alert sits in an inbox nobody reads anymore.
Account dependencies
Start with integrations wired to the admin's own login. Inventory scheduled-task identities, cloud connections, and API keys. For each credential, record who issued it, where it's used, and how to revoke it. Existing tokens and application sessions can remain valid for a period after revocation begins. Ask each connected app or service what else revoking their access takes and when it takes effect.
Ownership comes next. In Power Automate, a shared flow can continue with another active owner while actions using the former owner's connections can fail. Move approval recipients and operational alerts to a monitored team destination.
File and runtime dependencies
Sysadmins write custom Bash, Python, and PowerShell scripts to automate daily work, and those scripts can end up in a Documents folder on one laptop. Look for scripts and installers in personal folders or workstation-hosted shares; references to the admin's username and profile paths in job definitions and scripts can help you trace them.
A task pointing to C:\Users\Admin\Documents\Scripts\DeployApps.ps1 needs a stable path before anyone removes that profile. The dependency inventory should also cover its host, working directory, runtimes or modules, configuration files, permissions, and any environment variables tied to the admin's account.
A PowerShell module installed with Install-Module -Scope CurrentUser may be missing from a new identity's module search path. Note the module version and installation scope in the handover notes.
For a PDQ environment, use the guide to inheriting PDQ to walk through packages, schedules, target groups, and deployment history. That helps to establish what's already running before changing it.
How do you transfer control without interrupting automation?
Save the current scripts, package settings, and configuration before changing them, and test deployment changes on a small device group. A missing module costs less to find on 10 devices than on 1,000.
Use a supported execution identity
Handing a job to another teammate's personal account re-creates the dependency you're trying to remove. Where the platform supports it, give each unattended job a nonhuman identity (a service account, a managed identity, or a service principal) with only the permissions it needs. This gives your team a setup to maintain through future staffing changes.
Power Automate supports service principal ownership, subject to connection and licensing requirements. For flows that still use a user connection, document the exception and have a teammate show they can edit the flow and replace its connections through the platform's supported process. And yes, its licensing has to stay covered too.
PDQ's package execution settings default Windows install and script steps to Local System, which means the execution identity can differ from the admin's console login. External scripts and API connections still need their own assessment.
Then move the job itself by doing the following:
Copy the job's files from the old workstation to approved shared storage.
Recreate workstation-hosted jobs on the new host, with their schedules and triggers.
Update paths and install any required runtimes or modules.
Rebuild the environment settings the job relies on, then test its access to scripts, installers, and input sources under the execution identity.
Disable the original job at the planned cutover.
Replace credentials in a controlled sequence
Where overlapping credentials are supported, replace them in this order:
Create the replacement under the intended identity and store it in the approved secret manager, such as Amazon Web Services (AWS) Secrets Manager, Azure Key Vault, or HashiCorp Vault.
Update each consumer and watch it authenticate with the new credential.
Revoke the old credential after the new one works.
The timing depends on when each job reads its credentials; some jobs only pick up the new credential after a restart or connection refresh.
Older PDQ API keys created before scoped keys were introduced retain full access. Audit those keys during the handover. Save every new key as you create it, since it's displayed only once. For a PDQ Zapier connection using an API key, create a new key, reconnect Zapier, validate the Zaps, then revoke the old key. If the Zapier connection uses OAuth sign-in instead of an API key, it’s tied to the PDQ user who authorized it. Have a remaining admin replace the connection in Zapier using their own PDQ credentials before the departing admin’s access is removed.
Keep the employee's access-removal deadline fixed. If a dependency can't be transferred in time, plan a controlled interruption and warn the people it affects. Just make sure your recovery plan doesn't involve texting (or calling or emailing) the admin who already left.
Assign ownership and document the job
An automation that only one person understands is a single point of failure. Name an accountable owner and a backup for every workflow.
Give each teammate an individual account with permissions suited to their responsibilities. In PDQ, role-based access control reserves Manage teammates for the Admin role, and custom roles can grant permissions such as Manage automations. Confirm that at least one other appropriate teammate has the Admin role before the exit date. If not, assign it as part of the handover. If the departing admin is also the account Owner in the PDQ Portal, transfer ownership to another admin, since the billing Owner is separate from the Admin role.
Update the shared documentation for every job with:
The business purpose, trigger, target devices, and expected result.
Upstream services or data sources and where the job writes its output.
The final execution host and identity, working directory, file locations, runtimes and modules, and environment settings.
Permissions and secret references, with the secrets themselves stored in the approved secret manager.
Alert and approval routing, pause steps, and the recovery procedure.
How do you verify the IT automation handover worked?
Your IT automation handover worked when a second authorized admin can maintain, troubleshoot, and receive alerts for every job using only their own login and the shared documentation, while each job runs under its intended execution identity. Also, have them save evidence as they go.
Finish migration testing before the access cut-off where possible, and continue watching scheduled runs afterward.
Work through this checklist with the new admin:
Confirm independent access. They can maintain and troubleshoot the workflow, and the execution identity reaches its inputs, scripts, installers, and output destinations from the intended host.
Observe the actual trigger. Watch the production schedule or relevant event start the job without manual intervention. If you can, run it with the old workstation powered off and the departing admin's session signed out. Record the run and its target devices.
Inspect deployment results. In PDQ, open Deployments, note who or what started the run in Deployed by, and select View Output on the deployment's device results for package-step logs. PDQ's audit logs don't record automation runs; review automation activity through Deployments instead.
Check the resulting endpoint state. Compare inventory and deployment results for the intended version on the targeted devices, inspect any changed settings, and chase skipped or unfinished deployments.
Test the alert path. Trigger a controlled failure in a test scope, or send a sample notification if your tool supports it. The alert should reach the team destination, with someone named to respond. Reassign any approvals still waiting on someone who's gone.
Retire the old access. Do the account, session, and credential revocations by the agreed cutoff. Comb through job, application, and sign-in logs for missed runs, authentication errors, and continued use of the old account. Investigate remaining dependencies under an approved account.
Keep monthly, quarterly, and conditional jobs on the handover list until someone has verified the relevant run and its result.
PDQ gives your team role-based access, shared automations, and deployment history to build the next handover on. Start a PDQ trial to see how it fits your team's handover.
