Changing project management software can preserve task titles while losing the context that makes work reliable: hierarchy, comments, attachments, custom fields, permissions, automation, timestamps, archived items, and ownership. The safest record is a layered evidence package that shows what existed, how it was exported, what moved, what did not, and how the destination was verified.
Keep a dated system inventory
Record organizations, workspaces, teams, projects, boards, portfolios, forms, templates, dashboards, integrations, automations, guests, administrators, billing owner, identity provider, recovery contacts, retention settings, and archive counts. For each active or regulated project, name the business owner, data steward, required history, and acceptable downtime.
Do not put passwords, tokens, recovery codes, customer secrets, or private keys in the inventory. Record only that an authorized owner-controlled recovery route exists. Use fictional data for migration trials unless real data is explicitly authorized and protected.
Preserve original vendor exports
Asana's project import and export documentation says projects can be exported as JSON or CSV and tasks can be imported by CSV. It also identifies Search Views and My Tasks as separate exportable scopes. Save the original files, scope, account role, settings, export time, and provider documentation used.
Atlassian's Trello export guidance says board members can export raw JSON, while CSV and workspace exports depend on plan and role. It notes differences in comment coverage, optional raw attachments, and that JSON or CSV cannot directly recreate a Trello board. These limitations should appear in the migration evidence, not as surprises after shutdown.
Store original archives read-only. Record filename, byte size, generation time, source workspace, object counts, and a cryptographic checksum where proportionate. Keep the exported documentation or a dated reference because vendor behavior can change.
Save relationships and files, not just rows
Inspect stable IDs, parent-child relationships, project membership, sections, dependencies, milestones, status, assignees, due dates, custom-field definitions and values, comments, activity, completion history, archived objects, and external links. Export attachment binaries when permitted; a URL may stop working after the source account closes.
Keep a mapping table from source IDs to destination IDs and from old users to authorized destination users. Preserve departed users as historical attribution rather than impersonating them. Record unsupported relationships and every manual transformation.
Document permissions, automation, and integrations
Capture roles, guests, restricted projects, private tasks, sharing rules, group membership, and administrator boundaries without exposing confidential task content beyond the authorized migration team. Take configuration evidence for recurring tasks, rules, forms, email ingestion, webhooks, calendar links, repositories, chat integrations, and reporting feeds.
For each automation, record trigger, conditions, actions, owner, credentials location by reference, last observed run, failure behavior, and destination replacement. Screenshots can support a record, but use machine-readable configuration or a field-by-field worksheet when available.
Build a migration and exception ledger
Record each export, transform, import, retry, error, owner decision, and validation result with timestamps. Count objects by type before and after. Maintain an exception list for missing attachments, truncated comments, unsupported custom fields, changed dates, unmapped users, duplicate tasks, failed automations, and permissions that require manual recreation.
Separate “exported,” “transformed,” “imported,” “verified,” and “accepted.” A successful command is not acceptance. Do not delete or downgrade the source until the authorized owner reviews material exceptions and confirms the retention plan.
Prove restoration in a clean environment
Import representative projects into a clean test workspace. Compare every selected field and relationship against the source evidence. Open attachments, exercise filters, complete and reopen tasks, trigger safe automations, test normal member and guest access, and verify that restricted work remains restricted.
Save the test plan, expected results, observed results, screenshots or logs, counts, timings, reviewers, and unresolved differences. Include rollback steps and a final source snapshot taken immediately before cutover. If direct import is unavailable, preserve the transformation code or repeatable procedure and test it twice.
Retain a durable handoff package
The final package should contain the inventory, original exports, attachment archive, checksums, ID mappings, field mappings, user mappings, permission matrix, automation register, integration register, exception ledger, restoration results, rollback plan, acceptance decision, source-retention date, and responsible owners. Encrypt and restrict it according to the underlying data.
The evidence is sufficient when an independent authorized reviewer can explain what moved, reproduce the important transformation, account for every material omission, verify destination access, and recover critical work without relying on the departing administrator's memory. Keep retention periods proportionate to legal, contractual, operational, and privacy requirements.
Sources
- Project importing and exporting — Asana Help Center
- Export data from Trello — Atlassian Support