An export button produces a package, not a guarantee that a different service can reproduce your workspace. The archive may contain the files you need while losing the relationships that made them useful: labels, attachments, edit history or shared ownership. A migration is ready when representative work survives a trial import and the remaining losses are understood. This guide sets out an acceptance test for that decision, using a fictional project archive rather than claiming that any named products were tested together.
Write the acceptance list while the source still works
List the things you must be able to do after moving. Reading the final report, finding its attachments, searching by date and handing ownership to a colleague are different requirements. Translate each into observable evidence. A file count is useful, but it cannot prove that the right permissions or original timestamps have arrived.
For the fictional archive, the essential objects are a project folder, two documents, a calendar entry and an attached image. The example deliberately has a small scope so missing relationships are visible. Your actual list may include email labels, recurring events, task dependencies or album membership. Identify which are essential and which can be documented separately. Do not promise a lossless migration before the destination's supported formats and behavior have been examined.
Learn what the export actually contains
Read the source service's current export documentation and the destination's import instructions together. Check the account type, selected products, date range, file formats and omitted features. An administrative export can differ from a personal one. Some records may belong to another owner even though you can view them.
Google's Takeout documentation notes that recent changes between requesting an archive and its creation may be absent. That limitation makes the request time part of your migration record. It is not a reason to assume every export service has the same behavior. Save the relevant instructions and note the settings used for your package. If the documentation only promises a readable copy, do not silently reinterpret that as a supported round trip back into the original product or into a competitor.
Keep an untouched package and inspect a working copy
Download all parts of a split archive and verify that extraction finishes without errors. Keep an original copy in protected storage and inspect a separate working copy. Sensitive exports can contain much more than the items visible in the application's ordinary interface. Do not upload the package to an arbitrary converter or an online repair tool simply because a file extension is unfamiliar.
Create a small inventory of top-level folders, file types and selected counts. Record the source account, export request date, completion date and archive filenames without exposing credentials. Checksums can help detect later changes to the package, but a matching checksum does not establish completeness or correct interpretation. A package can remain byte-for-byte intact while containing the wrong date range or omitting a product you forgot to select.
Sample difficult records, not only easy ones
Choose examples that exercise the features you depend on. For documents, include a table, embedded image, comments and a link to another file. For calendars, inspect an exception to a recurring event as well as an ordinary appointment. For email, look at attachments, dates and organizational labels. Treat those categories as a proposed test design; the available fields depend on the actual service and format.
Compare the source view with the extracted record. In the fictional project, the report opens correctly but its shared-folder link points back to the old account. That would be a migration gap even if every document file was present. Write down whether the relationship can be rebuilt, replaced with a local reference or deliberately abandoned. Avoid silently repairing the sample and then claiming the untouched export preserved the feature automatically.
Trial the destination before the cutoff
Import a limited, authorized sample into a destination environment where mistakes can be reversed. Check item counts, representative content, attachment access, timestamps, search behavior and permissions. Look for duplicates before repeating an import. An importer may append another set instead of recognizing the records it already received.
Ask the person who will use the migrated work to complete a real retrieval task. Can they locate the latest approved document and open the attachment without signing into the old service? This task is more informative than a green success banner. Record any field the destination ignores or transforms. A destination can legitimately lack an equivalent for the old platform's features; the decision is whether the documented compromise is acceptable for your work, not whether the interfaces look similar.
Schedule the changeover and preserve the evidence
Choose a point after which new changes belong in the destination, and explain it to collaborators. If work continues during export, decide how to collect the difference without duplicating or losing records. Keep the old account available for a defined verification period when its terms and your obligations permit it. Exporting is separate from canceling a subscription or deleting an account.
The final record should name the tested package, the destination, the tasks completed and the limitations accepted. Retain a protected copy according to the value and sensitivity of the material. It requires knowing which records arrived, which relationships were rebuilt and why it is reasonable to stop depending on the source service for the tasks that matter.
An acceptance sheet for a fictional project archive
These expected outcomes define a trial; they do not report a completed migration. Write the observed result before deciding to retire the source account.
| Object | Required task | Observed result to fill |
|---|---|---|
| Report | Open text, table and image without the old account | NOT TESTED |
| Attachment | Open from the new report or documented local reference | NOT TESTED |
| Calendar | Check time zone and one recurring-event exception | NOT TESTED |
| Shared folder | Intended colleague can access with the agreed role | NOT TESTED |
| Reimport | Identify whether repeating import appends duplicates | NOT TESTED |
| Cutover | New changes have one owner and one destination after the cutoff | NOT AGREED |
Select or copy plain text
Object Required task Observed result to fill Report Open text, table and image without the old account NOT TESTED Attachment Open from the new report or documented local reference NOT TESTED Calendar Check time zone and one recurring-event exception NOT TESTED Shared folder Intended colleague can access with the agreed role NOT TESTED Reimport Identify whether repeating import appends duplicates NOT TESTED Cutover New changes have one owner and one destination after the cutoff NOT AGREED
REFERENCES
Sources and further reading
Sources reviewed October 20, 2026. Provider instructions and product terms can change. Examples identified as fictional are editorial illustrations, not reported events or product tests.