How to export your data from Google Workspace

For a complete exit from Google Workspace, the organization-wide Data Export tool is the right path, because it is the only option here that covers the whole tenant in one run. A super administrator starts it from the admin console and selects the organization's data, including Gmail, Drive, Chat and Calendar. The export is written as zip files into a Cloud Storage bucket, so the output sits in one place you control and can hash, index and hand to your migration team. Before you start, confirm that the admin account meets the documented age requirement, which is at least 30 days old, and check that your edition and tenant settings allow the export in your own console.

The per-user Google Takeout service works differently. Each individual user downloads their own data from Google products such as Gmail, Drive documents and Calendar, and the data is delivered to that user. Google documents that Workspace administrators control whether users can use Takeout at all, so an administrator may have switched it off. Treat Takeout as a gap filler, not as the exit mechanism: it is useful for personal items that the organization-wide run does not cover in the form you need, or for a user who must retrieve something urgently. It does not give you a single, auditable archive for the whole domain, and relying on dozens of individual downloads makes completeness hard to prove. Build the plan around the two paths together. Ask your Google Workspace administrator to confirm, in your own tenant, whether Takeout is enabled for users and which products it covers, and record the answer as part of your exit evidence. Then schedule the Data Export run early enough to absorb the documented processing window, which Google describes as typically about 72 hours but up to 14 days, and remember that the default bucket is deleted after 60 days, so copy the output to your own storage before that point. Any user whose needs fall outside the organization-wide export should be listed and handled through Takeout or through a documented manual process.

A finished Data Export or Takeout archive only proves that Google produced files. It does not prove that you can use them. Before you close the Workspace tenant, compare what left the source with what arrived in the target, data type by data type. Count items and measure sizes for Gmail, Drive, Calendar, Contacts and Chat separately, and record the totals from the export side so the comparison is repeatable. Expect differences where Google converts native files or skips items it cannot represent, and write those exceptions down rather than treating them as surprises. Confirm the export's delivery details too: the zip files should sit in the Cloud Storage bucket you chose, and you should download or copy them before the default bucket is deleted after 60 days.

Counts alone miss problems that matter in daily work. Sample real items in the target system: open a set of mail messages with attachments, check that labels or folders map to the expected places, confirm that calendar events keep their times, recurrence rules and attendees, and search for a few known contacts. Check that the vCard files for contacts and the iCal files for calendars parse in the tools your users will run, because a file that unzips can still fail to import. Then confirm that restored Drive folders keep their nesting, file names and version history where your target supports it. Ask the target platform's vendor or implementer which of these fields it preserves, and test each one.

Treat the verification as a gate, not a formality. Run the checks with a pilot group of real users and real data, including a shared folder and a mailbox with a large history, and keep the results with the migration record. Only after the pilot passes should you move the remaining users and retire the source. If a check fails, fix the mapping and repeat it rather than accepting the gap. Plan for a window in which both systems stay available so users can verify their own items, and confirm with the target vendor how long that window needs to be in your environment.

DeployOpen can take on the export side of a Google Workspace exit as a planned piece of work under a written, fixed scope. In practice that means agreeing which products are in scope (Gmail, Drive, Calendar, Chat and any shared drives), choosing between the admin Data Export tool and per-user Takeout for each data set, and setting the export window around the admin account age requirement, the run time Google documents for Data Export and the 60-day deletion of the default Cloud Storage bucket. The scope document is where the reader should confirm which items the work covers and which remain with the client, such as user-level Takeout requests and any Chat history the client wants to keep.

Verification is the part most often underestimated. DeployOpen can define checks that compare exported archives with the source: item counts by mailbox and folder, file counts and sizes in Drive, vCard and iCal output for contacts and calendars, and a sample of shared files opened to confirm that sharing and ownership survived the move. It can also prepare the target platform, such as Nextcloud with Collabora Online or OX App Suite on Kubernetes, so that imported data lands on tested infrastructure. Ask for the verification method and the acceptance criteria in writing before the export starts, and confirm which format conversions, such as native Docs, Sheets and Slides files, are included.

Evidence is delivered as documentation the client keeps: the export runbook, the verification results, the decisions made on exceptions, and the retention and deletion steps taken for the Cloud Storage bucket. DeployOpen prepares this material so that the client's own auditors or compliance team can review it. It does not issue audit reports, attestations or certifications, and it cannot promise how an independent assessor will judge the result. Confirm with your assessor which records they expect before the work begins, and ask any proposal to state what is delivered, who signs off each stage and how changes to scope are handled.