When someone leaves, make sure their software work can stay

The replacement has a login. The files have been shared. Then a scheduled report fails because its connection belonged to the person who left.

A software handover needs to cover access, ownership and the work that runs in the background. It is complete when the next responsible person can perform the essential tasks from their own account and the departing person's access has been removed at the agreed time.

This guide covers the operational handover. Follow your organization's employment, retention and security decisions; those determine who may access which material and when access must end. You do not need to settle those policies inside a spreadsheet checklist.

Build the list around work that must continue

Start with recurring responsibilities, then identify the systems behind them. Ask what happens daily, weekly and monthly, and what would fail if the person's account stopped working today.

Include obvious applications such as email, file storage, accounting and project management. Also check domain registration, website hosting, booking forms, shared calendars, billing contacts, reports, integrations and automations. A low-cost tool can hold an essential business process.

For each system, record:

• Its purpose and the business account or workspace involved.
• The administrator and next responsible person.
• Data, projects or assets owned by the departing account.
• Recurring work and connections that depend on that account.
• The handover test and any unresolved issue.

Keep passwords, recovery codes and API keys out of this register. Refer authorized colleagues to the organization's approved credential-management process. The checklist needs to tell them where responsibility sits, not become another place to leak secrets.

Ask for the last completed example of each responsibility

“What software do you use?” produces a list of applications. “Show me how last Monday's booking report was produced” reveals the spreadsheet, source account, scheduled job and person who receives it.

Walk through the last ordinary run and one recent exception. Look at the final output, then trace backward: where did its information come from, what caused it to run and whose account supplied the access? Include tasks that happen only at month-end or before a renewal. They are easy to miss in a handover organized around today's browser tabs.

For work that depends on email, record outstanding customer promises as well as mailbox access. The next coordinator needs to know which reply is due tomorrow, not merely how to open the inbox. Use the shared inbox handover method to transfer those conversations to someone who has accepted responsibility.

Give essential work priority over a perfect inventory. Start with the services whose interruption would stop customers booking, prevent the team delivering work or block access to other systems. The book-club subscription can wait until the booking export has an owner.

Separate access changes from data decisions

Sharing a folder may give somebody access without transferring ownership. Removing a paid seat, blocking sign-in and deleting an account may also have different effects. Read the provider's instructions for the actual account and service.

Microsoft's former-employee guidance treats blocking access, preserving mailbox content and giving another employee access to email or OneDrive data as distinct tasks. That is a useful checklist structure even when your business uses other products.

Google likewise explains which data to transfer when removing a Workspace user. In particular, its current guidance says to transfer owned secondary calendars before deleting the owner. Do not assume transferring Drive files covers the workshop calendar too.

At the agreed access cutoff, follow the approved process for blocking access even if some handover work remains. An authorized administrator can handle outstanding preservation and transfer tasks using the provider's supported process. Keeping a departing person's login active for convenience is a poor handover plan.

A worked example: the coordinator's four systems

The following company and handover are fictional.

A training business is replacing its operations coordinator. The team's first list contains a shared folder and the booking application. Walking through the coordinator's week reveals two more dependencies: a calendar they own and a weekly export connected through their personal work login.

The word appropriate matters. The successor should receive the access their role needs, with an administrator available for administrative tasks. Giving everyone the broadest possible role is not a substitute for working out what the job requires.

Trace the booking export all the way to its reader

In the fictional training business, the weekly export has five links:

Booking records → saved report → authorized connection → scheduled run → shared destination.

The successor can have access to the first and last links while the middle still depends on the departing coordinator. Opening the booking app and output folder therefore proves only part of the handover.

A “successful” run that exports zero rows is worth investigating if the source contains bookings for that period. Compare expected identifiers, dates and counts with the source. If a report deliberately excludes canceled bookings, preserve that filter in the handover notes so the successor can explain a difference instead of treating every difference as a fault.

This is also a useful buying question for future tools: can the team maintain the connection without depending on a particular employee's continuing membership? The automation comparison examines who inherits setup and maintenance. Ask the provider about the supported ownership model for the plan you actually use.

Check the transfer, including what it leaves out

Before deleting an account, establish which information must be kept, who is allowed to receive it and how the service handles transfer. Ask the person responsible for retention decisions when the answer is unclear.

Transfers have boundaries. Google's Drive ownership-transfer instructions say that items in Trash are not transferred, and that files owned by other people in a folder hierarchy may need separate handling. A folder arriving in the new owner's Drive is a reason to check its contents, not to assume every dependency moved with it.

For exports, open a sample in the tool the successor will use. Check dates, identifiers, attachments and any information the normal workflow depends on. An export can be readable while omitting comments, relationships or files stored elsewhere; check what that particular product includes.

Keep a brief record of the transfer or export, its date, destination, responsible person and unresolved gaps. Store it where the team can find it after the original account is gone.

Sequence the work around the agreed cutoff

For a planned departure, prepare the replacement access and inspect important transfers before the cutoff where authorized. Test from the successor's account while there is still time to ask about the process. This should not change when the organization's access decision takes effect.

At the cutoff, the administrator carries out the agreed access changes and records what was completed. Outstanding transfer work stays visible for authorized administrators to finish. A transfer problem is a reason to use the provider's recovery or preservation process, not to hand the successor the former employee's login.

Afterward, verify the first important recurring outputs. A manual test can check the report contents and destination; the next scheduled run checks that the trigger and connection work together. If the job is monthly, assign a person and date to that later check. “Waiting for the first scheduled run” is a precise open item, rather than a reason to label the whole handover complete.

An unexpected departure starts from a different position. The administrator should preserve and recover information through authorized service controls, establish essential service continuity and record what remains unknown. Do not make contact with the former employee a prerequisite for following the agreed access cutoff. Where the provider cannot transfer an asset, document the replacement or reconstruction needed and who accepts the temporary arrangement.

Inspect the quiet connections

Ask about scheduled reports, mail rules, form notifications, connected spreadsheets and tools that sign in through another account. Record who owns the connection and how the team will know it has failed.

Have the responsible administrator replace or revoke credentials using the service's supported controls. Check the process after the change. Revoking a person's access and keeping an unattended job working are separate checks, even when they happen in the same application.

For businesses using GitHub, its member-removal guidance explains that the removal process depends on how membership is managed and that a removed member may retain local repository copies. Do not treat account removal as proof that every copy of business information has disappeared.

Finish with a short working demonstration

Ask the successor to perform one representative task in each essential system from their own authorized account. For the fictional training business, that means updating a workshop pack, managing an event, checking a booking setting and obtaining the weekly export.

Record failures as open work with an owner and a date. Keep the handover open until the essential tasks are verified or the business has explicitly accepted a documented alternative. Schedule a check after the next important recurring run; a monthly process cannot be proved by successfully opening its settings page.

Write the completion record at the level of the work. “Successor can access Drive” is weak evidence. “Successor opened and edited the current workshop pack from their own account; the booking export test contained the expected workshop records; Monday's scheduled run still needs checking” is a useful state of affairs. It preserves the unfinished part instead of burying it under a general tick.

Then ask the successor to update the procedure for that work with any step they had to discover during the demonstration. A handover is an unusually good test of documentation: it reveals which instructions only worked because one person already knew the answer.

Use the software handover checklist to collect those details. The strongest completion note is specific: who now owns the work, what they successfully did and what still needs attention.