Software companies
Before layoffs: how to preserve Slack, GitHub and Google Workspace records
By SourceX Editorial · Updated
Short answer
To preserve data before layoffs, suspend departing accounts instead of deleting them, transfer ownership of files and repositories to company-controlled accounts, and confirm retention settings before anyone loses access. Deleting a Google Workspace user before transferring files, or leaving work repositories in personal GitHub accounts, can erase years of records that cannot be rebuilt later.
Key takeaways
- Suspend first and delete later: suspension removes access while keeping the data.
- Move ownership of Drive files, repositories and integrations to company accounts before any account changes state.
- Retention policies in Slack and Google Workspace delete records on schedule, whoever is still employed.
- Write down what was preserved, where and by whom, so the archive can be trusted later.
Why do layoffs destroy company records?#
Layoffs destroy records because offboarding procedures are built for single departures, where deleting an account frees a license and the work was handed over weeks earlier. When many people leave on the same day, nobody has time to hand anything over, and default deletion steps remove documents, repositories and message history in bulk.
The loss usually surfaces months later, during a customer dispute, a diligence request or an assessment of which records the company could license. Engineering design documents, code review discussions and customer escalation threads are typically the hardest to rebuild, because their authors are gone.
Preservation is a separate decision from any later use. Keeping records intact costs little compared with losing them, and it leaves every option open: litigation response, a sale, a system migration or a license.
Suspend, transfer or delete: what each action does#
Suspending or deactivating an account removes the person's access while keeping their records; deleting it can remove the records as well. The safe choice differs by system, so use the table to brief IT before the layoff date, and confirm each step against the vendor's current documentation, because platform behavior changes and differs by plan.
| System | Safer action | Risky action | What to check |
|---|---|---|---|
| Google Workspace | Suspend the user and transfer Drive ownership | Deleting the user before files are transferred | Whether your edition includes Google Vault or other retention options |
| Slack | Deactivate the member; their messages generally remain | Shortening retention or deleting channels | Workspace retention settings and what your plan can export |
| GitHub | Move personal-account repositories into the organization, then remove access | Leaving work repositories owned by personal accounts | Forks, personal access tokens and deploy keys tied to the user |
| Jira and Confluence | Deactivate the user; reassign issues and page ownership | Deleting users or personal spaces | Personal spaces and restricted pages |
| Keep the mailbox through suspension or an archive account | Deleting mailboxes to recover licenses | Retention rules and holds |
Which records to protect first#
The records to protect first are the ones only departing people can explain and nobody else can recreate. Rank them before the layoff date so the first hours of offboarding go to the material that matters most.
Shared inboxes deserve a specific mention. Addresses such as support or billing inboxes are often tied to one employee's account, and deleting that account can take years of customer correspondence with it.
| Record | Where it usually lives | Why it is hard to rebuild |
|---|---|---|
| Design documents and architecture decisions | Google Docs in personal drives, Confluence, Notion | The reasoning leaves with the authors |
| Code review discussions | GitHub pull requests | Review threads are not part of the git history |
| Customer escalation threads | Slack channels, help desk internal notes | Context is scattered across tools |
| Prototypes and experiments | Personal GitHub repositories, local machines | Often never pushed to the organization |
| Shared inbox correspondence | Mailboxes tied to individual accounts | Deleted with the owning user |
The do-not-delete checklist#
The do-not-delete checklist runs before access is removed, with an IT owner, an HR contact and counsel available. Assign each line to a named person and record when it was completed.
- Pause automated deprovisioning that deletes accounts after a set period.
- Suspend departing Google Workspace users rather than deleting them, after transfers in tools that rely on Google sign-in are done.
- Transfer ownership of Drive files and shared calendars to a named company account.
- Move documents from personal drives into shared drives owned by the company.
- Confirm Slack retention keeps messages and files, and export what your plan allows.
- Transfer repositories from personal GitHub accounts into the organization, and keep at least two organization owners.
- Move builds and integrations that run on departing users' tokens or deploy keys to service accounts, then revoke the old credentials.
- Reassign ownership of Jira projects, Confluence spaces, Notion pages and help desk views.
- Place legal holds where counsel advises, before any retention policy runs.
- Record what was preserved, by system, with dates and the responsible person.
Google Workspace: suspension, ownership transfer and holds#
Google Workspace records survive a layoff when the account is suspended and file ownership is moved before anyone deletes the user. Deleting a user without a transfer can remove files that person owned, including documents shared widely across the company that colleagues assumed were safe.
Google's admin tools include ways to transfer a departing user's files to another account, and editions that include Google Vault let counsel place holds on mail, Drive and chat. Retention and licensing options for former employees differ by edition, and holds protect data only while the account and its data exist, so confirm how your edition treats a deleted account before removing anyone under a hold.
Watch the knock-on effect of single sign-on. If Slack, GitHub, Jira or the help desk use Google sign-in, suspending a Google account also blocks that person from those tools, so finish repository transfers and ownership changes that need their cooperation first, or have an admin complete them.
Shared drives reduce the problem permanently. Files created in a shared drive belong to the company rather than to an individual, so moving active project folders there now makes every future departure safer.
Slack and GitHub: where records quietly disappear#
Slack records usually disappear through retention settings rather than through deactivated accounts. A workspace set to delete messages after a fixed period will remove history no matter who is still employed, and export options for private channels and direct messages depend on the plan and on admin approvals.
GitHub records disappear when work lives outside the organization. Repositories created under personal accounts, gists and project boards owned by individuals leave with the person unless transferred first. Removing a user can also break automation that relied on their tokens, so rotate credentials in the same step.
Issues, pull requests and review comments stay in organization repositories after a member is removed, but only while the organization itself is kept and someone retains owner access. If a later wind-down is possible, plan a full archive the company controls instead of relying on the hosted copy.
Illustrative: a marketing analytics software company reduces its team#
Illustrative: a fictional marketing analytics software company is reducing its engineering and support teams. The COO pauses automated deprovisioning, and IT suspends every departing Google Workspace account, transferring Drive files to a records account the COO controls.
An engineer flags that two prototypes live in personal GitHub repositories; both are transferred into the organization before access ends. Slack retention is confirmed to keep full history, and the support team's Zendesk views are reassigned. When the company later assesses its records for licensing, the design documents, code reviews and escalation threads are intact, and the preservation log shows how each was kept.
The one gap is a former support lead's mailbox, which held the shared escalations address and had already been deleted under an old script. The COO records the loss in the log, so later reviewers know why escalation email before that date is missing rather than assuming it never existed.
Where SourceX fits once the records are safe#
Preserved records keep options open without committing the company to anything. If the company later considers licensing, SourceX begins with a fit check built on descriptive information alone: system names, accessible years of history and record types, with no files shared during assessment. If a license goes ahead, it runs through the SourceX five-step transaction, and privacy preparation is finished before the supplier approves delivery.
Frequently asked questions
Is suspending accounts more expensive than deleting them?
Suspended accounts may still count against paid licenses, depending on the vendor and plan. Weigh that cost against the value of the records, and move files into shared drives or archive accounts so suspended users can be deleted safely later.
Do departing employees need to agree to preserving their work accounts?
Work accounts and their contents generally belong to the company, and preservation is standard practice. Employee notices and local law can affect how content is used later, especially messages, so involve HR and counsel before any use beyond running the business.
Should we export everything before the layoff?
Full exports take time and create security risk if stored carelessly. Preserve records in place first through suspension, ownership transfer and retention settings, then export systematically from company-controlled accounts once the immediate offboarding is finished.
What if accounts were already deleted?
Act quickly. Some platforms allow restoring recently deleted users or files for a limited period, so check each admin console and contact vendor support. Record what was lost so later diligence and assessments start from an accurate picture.
Who should own the preservation plan?
The COO or head of operations usually owns it, with IT running the steps and HR and counsel advising on notices and holds. Name one accountable person, because tasks spread across many systems are easy to drop on a difficult day.
Related resources
- InsightShutting down a SaaS startup: what to do with Slack, Jira, GitHub and email
- QuestionShould companies sell or license their data?
- QuestionWho owns enterprise data?
- InsightHow do I de-identify source code for AI training?
- InsightHow do I de-identify CAD and engineering drawings for AI training?
- SolutionData partnerships between businesses and AI developers
See if your company qualifies
A short company assessment. No data uploads are needed.