Social media client offboarding checklist: how to hand over accounts, content, and access

A client relationship can end on good terms and still leave behind a messy publishing setup: next week’s posts are scheduled, an evergreen queue is still running, source files live in an agency folder, and nobody has checked who controls account recovery.

Social media client offboarding is the process of transferring the agreed work, confirming the client’s ability to operate, and closing the outgoing team’s access and responsibilities in a controlled order.

The goal is not simply to send a folder and remove yourself. It is to leave no uncertainty about what will publish, who can manage it, and who handles the next question.

Use the checklist below whether the client is moving in-house, appointing another agency, or pausing social media work. It complements our client onboarding checklist, but focuses on the end of the engagement rather than a new team’s first month.

1. Agree on the handover boundary

Start with a short written handover brief. Record the final service date, the exact operational cutoff time and time zone, the client decision-maker, and the person taking over each workstream.

Be precise about what stops at the cutoff. Content creation, publishing, comment moderation, reporting, and emergency support may have different arrangements. Paid campaigns and lead handling need their own named owners if they were part of the engagement.

For example:

Scheduled publishing remains with the agency until [date, time, time zone]. The client takes over moderation at that time. The agreed final report covers activity through [date] and will be delivered on [date].

This is an operational summary to agree with the client, not a replacement for the contract. Resolve any disagreement about deliverables or service obligations before treating the handover as complete.

Work backward from the cutoff rather than leaving permissions until the last afternoon. For example, Google Business Profile places seven-day restrictions on some actions by newly added owners and managers, including primary-ownership changes. A newly accepted invitation may therefore be only the start of a transfer.

2. Inventory accounts and the systems behind them

List every managed account with its platform, handle, stable identifier where available, business owner, outgoing users, incoming users, and connected publishing tools.

Then look beyond the social profiles. Include the systems that can create posts or keep the client dependent on the agency: content libraries, link destinations, reporting tools, feed automations, integration workflows, and any related billing arrangements.

Use a handover register like this. The entries are examples to replace with the client’s actual setup.

Keep passwords, recovery codes, and API secrets out of this register. It should describe access and completion, not become a new repository of credentials.

3. Decide the future of every unpublished item

Review fixed scheduled posts, drafts, queued items, recurring series, and outstanding approval requests. Give each item a clear disposition: keep, transfer or rebuild, cancel, or hold for a decision.

Do not interpret silence as approval to keep publishing after the engagement ends.

In Postoria, approval requests can release posts immediately, at their scheduled time, or into a queue. That makes outstanding approvals part of the publishing audit, not just a list of unfinished comments.

Likewise, Postoria Queues supports recurring slots and recycling. Check the queue itself, not only the next visible publication.

When content is moving to another setup, agree on the new schedule before disabling the old route, then check that only the intended route remains active. Use a documented test or dry review that the client approves; do not publish a surprise test on a live brand account.

This article does not assume a one-click transfer between tools or workspaces. Verify supported export and migration options before promising them. Our social media migration checklist covers the technical move in more detail.

4. Audit the triggers that can create new content

An empty calendar is not the end of the audit. Look for upstream workflows that are intended to create or publish content: RSS feeds, website updates, product feeds, webhook integrations, API jobs, and connected automation services.

For each workflow, record what starts it, which accounts it affects, who owns it, and what should happen after the cutoff.

If it will continue, have the receiving owner validate the configuration and required credentials. If it will stop, disable the agreed trigger and inspect any queued or pending work. Also check delayed follow-up actions, such as comments or cross-platform copies, where the setup uses them.

Be careful with shared infrastructure. Do not revoke a credential used by several clients simply because one engagement is ending. Identify its scope, arrange an appropriate replacement, and test unaffected workflows before making a broader change.

The same principle applies to subscriptions: end the client-specific arrangement that was agreed, not an agency-wide service that other projects still need.

5. Deliver files that the client can actually use

A useful handover folder distinguishes finished assets from editable sources and clearly labels work that has not been approved.

A small project might use this structure:

client-handover/
  01-readme-and-handover-register/
  02-brand-guidelines-and-templates/
  03-approved-media-and-captions/
  04-editable-source-files/
  05-calendar-drafts-and-open-decisions/
  06-reports-and-raw-exports/
  07-permissions-and-usage-notes/

Include the material covered by your agreement: finished images and videos, relevant editable files, caption documents, content plans, reusable templates, and instructions for any specialized workflow.

Document restrictions rather than hiding them. Identify assets whose continued use depends on a license, subscription, creator permission, or separate client purchase. Do not assume that transferring a file also transfers every right associated with it.

For important assets, ask the recipient to open the files from their own account and storage location. Check that linked media and fonts are available as permitted, that videos play, and that the folder does not depend on an agency share that will be removed at closure.

Avoid exporting other clients’ files or unnecessary private messages into the package. Share the agreed material with the authorized recipients, using access-controlled delivery rather than a publicly accessible folder.

6. Export reporting before removing connections

Deliver a final report that explains the period covered, the objectives, the results, and the decisions the next team should understand. Keep the underlying exports alongside the summary where available.

Useful context includes the accounts included, reporting time zone, metric definitions, paid versus organic scope, known data gaps, and the capture date. Explain unfinished tests without presenting them as proven conclusions.

Postoria Analytics supports CSV exports from its Posts and Accounts views using the active filters. Post-level reporting covers content published through Postoria; account reporting covers supported connected-account metrics. Availability varies by network and permissions, so preserve missing values as missing rather than converting them to zero.

Check that an analytics export actually contains what you need. It is not automatically a complete, editable backup of drafts, media, approvals, and scheduled content. Package those separately.

A concise handover report can end with three decisions: what to continue, what to reconsider, and what has not yet been tested. Our client reporting guide provides a broader structure.

7. Validate client control before removing your access

Ask the receiving owner to confirm access using their own account, rather than relying on a screenshot of an invitation you sent.

Check the ability to perform the required work: manage content, see appropriate settings, access reports, and connect the chosen publishing tools. Review recovery arrangements with the client without collecting their private recovery codes.

For example, YouTube channel permissions let people work on a channel without sharing the owner’s Google Account password. However, YouTube lists API access among the capabilities not supported for delegated channel users. Being able to edit in Studio does not by itself prove that the incoming person can authorize a publishing integration.

After the agreed validation and cutover, remove the outgoing people’s roles and partner access, disconnect retired tools, and handle any shared credentials that need changing. Limit each action to the client and scope being offboarded.

For Google-connected tools, follow Google’s linked-app access review. Removing an app’s access can affect features that depend on it, so distinguish a retired connection from one the client intends to keep.

Record the action and the time. Do not claim access has been removed until the relevant change has actually been checked.

8. Close with acceptance and named exceptions

Ask the client to confirm that the agreed accounts and files are accessible and that the future publishing arrangement is understood. Keep any exceptions visible with an owner, a next step, and a target date.

An unresolved ownership transfer is an open item, not something to hide behind “handover complete.” Equally, avoid an indefinite “contact us anytime” promise if the agreement provides only a defined support period.

Agree what copies the agency will retain, who can access them, and the intended deletion or review dates under the applicable arrangements. Do not erase the only usable copy before the receiving team has verified delivery.

Final handover email template

Replace the bracketed fields and include only statements that are true at the time of sending.

Subject: [Client name] social media handover and next steps

Hi [Name],

The agreed handover materials are available in [secure folder or delivery location]. The handover register lists the accounts, content, reports, access changes, and any remaining actions.

Our agreed publishing and moderation cutoff is [date, time, time zone]. From that point, [named owner or team] will manage [specific responsibilities]. Future scheduled posts and recurring content will [continue under the agreed owner / stop / move to the new setup], as recorded in the register.

Please confirm that you can access the accounts and open the delivered files. The remaining items are [item, owner, next step, and target date], or there are no outstanding items.

The final report covers [period]. The agreed handover support arrangement is [scope and end date]. Access already removed is recorded in the register; any pending removals are listed with their planned timing.

Thank you for working with us.

Best, [Name]

Client offboarding checklist

• Scope, cutoff time, time zone, and receiving owners are agreed.
• Every scheduled post, draft, queue, recurring series, and approval has a decision.
• Upstream automations and pending follow-up actions have been checked.
• The client can operate the required accounts and publishing connections.
• Agreed assets are delivered, opened, and accompanied by usage notes.
• Reporting and relevant exports are saved with dates and definitions.
• Duplicate publishing routes and retired client-specific integrations are resolved.
• Outgoing access changes are completed and recorded where agreed.
• Retention arrangements, remaining actions, and support boundaries are documented.
• The client has confirmed receipt and understands what happens next.

A clean handover leaves no hidden publisher

Good offboarding preserves continuity without leaving the old team responsible for an unattended workflow.

Before closing the project, make sure the client can answer four questions: what will publish next, where the usable files are, who controls the accounts, and who owns every unfinished action. When those answers are clear and verified, the handover is much more than a goodbye email.