Changing a digital task list can look harmless because the visible objects are short lines of text. In practice, a move or redesign may also change owners, due dates, recurrence, reminders, attachments, comments, permissions, integrations, and the meaning of completed work. Keep enough evidence to prove what existed, what moved, what did not move, and whether the new list works for the people who depend on it.
Capture the operating baseline
Before changing anything, record the account or workspace that legally owns the list, the people who can view or edit it, the list names, active and completed task counts, fields in use, recurrence rules, reminders, attachments, links, labels, dependencies, automations, and integrations. Add the date, time zone, device or client, and person taking the snapshot.
Use screenshots for layout and settings, but do not rely on screenshots as the only record. Export or print a small representative sample that includes a normal task, a recurring task, a completed task, an assigned task, an attachment, and a comment. Redact personal information before sharing diagnostic evidence outside the authorized team.
Google's data export guidance explains that users can select products and archive formats, but also warns that changes made between the export request and archive creation may not appear. Record both the request time and the archive completion time so the evidence has an honest boundary.
Preserve meaning, not just task titles
For each important task, retain its stable identifier if available, title, description, owner, creator, created date, due date and time zone, completion state, recurrence, reminders, subtasks, labels, attachments, links, comments, and last update. A migration that copies titles but loses ownership or recurrence is not complete.
Create a field map from the old system to the new one. Mark every field as mapped, transformed, intentionally omitted, or unsupported. For transformed values, document the rule. If recurring tasks become individual tasks or local times become UTC, keep examples that prove the conversion behaved as intended.
Record sharing and access changes
List who could access the old list, how access was granted, and who should have access afterward. Preserve invitation settings, guest restrictions, administrator roles, and the approved owner. Do not include passwords, recovery codes, or active invitation tokens in the change record.
Microsoft's To Do sharing guidance documents invitation links, limiting a link to current members, and stopping sharing. Those actions can materially change who retains access, so record the before state, approved change, after state, and a verification from a non-owner account when safe.
Test the new workflow with a fixed sample
Use the same representative sample before and after the change. Confirm that assigned users can see and update their tasks, reminders arrive in the intended time zone, recurrence creates the expected next task, attachments open, comments retain order and author context, search finds known items, and completed tasks remain distinguishable from deleted tasks.
Test one failure path: revoke a test user's access, disconnect a noncritical integration, or restore a small exported sample. Record expected and observed results. Avoid destructive tests on the production list when a sandbox or copied list can prove the same behavior.
Keep a change ledger and rollback package
For each change, record the date, requester, reason, scope, approvals, old setting, new setting, test evidence, exceptions, owner, and rollback instruction. Store an export, field map, screenshots, and issue list together. Hashing an export can show which exact file was reviewed, although a hash does not prove the export was complete.
Define the rollback boundary before launch: which system remains authoritative, how long the old list stays read-only, how new tasks will be reconciled, and who decides to return. The change is complete only when task counts and critical fields reconcile, access is verified, exceptions have owners, and a second person can understand the record without relying on the operator's memory.
Sources
- How to download your Google data — Google
- Create and share lists — Microsoft