# Exit-Ready Tools — full text > Exit-Ready Tools is an independent publication about evaluating, adopting, and leaving productivity apps. It is not an app vendor, marketplace, software reviewer with laboratory testing, data-recovery service, security auditor, or continuation of any former entity associated with this domain. # How to Back Up Productivity App Data > Back up productivity app data by exporting the complete workspace in every useful available format, copying the files to storage independent of the app account, and recording scope, date, formats and known exclusions in a manifest. Open representative records and attachments, then run a sample restore in an isolated test workspace. Repeat according to the amount of recent work you could tolerate losing; do not treat sync alone as backup. Source: https://mygavio.com/back-up-productivity-app-data/ Publisher: Exit-Ready Tools Published: 2026-09-05 Updated: 2026-09-07 ## A backup must survive the app To back up productivity app data, export the complete dataset in every available useful format, copy it to storage independent of the app account, record the date and export scope, then test whether a sample can be opened or restored without altering the live workspace. Repeat on a schedule based on how much recent work you can afford to lose. Sync alone is not a backup, and an export is not proven until recovery works. The exact export menus and included fields vary by product and plan. Use the current vendor documentation for the account in front of you rather than following a screenshot from another version. ## Distinguish sync, export, and backup These terms solve different problems. | Mechanism | What it does | What it may not protect against | |---|---|---| | Sync | Propagates current state between devices or a cloud service | Accidental deletion, corruption, unwanted edits, account loss | | Export | Produces a copy in one or more files at a point in time | Missing fields, attachments, history, permissions, or a workable restore path | | Backup | Preserves a recoverable copy under a defined schedule and retention plan | Nothing automatically; the plan must still be tested and maintained | If deleting a task on one device deletes it everywhere, sync performed correctly. That outcome does not prove an older recoverable copy exists. An app’s native version history can be useful, but it remains inside the same product and account boundary. Treat it as one recovery layer, not as proof that you can recover after lockout, cancellation, vendor failure, or a damaged workspace. ## Define the recovery target first Write down two limits before choosing a schedule: - **Maximum acceptable data loss:** the amount of recent work you could recreate. This determines how frequently a new backup is needed. - **Maximum acceptable recovery time:** how long the system can remain unavailable while you restore or rebuild. This determines how simple and well-documented recovery must be. These are personal or organizational decisions, not universal numbers. A private reading list might tolerate a month of lost changes. A shared operations board may not tolerate one working day. List the events the backup should cover: accidental deletion, a bad bulk edit, device failure, failed migration, account lockout, malicious change, or service closure. A plan that covers only one lost laptop but keeps every copy inside the same cloud account has a visible boundary. ## Inventory what the app actually holds Productivity data is more than the visible title field. Build an inventory before exporting: - tasks, notes, documents, databases, or calendar items; - descriptions, rich text, checklists, subtasks, and status fields; - tags, labels, custom fields, priorities, and dates; - comments, activity history, and change history; - attachments and embedded files; - links between records, backlinks, and parent-child relationships; - templates, automations, saved views, filters, and notification rules; - sharing, membership, ownership, and permission information; - archived, completed, or trashed items; - integration configuration and externally stored content. Mark each item as included, excluded, transformed, or unknown for every export format. A CSV may preserve rows and columns while flattening nested tasks or omitting file attachments. A proprietary archive may preserve more structure but require the original app to restore. Export both when the product offers complementary formats. Our guide to [leaving a productivity app with your data](/leave-productivity-app-with-your-data/) uses a similar inventory for migration. A backup differs because it must be repeatable and retained before any move is planned. ## Run the first export without changing live data Read the vendor’s current export documentation and identify: 1. which role is allowed to export; 2. whether the export covers one item, one workspace, or the whole account; 3. whether archived and deleted material is included; 4. whether attachments arrive inside the archive or as expiring links; 5. whether comments, history, relationships, and custom fields survive; 6. which file formats are produced; 7. how completion is delivered and how long the download remains available; 8. whether exporting is recorded or restricted by an organization policy. Exporting is normally read-only, but do not assume. Review every confirmation screen. Stop if the workflow also offers to move, replace, detach, reset, or delete data. Download the result to a new, clearly named working folder. Do not open or extract an untrusted archive with elevated privileges. Scan it with the security controls appropriate to the device and organization. Use a filename that remains useful outside the app, for example: `app-workspace_full_2026-09-05T0815Z_vendor-export.zip` The timestamp should identify when the export was created, not when someone happened to rename it. UTC avoids ambiguity across time zones; if local time is used, record the offset. ## Create a manifest beside the files A short text or spreadsheet manifest makes the backup auditable. Record: - app and workspace name; - export start and completion time; - account or workspace scope without copying secrets; - requesting role; - formats and filenames received; - file sizes and record counts where they can be measured reliably; - expected versus present attachment counts; - known exclusions and transformations; - vendor documentation URL and access date; - verification steps and result; - next scheduled backup and responsible person. Do not put passwords, recovery codes, API keys, session cookies, or private encryption keys into the manifest. It should explain the backup without becoming a second credential store. If your environment already has a managed checksum process, record a cryptographic hash for each backup file. A matching hash later can show that the bytes have not changed since the reference was calculated. It does not prove the original export was complete, safe, or semantically correct. ## Store copies across failure boundaries Keep the working export away from the only device and account that contain the live data. CISA’s [device-data protection guidance](https://www.cisa.gov/resources-tools/training/how-protect-data-stored-your-devices) recommends frequent backups to an external drive or properly vetted cloud service and advises disconnecting an external drive when it is not actively being used so ransomware cannot reach it through the connection. For important data, use more than one storage location and ensure at least one copy is not continuously writable from the normal account or device. The right design depends on sensitivity, volume, organization policy, and available support. Protect backup confidentiality as well as availability. Use organization-approved encryption for sensitive exports. Store the recovery key through an approved key-management or password-management process separate from the encrypted file. An unreadable encrypted archive whose only key lived on the failed device meets the storage goal and fails the recovery goal. Do not upload work, client, health, financial, or otherwise sensitive exports to a personal storage account without authorization. Data ownership and retention obligations continue after export. ## Test the files before calling them a backup NIST’s [backup guidance](https://csrc.nist.gov/pubs/other/2020/04/24/protecting-data-from-ransomware-and-other-data-los/final) defines backup files as copies made to facilitate recovery and emphasizes conducting, maintaining, and testing them. A successful download notification is only the start of that test. Use a clean test location: 1. Preserve the original downloaded archive unchanged. 2. Copy it into a temporary verification folder. 3. Confirm the archive opens without an error. 4. Compare the manifest’s expected files and sizes with what is present. 5. Open representative records from the beginning, middle, and end of the dataset. 6. Check non-ASCII text, long notes, dates, recurring items, tags, links, and attachments. 7. Confirm nested or related records remain intelligible. 8. Record every missing or flattened feature. Choose samples that exercise different structures, not merely three simple notes. Include one record with an attachment, one nested item, one recurring date, one archived item, and one item containing accented or non-Latin characters if the live dataset has them. If files open individually but relationships are lost, the backup may still support manual recovery. Label that limitation accurately instead of upgrading “readable” to “complete.” ## Test restoration without overwriting production An import can duplicate, replace, merge, or corrupt live data. Treat restoration as a potentially destructive action. Use a disposable test account, test workspace, isolated profile, virtual machine, or other approved environment. Confirm that the destination contains no needed data. Read the current import documentation and note whether the operation creates new records or updates matching ones. Restore a small, representative sample first. Verify: - text and formatting; - dates, time zones, and recurrence; - hierarchy and relationships; - status, tags, and custom fields; - attachment availability and filenames; - ownership and sharing behavior; - duplicate handling; - searchability after import. Do not test restoration into the live workspace merely because it is convenient. If the vendor provides no isolated import path, test what can be opened independently and document that full restore remains unverified. Escalate a production restore to the workspace owner and qualified administrator with a rollback plan. The NIST control for backup testing includes testing information for media reliability and integrity and using a sample restoration during contingency testing. The point is operational: a backup earns trust by producing usable data in a recovery exercise. ## Choose a schedule from the work rate Set the interval from the maximum acceptable loss, then verify that the process actually completes. A daily export that silently fails is not stronger than a weekly export someone checks. Use triggers as well as a calendar. Create a fresh verified backup before: - a large import or bulk edit; - changing workspace structure or permissions; - installing a high-impact integration; - migrating to another app; - downgrading or canceling a plan; - transferring ownership; - deleting a workspace or account. Keep several dated versions when storage and policy allow. A single backup overwritten each time may preserve the latest corrupted or unwanted state and remove the earlier clean one. Review retention separately. “Keep forever” creates cost, privacy, discovery, and access-control problems. Define how many versions are retained, where, by whom, and how expired copies are securely removed under the applicable policy. ## Monitor the routine For each scheduled run, record four outcomes: | Check | Pass condition | |---|---| | Export | Expected archive or files arrived | | Scope | Current workspace and required records were included | | Integrity | Files open and retained hashes or sizes behave as expected | | Recovery | Scheduled sample restore or open-file test succeeds | Alert on absence, not only on explicit error. If a monthly export is expected and no file exists after the due date, that missing artifact is a failed run. Periodically perform the test using someone other than the person who designed the routine. Clear instructions should survive absence. Record how long recovery takes and which manual steps or vendor dependencies delay it. CISA’s [ransomware guide](https://www.cisa.gov/stopransomware/ransomware-guide) recommends offline, encrypted backups and regular tests of their availability and integrity. The guidance is aimed at organizations facing ransomware, but the separation-and-test principle also exposes fragile personal workflows. ## Know what the backup cannot reproduce Some app behavior cannot be captured in a portable file. Automations may depend on proprietary triggers. Shared links may refer to the original service. Comments may lose authorship. Recurring items may flatten into instances. Embedded content may remain in another provider. Permission groups may not transfer. Maintain a rebuild note for these dependencies: - required integrations and their owners; - automation purpose, trigger, action, and conditions; - saved views and filter logic; - role and permission model; - templates and naming conventions; - external folders, calendars, or databases referenced; - order in which components must be restored. Do not copy credentials into that note. Record where authorized administrators retrieve them through the approved process. ## Never delete the account as a backup test Account deletion is not a realistic drill. It may be irreversible, may erase version history and integrations, and may begin a retention countdown that support cannot stop. Keep the live account intact while exports and test restores are evaluated. Before any cancellation or deletion, follow the full [app-exit checklist](/leave-productivity-app-with-your-data/). Before adopting a replacement, use the [productivity app trial](/test-productivity-app-before-committing/) with the [app trials](/app-trials/) and [data control](/data-control/) hubs as published references. A trustworthy backup routine is deliberately dull: export, copy, manifest, test, record, repeat. The excitement belongs in the work, not in discovering that eight years of notes were synchronized perfectly into nowhere recoverable. ## Frequently asked questions **Is syncing a productivity app the same as backing it up?** No. Sync propagates current state, including unwanted edits or deletions. A backup preserves a recoverable point-in-time copy outside the live app boundary and is tested separately. **Which productivity app export format should I use?** Export every complementary format available when practical. Open formats may be easier to inspect, while proprietary archives may preserve more structure. Record what each format omits or transforms. **How often should I back up app data?** Choose an interval based on the maximum amount of recent work you could recreate. Add event-triggered backups before bulk edits, migrations, ownership changes, downgrades, cancellations or deletion. **How do I test a productivity app backup?** Open a copied archive, inspect representative text, dates, hierarchy and attachments, then restore a small sample into a disposable test workspace. Never experiment on the only live copy. **Should backup files be encrypted?** Sensitive exports should use encryption approved for the person or organization. Keep the recovery key through an approved process separate from the encrypted backup, and test that authorized recovery works. **Can I delete my old app after making one export?** Do not delete it yet. Verify export completeness, test representative recovery, reconcile attachments and relationships, document exclusions, and retain the old account until the approved exit plan is complete. --- # Calendar Import vs Subscribe: Which Connection Do You Need? > Import a calendar when you need a one-time copy; use a supported subscription when you need an updating view of its provider's calendar. If you need to edit the original events from another app, check for a supported account-sync or sharing arrangement instead. Protect private calendar addresses, confirm authorization and preserve existing data before any change. An updating view is not an instant-update guarantee or an independent backup. Source: https://mygavio.com/calendar-import-vs-subscribe/ Publisher: Exit-Ready Tools Published: 2026-09-08 Updated: 2026-09-08 ## Should you import a calendar or subscribe to it? Import a calendar when you need a one-time copy; use a supported subscription when you need an updating view of its provider's calendar. If you need to edit the original events from another app, check for a supported account-sync or sharing arrangement instead. Protect private calendar addresses, confirm authorization and preserve existing data before any change. An updating view is not an instant-update guarantee or an independent backup. The distinction concerns how information moves, not the appearance of the calendar. This is a documentation-based comparison checked in September 2026. No account was connected, imported, inspected or tested for this article. ## What are the three different arrangements? An iCalendar file, commonly identified by the .ics extension, transfers calendar information. The same calendar can also be offered through an online address. The extension alone does not tell you whether your app received a downloaded copy or established an ongoing subscription. | Arrangement | Intended relationship | Question to resolve | |---|---|---| | File import | Copy events from a file into a destination calendar | Which fields survive, and where will the copy be stored? | | Calendar subscription | Display a provider-controlled calendar through an updating connection | What can change, and how does this app refresh it? | | Supported account sync or sharing | Work with a connected account or explicitly shared calendar | Which events may this account view or edit? | Do not classify an arrangement from the word “Import” on its final button. [Microsoft's Outlook guide](https://support.microsoft.com/en-us/outlook/import-or-subscribe-to-a-calendar-in-outlook-com-or-outlook-on-the-web) uses that button after **Subscribe from web** as well as in its file-upload workflow. The preceding choice determines the relationship. For an existing setup, record how it was added and which account owns it. If that evidence is missing, mark the arrangement unconfirmed rather than testing it by deleting or modifying important events. ## When is a file import the right fit? A file import is useful when a separate copy is the intended result, such as a documented migration. It is not a way to keep following a changing source schedule. [Google's import instructions](https://support.google.com/calendar/answer/37118?hl=en) support ICS and CSV imports on a computer and explicitly say imported events do not remain synchronized between accounts. They also identify omissions: event guests and conference data are not imported. Repeating events imported from CSV may appear as individual events rather than a repeating series. Those details matter more than a successful completion message. A visible meeting title does not establish that the guest list, conference information or recurrence relationship survived. Before an authorized import, identify the exact destination calendar. Google's documented default is the primary calendar; do not assume a separate destination is automatically created. Keep the source intact, preserve an authorized original export, and use provider instructions for the actual operation. A file-copy decision does not authorize a destructive cleanup afterward. ## What does subscribing change? A subscription is for following the provider's calendar, not taking ownership of its events. [Apple's Calendar guide for Mac](https://support.apple.com/guide/calendar/subscribe-to-calendars-icl1022/mac) says subscribed events are controlled by their provider and cannot be edited in the subscription calendar. For a calendar that several people should edit, it directs readers toward sharing instead. The same guide, shown for macOS Tahoe 26 when checked, exposes subscription settings for location, attachments, alerts and automatic refresh. Those settings are separate questions. Seeing the calendar on one Mac does not by itself establish that the chosen account location makes it available on another device. Record the actual product, version and account arrangement before relying on a feature. A setting documented for Mac Calendar should not be treated as an Outlook or Google setting. A subscription can be appropriate for a changing schedule whose owner remains elsewhere. It is unsuitable as the sole answer to “how do I preserve an independent historical copy?” That is a separate [Data Control](/data-control/) question. ## Does a subscription update immediately? Do not rely on that assumption. Microsoft says updates to subscribed calendars in Outlook.com and Outlook on the web can take more than 24 hours. That is a documented possibility, not a maximum deadline or a promise that every calendar updates within one day. For a time-sensitive event, use the organizer's current official information and confirmation process. A destination calendar displaying yesterday's information cannot settle whether the organizer has changed today's meeting. Keep these observations separate: - When the source change was confirmed. - What the destination currently displays. - When you checked the destination. - What the provider documents about updates. A browser reload is not evidence that every upstream calendar feed was refreshed. If the source and destination disagree, investigate the documented connection and ask the provider or authorized administrator. Do not repeatedly import a file to force a subscription to update. ## When do you need account sync instead? Editing through another app requires an explicitly supported arrangement. [Google distinguishes view-only iCal access from account sync](https://support.google.com/calendar/answer/37648?hl=en): some applications let you connect the Google Account and add or edit events from either application. “Some” is important; this is not a claim about every calendar app or every account configuration. Write the requirement as an action: “I need to change the original event from this application.” Then verify that action in the provider's current documentation and your authorized permissions. A calendar appearing in the sidebar answers a viewing question, not an editing question. For work, school or shared calendars, involve the responsible administrator before choosing a connection or changing permissions. Do not bypass organizational restrictions to make a personal workflow work. ## What would a changed event reveal? The following is an original fictional example, not an observed test or a promised refresh sequence. It uses one event on the same date and in the same named time zone throughout. A fictional workshop starts at 14:00 in the source calendar. An imported copy and a subscribed view initially both show 14:00. Later, the organizer changes the source to 15:30. | Record after the source change | What the example tells you | What it does not tell you | |---|---|---| | Source: 15:30 | The organizer's record changed | Whether another app has retrieved the change | | Earlier file import: 14:00 | This is a separate imported copy | That the organizer still intends a 14:00 start | | Subscription still showing 14:00 | The checked destination differs from the source | Whether the cause is refresh timing, configuration or something else | | Subscription later showing 15:30 | This event's displayed time now agrees | That every event, field or notification is correct | The changed start is 90 minutes later: 60 minutes from 14:00 to 15:00, plus 30 minutes to 15:30. That arithmetic describes the fictional event, not synchronization latency. A useful record would say: “Source shows 15:30; subscribed view checked afterward still shows 14:00; cause not established.” It should not say “sync is broken” or invent a refresh deadline. If attendance depends on the time, resolve it with the organizer rather than waiting for a presumed update. ## What belongs in a connection record? Use one row per calendar arrangement. A single app may contain imported records, subscriptions and connected accounts at once. This proposed worksheet records evidence without asking anyone to copy private content into it. | Field | Suitable entry | |---|---| | Purpose | Historical copy, following changes, or authorized editing | | Source owner | A private role label, not a confidential attendee list | | Destination | App, platform and account context | | Mechanism | File import, subscription or documented account connection | | Evidence | Provider help-page URL and date checked | | Capability limits | Omitted fields, read-only status or relevant settings | | Current uncertainty | One question that still needs an answer | | Responsible person | Owner, provider support or authorized administrator | Do not enter passwords, tokens, meeting contents or private subscription addresses. Record that an address is held in the approved location, not the address itself. Google explicitly says its Secret Address in iCal format should not be shared with other people. Public and secret addresses have different purposes. If one has been exposed, consult Google's current corrective guidance and your administrator where applicable; this article does not instruct a reset or promise that changing an address erases information already obtained. ## What should you decide before committing? Use a short decision statement: “We need an updating, read-only view; the provider remains responsible for event changes; urgent changes require direct confirmation.” Alternatively: “We need a point-in-time copy and have documented its omissions.” Neither statement promises more than the selected arrangement can provide. If the need is collaborative editing, do not substitute repeated file copies for verified permissions and supported sharing. If the need is recovery, do not substitute a subscription for an independent, verified backup. Use [App Trials](/app-trials/) to evaluate the wider workflow separately. Keep calendar deletion, account removal, access changes and production imports outside a casual experiment. When the documented behavior or authority is unclear, seek provider or administrator clarification before changing existing records. ## Sources - [Microsoft: import or subscribe in Outlook.com and Outlook on the web](https://support.microsoft.com/en-us/outlook/import-or-subscribe-to-a-calendar-in-outlook-com-or-outlook-on-the-web). - [Google: import events to Calendar](https://support.google.com/calendar/answer/37118?hl=en). - [Apple: subscribe to calendars on Mac](https://support.apple.com/guide/calendar/subscribe-to-calendars-icl1022/mac). - [Google: sync or view calendars in computer programs](https://support.google.com/calendar/answer/37648?hl=en). Documentation checked September 8, 2026. The event example and decision worksheet are original editorial illustrations, not executed account tests. ## Frequently asked questions **Will an imported calendar update when its source changes?** Do not expect an imported file to maintain a connection to its source. Choose a documented subscription when following later changes is the actual requirement. Before importing, identify the destination, preserve the authorized source export and check which fields survive. Do not erase the source calendar simply because the copied events appear. **Can I edit events in a subscribed calendar?** Check the provider's documented arrangement. Apple Calendar on Mac describes subscription events as provider-controlled and not editable by the subscriber. If editing the original events is required, verify supported sharing or account sync and the relevant permissions. Viewing a calendar does not establish authority to change its events or its owner's settings. **How long should a calendar subscription take to update?** There is no universal refresh promise. Microsoft warns that subscribed-calendar updates in Outlook.com and Outlook on the web can take more than 24 hours. For time-sensitive plans, confirm the organizer's current information directly. Record a discrepancy without assuming its cause, and use provider support rather than repeated imports or destructive resets. **Does a Google Calendar import preserve meeting guests?** Google's current import guide says guests and conference data are not imported. A matching event title therefore does not establish a complete meeting transfer. Check the required information and recurrence structure against provider documentation before relying on the result. Keep the original records intact until an authorized migration has been reviewed. **What should I check before connecting a calendar to another app?** Identify whether you need a copy, an updating view or authorized editing. Confirm the exact app, account, provider instructions and required permissions. Keep secret addresses, credentials and meeting contents out of shared worksheets. For organizational calendars or uncertain dependencies, ask the responsible administrator before importing records, changing access or removing an account. --- # How to Leave a Productivity App with Your Data > Leave a productivity app by migrating data before canceling billing or deleting the account. Inventory active, archived, shared, and attached content; export structured and readable copies; preserve the archive; and reconcile counts, dates, recurrence, encoding, links, and attachments. Test an import, document field mapping, then run and verify the migration. Set a cutoff, redirect capture and automations, revoke integrations and tokens, and retain the old workspace through an observation period. Save a final export and billing records before canceling renewal. Delete only after confirming scope, retention, collaborator effects, and irreversibility. Source: https://mygavio.com/leave-productivity-app-with-your-data/ Publisher: Exit-Ready Tools Published: 2026-07-19 Updated: 2026-08-26 ## Do not delete or cancel first Leaving a productivity app is a data migration followed by billing cleanup and, only when appropriate, account deletion. Those are separate operations. Canceling a subscription may change export access or storage limits. Deleting an account may be irreversible. Read the current provider instructions before touching either control. Keep the old account active until you have exported, opened, counted, migrated, and sampled the data in its destination. If the service is shutting down or a deadline is fixed, export immediately and preserve every original file before experimenting with conversions. For employer, client, regulated, or shared-team data, obtain the required authorization. Ownership, retention, legal hold, privacy, and administrator controls may determine what you may export or delete. ## Inventory more than tasks List every object the app stores: - active, completed, archived, and deleted items; - notes, descriptions, comments, and checklists; - projects, folders, tags, priorities, and custom fields; - recurrence rules, dates, times, and time zones; - attachments, images, audio, and embedded files; - contacts, collaborators, permissions, and share links; - templates, automations, forms, integrations, and API tokens. Record counts by major type before export. Take screenshots of a few complicated records, not as the backup, but as a reference for structure the export may flatten. Browse [data control](/data-control/) for inventory templates. ## Export in both portable and readable forms Use the provider's official export. When choices exist, preserve a structured format suitable for import—such as documented JSON, CSV, or another application format—and a human-readable copy such as HTML, PDF, plain text, or print output. The actual options vary. Download attachments separately if the main export only links to them. Keep the original archive unchanged and create a working copy for transformation. Store copies in at least two appropriate locations independent of the departing app, protected according to the data's sensitivity. Do not upload a confidential export to a random converter. Migration files can contain notes, addresses, internal links, tokens, deleted records, and metadata not obvious from the interface. Use trusted, authorized tools and inspect their privacy and retention terms. ## Open and reconcile the export Successful download is step one. Extract a working copy safely and inspect it with software appropriate to the format. Confirm: 1. the archive opens without errors; 2. file and record counts are plausible; 3. accented text and emoji survive; 4. dates, time zones, and recurrence remain interpretable; 5. completed and archived work exists; 6. attachments open and belong to the right records; 7. links are not merely temporary signed URLs that will expire. Spot-check the oldest, newest, largest, and most structurally complex records. Compare totals with the inventory. Explain every material difference before proceeding. Some exports intentionally exclude trash, system logs, or shared data owned by someone else; document the provider's scope rather than assuming a missing count is random. ## Test the destination with a copy Create a small destination workspace and import a subset or sanitized copy first. Never run an untested bulk import into the only production workspace when a separate test is available. Map fields explicitly. A source “project” may become a destination folder; a tag may become plain text; a recurring task may become one static date. Check what happens to assignees, comments, status, attachments, reminders, and links. Import tools can duplicate records when rerun, so document each attempt and learn whether the operation is idempotent or needs cleanup. Use the [productivity-app trial](/test-productivity-app-before-committing/) to verify the destination before moving real work. ## Reconcile after the full import Run the real import from a new working copy, preserving the untouched original. Count destination records by category and compare them with the source inventory. Search for the same sample items used during the trial. Open attachments and inspect dates at daylight-saving boundaries when time zones matter. Check recurrence by examining the rule, not merely the next visible occurrence. Verify shared permissions with authorized collaborators. Do not send automatic invitation or notification storms without warning the people involved. Keep a migration log containing export date, source version or plan, file names, import tool, mapping decisions, counts, known losses, and who approved the result. This is not glamorous. Neither is discovering six months later that every completed task stayed behind. ## Stage the cutover Choose a cutoff time. After it, make new changes only in the destination. Set the old workspace read-only where the provider and team permit, or clearly label it as archived. Redirect forms, email capture, calendar connections, browser extensions, mobile shortcuts, and automation endpoints. Revoke integrations and API tokens no longer needed. Remove the old app's access to calendars, contacts, cloud storage, identity providers, and team tools through both the app and connected service where appropriate. Uninstalling a client does not necessarily revoke server-side authorization. ## Cancel billing, then consider deletion After reconciliation and an agreed observation period, download a final export and billing records. Cancel renewal according to the provider's current process and save confirmation. Check whether cancellation ends service immediately or at the paid term's end, and whether taxes, seats, add-ons, or app-store billing are handled separately. Account deletion is destructive. Confirm that no team, shared data, receipts, legal records, or recovery need remains. Read the deletion scope, waiting period, backup-retention statement, and effect on collaborators. Then follow the official process and save confirmation outside the service. Continue through [app trials](/app-trials/) before the next long subscription. A clean exit is part of adoption. The best time to learn an app exports only decorative CSV confetti is before your second Tuesday, not after your seventh year. ## Frequently asked questions **Should I cancel my subscription before exporting data?** Usually, export and verify first. Cancellation may change storage limits, paid features, administrator access, or the time available to export, depending on the provider. Read the current official instructions and billing terms. Preserve independent copies, complete the migration, and download billing records before canceling renewal. Account deletion is separate and potentially irreversible; do not use it as the first method of stopping a subscription. **Which formats should I export from a productivity app?** When available, keep both a structured format suitable for import, such as documented JSON or CSV, and a human-readable version such as HTML, PDF, or plain text. Download attachments if they are separate. Formats and completeness vary by service. Preserve the untouched original archive and transform only a copy. Open every format with an appropriate independent tool before treating it as a usable backup. **How do I verify a productivity-app export?** Open the archive, compare record and file counts with a pre-export inventory, and spot-check the oldest, newest, largest, and most complex items. Verify accented text, emoji, dates, time zones, recurrence, completed and archived records, comments, attachments, permissions, and links. Determine whether links depend on temporary service access. Explain material count differences using the provider's documented export scope before moving to account cancellation. **Why test a small import before the migration?** A trial shows how source projects, tags, custom fields, recurrence, statuses, comments, assignees, and attachments map into the destination. It also reveals duplicates, notification behavior, and lossy conversions while cleanup remains small. Use a separate workspace or sanitized subset where possible. Document every mapping and whether rerunning the importer duplicates records. Never test an unknown bulk import against the only production copy. **When is it safe to delete the old app account?** Only after exports open, the destination reconciles, an observation period passes, collaborators approve, final billing records and data are saved, and no legal, retention, recovery, or ownership need remains. Read the provider's current deletion scope, waiting period, backup-retention statement, and effects on shared work. Revoke integrations and cancel billing separately. Save deletion confirmation outside the service because the account may become inaccessible immediately or after a short window. --- # Review Google Account Third-Party App Connections > Review each app's connection type, exact permissions and current purpose before changing anything. Google distinguishes sign-in, Google access to another service, and that service's access to Google data. Disconnecting is not proof of data deletion or subscription cancellation. Preserve access to accounts you still need; ask the provider or authorized administrator about uncertain dependencies. This review does not certify an app's privacy or security. Source: https://mygavio.com/review-google-account-third-party-connections/ Publisher: Exit-Ready Tools Published: 2026-09-08 Updated: 2026-09-08 ## How do you review third-party access to a Google Account? Review each app's connection type, exact permissions and current purpose before changing anything. Google distinguishes sign-in, Google access to another service, and that service's access to Google data. Disconnecting is not proof of data deletion or subscription cancellation. Preserve access to accounts you still need; ask the provider or authorized administrator about uncertain dependencies. This review does not certify an app's privacy or security. This is a desk-researched guide to Google's documented controls, checked in September 2026. No account was inspected or changed. Google's [overview of linked apps](https://support.google.com/accounts/answer/16670080) establishes the different relationships. The worksheet below is an editorial planning tool, not an automated scanner. ## Which connection are you actually reviewing? Begin with the [official Google connection-management guide](https://support.google.com/accounts/answer/13533235?hl=en), which links to the account's linked-apps page. Confirm that you are reviewing the intended account. Use its filters and details view to identify each relationship; an app can have more than one. | Connection type | Main question for your review | |---|---| | Sign in with Google | Is Google the way I enter this app account? | | Linked account | Which app feature have I enabled Google to use? | | Access to your Google Account | What Google data can this app access or change? | Google documents separate removal controls for these relationships. Do not assume one removed connection settles every relationship with the same app. Read the current details instead of treating the app's name as a complete permission description. The direction matters. [Google Account Linking](https://support.google.com/accounts/answer/13864929?hl=en) lets Google use features of another service on your behalf. Google's example is playing music from a linked streaming account. That is different from a productivity app receiving access to your Google Calendar. Removing an account link can disable features that depend on it. ## Does signing in give an app access to all your files? No. Google describes [Sign in with Google](https://support.google.com/accounts/answer/12921417?hl=en&ref_topic=16666004) as sharing your name, email address and profile picture with permission, not your Google password. Additional Google-data access is a separate request. That distinction belongs in the review record. “Uses Google” is too vague: it leaves unanswered whether the app merely uses that identity or also reads or modifies a Google service. Record the actual permission wording rather than guessing from a familiar logo. For data access, Google distinguishes basic profile information, viewing or copying data, and managing data. Managing permission can include creating, editing or deleting information. Check the specific authorization: permission for one Google product is not automatically permission for every product. Never give an app your Google Account password to complete this review. Google's [access-types explanation](https://support.google.com/accounts/answer/14012355) describes these boundaries. ## What should go into a connection-review worksheet? Start with a record you can fill without changing settings. Keep it private and follow workplace information-handling rules. Do not place passwords, recovery codes, access tokens, customer records or screenshots of sensitive account information in a shared planning document. Use one row per relationship, not necessarily one row per app. The following fields are this publication's proposed review method: | Field | What to record | |---|---| | Account context | A private label that distinguishes personal and work accounts | | App and connection type | Displayed identity and the relationship being reviewed | | Permission evidence | Exact displayed wording and the date you read it | | Present purpose | One concrete task that still requires this connection | | Dependency | The login, workflow or shared process that needs checking | | Responsible person | You, an authorized administrator or the app provider | | Unresolved question | A specific question, not an assumed answer | | Next step and evidence | Review, seek clarification or plan an authorized change | Separate observation from inference. “The details display Calendar access” is an observation. “The team still uses this integration” requires confirmation from the responsible person. “Probably harmless” is neither a permission description nor evidence of a current need. An empty purpose field is a reason to investigate, not a diagnosis of malicious behavior. An unresolved dependency is a reason to seek clarification, not a reason to grant more access. Keep those two decisions separate. ## What does a completed example look like? These are fictional records, not observations of real apps, permissions or user accounts. | Fictional record | Known fact in the example | Missing evidence | Proposed next step | |---|---|---|---| | Sample Task Planner: sign-in relationship | The owner still needs its project archive | Whether another supported login reaches that same archive | Ask the provider before changing sign-in | | Sample Calendar Board: data-access relationship | A former trial used the calendar display | Whether a colleague still relies on that display | Ask the workflow owner; leave the answer unresolved | | Sample Audio Service: account-link relationship | The owner no longer uses the linked playback feature | Whether any other device still depends on it | Review that dependency before deciding about the link | Do not combine these into a single “three apps to delete” list. Each record asks a different question. The task planner has an account-entry dependency; the calendar board has a shared-workflow uncertainty; the audio service has a linked-feature dependency. For the fictional calendar board, a useful handoff note would be: “Please confirm whether the shared planning view still depends on this connection. The review has not changed access. If it is still used, identify its owner and current purpose.” This asks for operational evidence without copying calendar contents into the note. A reply such as “we stopped using it” resolves the purpose question only. It does not establish what data the provider retained, who pays for the subscription, or whether another connection exists. Keep those as separate fields. ## What needs checking before any consequential change? First, establish how you will access an app account you still need. Google's [linked-app troubleshooting guidance](https://support.google.com/accounts/answer/12917337) warns that some apps do not support multiple sign-in methods for the same account. Contact the developer when that is unclear. Do not assume adding a password or choosing another button will reach the same records. Second, identify who is authorized to change the connection. For work or school accounts, ask the responsible administrator about organizational requirements and shared dependencies. This guide is not permission to alter another person's account or bypass an administrative restriction. Third, separate a routine review from a suspected compromise. If you suspect account intrusion, use Google's [official compromised-account guidance](https://support.google.com/accounts/answer/6294825), and notify your organization's security team where relevant. A worksheet is not an incident-response procedure. For broader preparation, the [App Trials collection](/app-trials/) covers evaluating tools before commitment. Use the [Data Control collection](/data-control/) for the separate tasks of preserving records and planning an exit. This connection review does not replace either task. ## What remains unresolved after a connection is removed? A removed permission and a deleted copy are different outcomes. Google's data-access guidance says an app may already hold copied information and that you may need to request its deletion from the developer. Google's [data-sharing safety explanation](https://support.google.com/accounts/answer/14013600) also identifies provider retention policies as controlling how long information is stored. Review the provider's current privacy terms and deletion process rather than treating a disappeared connection as proof of erasure. Keep billing in its own workstream: find the subscription's actual billing provider and its cancellation instructions. Do not mark a subscription cancelled because an account connection changed. Likewise, do not delete an app account merely to see whether the connection list updates; account deletion can destroy information you still need. Close your review with an evidence note: what relationship you examined, what remains uncertain, who owns the next decision, and which provider documentation applies. If an authorized change is later made, record its observed result separately. A shorter connection list is not a privacy guarantee; the useful outcome is a clear account of access and unresolved obligations. ## Sources - [Google: manage links and review connection types](https://support.google.com/accounts/answer/13533235?hl=en). - [Google: account linking and dependent features](https://support.google.com/accounts/answer/13864929?hl=en). - [Google: information shared through Sign in with Google](https://support.google.com/accounts/answer/12921417?hl=en&ref_topic=16666004). - [Google: data-access types and previously copied information](https://support.google.com/accounts/answer/14012355). - [Google: linked-app login and account troubleshooting](https://support.google.com/accounts/answer/12917337). - [Google: linked-app overview](https://support.google.com/accounts/answer/16670080). - [Google: data-sharing and retention considerations](https://support.google.com/accounts/answer/14013600). - [Google: suspected account compromise](https://support.google.com/accounts/answer/6294825). ## Frequently asked questions **Are Sign in with Google and Google data access the same?** No. Google's sign-in feature shares basic profile information with permission; an app can separately request access to other Google data. Review each relationship and its displayed permissions. Record the purpose of any additional access rather than assuming a familiar sign-in button describes everything the app can do. **Does removing a connection delete information the app copied?** Do not treat removal as evidence that previously shared information has been erased. Check the app provider's retention policy and deletion process, and ask the provider about copies it already holds. Preserve any records you need before considering account deletion; a connection review is not a deletion test. **Should I remove every connection I do not recognize?** An unfamiliar entry needs investigation, not an invented explanation. Verify its identity, current purpose and owner using official account details and provider information. For workplace connections, involve the authorized administrator. If you suspect a compromise, follow official account-security guidance rather than treating a routine review worksheet as an incident-response procedure. **Can I keep my app account after stopping Google sign-in?** Confirm the app's supported access methods with its developer before changing a sign-in relationship you still need. Some apps do not support different sign-in methods for the same account. Do not assume a new password or another sign-in button will reach the existing account and its records. **Does disconnecting an app cancel its subscription?** Do not use a connection change as cancellation evidence. Identify the actual billing provider, follow its current cancellation instructions and keep the resulting confirmation separately. Connection access, subscription status and retained information are separate review questions. Avoid deleting an account as a shortcut when you still need its records. --- # How to Test a Productivity App Before Committing > Test a productivity app with fake data before moving real work. Define requirements and deal-breakers, then create sample tasks with dates, recurrence, tags, subtasks, an attachment, completed status, accented text, and an emoji. Test capture, search, retrieval, notifications, offline behavior, sync conflicts, accessibility, permissions, privacy, pricing, and support on the devices and plan you would use. During the trial, export the sample, open it independently, and verify counts, text, dates, structure, and attachments. Score each requirement passed, passed with friction, failed, or not tested; never average away a deal-breaker. Source: https://mygavio.com/test-productivity-app-before-committing/ Publisher: Exit-Ready Tools Published: 2026-07-19 Updated: 2026-08-26 ## Define the job before opening the store Write the workflow the app must support in one sentence: “Capture personal tasks quickly, plan a week, and retrieve project notes on phone and laptop.” Then list three requirements and three deal-breakers. A requirement might be offline access, keyboard navigation, shared lists, reliable recurring dates, or export to a documented format. A deal-breaker might be mandatory public sharing, no usable export, inaccessible controls, or a subscription beyond the budget. Check current price, billing period, renewal terms, platform support, and refund policy on the seller's own pages. Screenshots age faster than bananas. Do not begin with all your real work. A trial should be reversible and deliberately small. ## Build an awkward sample dataset Create 12 to 20 fake but realistic items. Include: - a plain task and a long note; - a due date and a due time; - one recurring item; - subtasks, tags, and a project or folder; - an attachment with a harmless sample file; - punctuation, an accented name, and an emoji; - two items with similar titles; - one completed item and one deleted test item. Use no confidential, personal, client, medical, financial, or credential data. The set should expose weak handling without creating a real breach if sync, sharing, or deletion behaves unexpectedly. Record the expected count and structure. You will use the same set in every candidate, which makes comparison more useful than remembering that App A “felt organized” while App B had a very calming shade of blue. ## Test capture under ordinary friction Add the same item through every input you expect to use: keyboard, mobile app, share sheet, browser extension, email, or voice only where supported and appropriate. Time the process informally, but also count corrections. Check whether the app preserved the intended date, time zone, recurrence, tag, note, and attachment. Create one item while rushed and one while offline. Reconnect and verify the result on another device. Do not manufacture a sync conflict with important data; edit the same harmless sample on two devices and observe which version survives or whether the app asks you to reconcile. Features and offline behavior vary by plan and platform. Test the exact paid tier and devices you would use, not a marketing sentence about “access everywhere.” Browse [app trials](/app-trials/) for workflow-specific test sets. ## Retrieve, do, and review Capture is the app's audition. Retrieval is the job. Search for the accented name, partial title, tag, and a word inside the long note. Filter due items and completed items. Open the attachment. Move a task, complete a recurring occurrence, and confirm what the next date becomes. Undo a safe change, then restore the deleted test item if the service claims a trash or recovery feature. Run a ten-minute weekly review. Can you see overdue, upcoming, unscheduled, waiting, and completed work without rebuilding the interface? Does the app show enough context to decide, or does every task require a small expedition? Test notifications only after checking operating-system permission and focus settings. A reminder that did not appear may be blocked by the device, app configuration, account tier, network, or battery policy. Diagnose the path before calling the feature broken. ## Inspect accessibility and attention cost Use keyboard navigation where relevant. Increase text size, zoom the interface, switch contrast or theme, and try a screen reader if that is part of your use. Check focus visibility, labels, drag-only actions, color-only status, motion, and whether essential controls remain reachable on a small screen. Accessibility is personal and task-specific. A published conformance statement can inform the test but does not replace using the workflow with your own access needs. Also count attention costs: forced badges, upgrade prompts, inboxes you cannot hide, and notifications enabled by default. Productivity software should hold work, not repeatedly ask whether you have considered becoming more productive through merchandise. ## Review permissions, privacy, and ownership Grant only permissions needed for the feature you are testing. A calendar view may need calendar access; a basic text list should explain why it wants contacts, microphone, location, or full storage. Review the current privacy policy, data location or subprocessors when relevant, retention, advertising, model-training language, account security, and process for exporting and deleting data. For workplace or regulated data, use the organization's approved security, legal, and procurement process. A personal checklist is not a vendor risk assessment. ## Run the exit test during the trial Export the sample dataset before paying annually. Open the result in an appropriate independent tool. Check item count, notes, dates, recurrence, tags, completed status, attachments, and non-ASCII text. A ZIP file that downloads successfully but contains a logo and three empty folders has technically traveled, not succeeded. Our guide to [leaving with your data](/leave-productivity-app-with-your-data/) covers the full reconciliation process. Continue through [data control](/data-control/) before importing real work. ## Make the verdict reproducible Score only the requirements you named: capture, retrieval, sync, offline behavior, accessibility, sharing, privacy, export, support, and total current cost. Mark each **passes**, **passes with friction**, **fails**, or **not tested**. Do not average a deal-breaker into victory with five decorative features. Choose the smallest commitment that preserves the trial result. Keep the sample export and notes. If no candidate passes, the correct result is not “pick the prettiest.” It is “the current system remains employed while the search continues.” ## Frequently asked questions **What sample data should I use in an app trial?** Use 12 to 20 fake but realistic items containing a plain task, long note, due date and time, recurring item, subtasks, tags, project, harmless attachment, accented text, emoji, completed item, and deleted test item. Record expected counts and reuse the same set in every candidate. Never use confidential, client, credential, health, financial, or other sensitive data for a casual trial. **How long should I test a productivity app?** Test long enough to complete the workflow's real cycle, including at least one review, recurrence, offline period, sync across intended devices, reminder, and export. A fixed number of days is less useful than completed scenarios. Check the trial deadline and cancellation terms directly so billing does not begin unexpectedly. Keep the initial dataset small and avoid an annual commitment until the exit test succeeds. **How do I test productivity-app sync safely?** Use harmless sample records on the exact devices and networks you expect. Create an item offline, reconnect, and verify it elsewhere. Edit the same fake item on two devices to observe conflict handling. Record which version survives and whether history or recovery exists. Do not manufacture conflicts with real work. Separate app behavior from device notification, battery, account, or network settings when diagnosing a failure. **Why should I test data export before paying?** An export reveals whether you can leave with usable records rather than screenshots or locked links. Download the sample export, open it in an independent appropriate tool, and verify counts, text encoding, notes, dates, time zones, recurrence, tags, completion, and attachments. Read the provider's scope because trash, shared data, or some metadata may be excluded. A downloaded archive is not successful merely because it has a filename. **How should I score a productivity app?** Score only requirements named before the trial, such as capture, retrieval, sync, offline use, accessibility, sharing, privacy, export, support, and total current cost. Mark each passed, passed with friction, failed, or not tested, and preserve short evidence notes. Keep deal-breakers separate rather than averaging them against cosmetic features. If no app passes, retain the current system while testing another candidate instead of choosing by design alone. ---