Phase 0

Decide & Plan

Lock the decisions that cause mid-migration scope creep when skipped.

Document the migration scope by Asana object class: Workspaces or Organizations, Teams, Projects, Sections, Tasks, Subtasks, Custom Fields, Portfolios, Goals. Each class has different import paths and tier gating; list which are in scope and which are explicitly out.
Risk if skipped: Discovering mid-cutover that Portfolios or Goals were assumed in-scope but were never planned for blocks executive reporting on day one.
Decide between an Organization model and a Workspace model in the destination. Personal Projects organizations cannot be used as a source or destination domain, and Organizations cannot be migrated to Workspaces. Pick the destination shape before any other work.
Risk if skipped: Choosing the wrong domain type forces a full re-do because the platform does not convert between the two.
Decide the historical-data scope: how many years of completed tasks, how far back for comments, and whether deleted tasks are included. Deleted objects (teams, projects, tasks) are not copied during a platform-assisted migration, and completed-task history is often re-stamped on CSV import.
Risk if skipped: Users expect to see closed work on day one and find a blank Completed view, eroding trust in the new system.
Decide and document the strategy for record ownership: keep original assignees, reassign to a single migration user, or best-match by email. Asana matches assignees on the email address in the Assignee column at import time.
Identify GDPR, SOC 2, HIPAA, and FERPA obligations that apply to the data set. Asana holds ISO 27018:2019, ISO 27701:2019, SOC 2 Type 1 with HIPAA, and SOC 2 Type 2 with Privacy attestations; confirm your DPA covers the source data.
Risk if skipped: A regulated data set landing in an unconfigured tenant can trigger a reportable incident before users even log in.
Decide whether EU data residency is required and confirm the destination domain is provisioned in the Frankfurt region if so. Data residency in the EU data center is an Enterprise add-on and an Enterprise+ inclusion; user authentication and seat-usage data remain outside the residency boundary.
Risk if skipped: If residency is needed but not provisioned at sign-up, switching regions later requires re-migrating the domain through Asana's data migration request flow.
Set the cutover date, the source-system freeze window, and the read-only date. Pick a low-activity window; communicate it in writing to all source-system users at least two weeks ahead.
Assign a single accountable DRI for the migration project. One named owner for end-to-end execution; secondaries for export, transform, load, and validation.
Document explicit success criteria for declaring the migration complete. Examples: zero variance in active task counts per team, all subtasks linked to their parent, all attachments accessible, three power users sign off per team.
Risk if skipped: Without written criteria, the project never formally ends and the source system never gets decommissioned.
List out-of-scope items explicitly in the project plan. Common out-of-scope items: deleted tasks, archived projects older than X years, board-only attachments, legacy integrations.

Phase 1

Pre-Migration Prep

Everything that must be true before the first byte leaves the source.

1a. Source-system audit and cleansing

Export current record counts per object from the source as a baseline. Tasks, completed tasks, subtasks, projects, sections, custom fields, attachments, comments, users.
Risk if skipped: Without baseline counts, you cannot prove the destination received everything during validation.
Run a deduplication pass on source users using email as the match key. Asana matches by email when assigning tasks and when applying CSV user import; duplicate emails create ambiguous matches.
Risk if skipped: Duplicate emails resolve to the wrong user during import and reassignment becomes a per-task cleanup job.
Normalize email casing on every source user record to lowercase. Email casing inconsistencies cause assignee lookups to silently fail on some imports.
Identify tasks with empty required-equivalent fields (assignee, due date, project) and resolve. Decide per field whether to backfill, drop, or import as null.
Audit source picklist / dropdown values per custom field and collapse near-duplicates. Asana single-select and multi-select fields are case-sensitive on import; "Option" and "option" become two separate values.
Risk if skipped: Importing case-mismatched values silently creates a parallel dropdown option, doubling the value list and breaking filters.
Identify any source dropdown field exceeding 500 options. Asana caps drop-down custom fields at 500 field value options; values above that cap must be reshaped before import.
Risk if skipped: An over-cap dropdown imports the first 500 values and silently drops the rest, orphaning tasks tagged with truncated values.
Identify any source object with more than 100 custom fields on one project equivalent. Asana allows up to 150 custom fields in a single project and up to 60 fields per task via multi-homing.

1b. Destination setup

Provision the production Asana domain and confirm tier (Starter, Advanced, Enterprise, Enterprise+). Tier determines access to Custom Fields, Rules, Bundles, Portfolios, Goals, Forms, Approvals, Service Accounts, the audit log, and the Time tracking field.
Risk if skipped: If you build the migration plan assuming Enterprise features and the domain is on Advanced, half the workflow rebuild stops on day one.
Request an Asana Sandbox via the super admin console. Sandboxes are available on Enterprise+ and mirror production for performance, speed, and security; use one for the test migration in Phase 4.
Risk if skipped: Testing against production exposes real users to dirty test data and rules they did not opt into.
Create Teams in the destination Organization in the intended hierarchy. Teams are containers for Projects; create them before importing projects so projects land in the right place.
Invite all required users and assign roles before any task import. Use the CSV user import (Advanced, Enterprise, Enterprise+) to bulk-invite; guests are not processed via that import path.
Risk if skipped: If assignees do not exist as members at import time, the Assignee column silently leaves tasks unassigned.
Create the field library entries for every custom field that will be migrated. Custom fields must exist on the destination project before import, otherwise the importer maps them into the task description text.
Risk if skipped: Missing field definitions cause data to land in the task description as free text, requiring per-task re-parsing.
Create a dedicated External ID custom field on every project receiving imported tasks. Asana's ID custom field is platform-generated; use a separate text custom field to hold the source system's primary key for upsert matching and reconciliation.
Risk if skipped: Without an external-ID column, re-running an import after fixing a transform creates duplicates instead of updating in place.
Configure org-level settings (locale, timezone, working days, default project privacy). These settings affect how the importer parses dates and how Rules evaluate them.
Pause every Rule and integration on the destination before import. Rules fire on task creation and field changes; an active rule during bulk import can mass-assign, mass-notify, or mass-archive thousands of records.
Risk if skipped: An unpaused notification rule during a 10,000-task load sends 10,000 emails to assignees who do not yet know the migration happened.
Disable email notifications for the migration service account that will run the import. Even with rules paused, native activity notifications still go to followers; muting at the account level cuts the noise.

1c. People prep

Communicate the source-system freeze date and cutover window to every end user in writing. Specify the exact time the source goes read-only and the exact time the destination opens.
Risk if skipped: Users editing source data after the export point create a delta that has to be reconciled by hand at cutover.
Schedule a 30–60 minute training session on Asana basics segmented by role. Cover My Tasks, Inbox, List/Board/Timeline views, sections, dependencies, and search; admins get a separate session.
Identify and brief a roster of first-responders for the first 48 hours after cutover. One per team is enough; their job is to triage "where did my task go" questions, not to do training.
Pre-write a one-page "day-one in Asana" reference and link it from the destination's home banner. Login URL, how to find their tasks, who to contact, where the source archive lives.

Phase 2

Source Export

Get everything out — including the things you didn't think of.

Phase 3

Transform & Map

Turn source exports into Asana-shaped files.

3a. Mapping spreadsheet

Build a master mapping spreadsheet: source field, destination Asana field, transform rule, required-on-import flag. Include one row per source field per object type; this becomes the single source of truth for the transform.
Risk if skipped: Without a documented mapping, every transform decision is reinvented per-engineer and produces inconsistent output.
Resolve every picklist value mismatch between source and destination. Asana single-select values are case-sensitive; "In Progress" and "in progress" import as two separate values.
Risk if skipped: Case-sensitive value collisions silently inflate the dropdown option list and exhaust the 500-option cap.
Choose the upsert key per object class: typically external-ID text field for tasks, email for users. The CSV importer does not natively upsert, so store the source ID in a dedicated External ID custom field for cross-system reference and reconciliation.
Risk if skipped: Without an upsert key, a re-run produces duplicates instead of updates and forces a manual dedup pass.
Decide handling for source fields with no Asana equivalent: drop, concatenate into task description, or create a new custom field. Document the call per field so reviewers can audit it.
Confirm per-project custom field count stays at or below 150. Per-project limit is 150 custom fields; per-task limit is 60 via multi-homing.

3b. Data transformation

Convert all date fields to ISO-8601 (YYYY-MM-DD) for due dates and start dates. Asana CSV import accepts multiple formats but mixing MM/DD/YYYY and DD/MM/YYYY in one file causes silent reinterpretation.
Risk if skipped: Date format drift between rows causes some tasks to land with a due date one year off and no error from the importer.
Convert all datetime fields used in formulas to UTC. When custom fields like Created on and Completed on are used in Asana formulas, the formula engine treats them as UTC timestamps regardless of display timezone.
Re-encode every text field as UTF-8 and verify with a byte-order-mark check. Non-UTF-8 text causes attachment filenames and task names to render as garbled mojibake (notably on Japanese and Cyrillic strings).
Risk if skipped: Mojibake in task names is irreversible once imported and requires re-importing the affected rows.
Escape commas, double quotes, and newlines inside text fields per RFC 4180. Unescaped quotes split rows mid-import and shift columns out of alignment downstream.
Truncate task name fields to fit Asana's display ceiling; preserve full text in the description. Long task names render but degrade list-view usability; keep names under ~120 characters.
Translate source rich-text markup to Asana's supported markdown subset. Asana descriptions accept H1, H2, bold, italic, strikethrough, blockquote, ordered/unordered lists, code, and links; everything else is stripped to plaintext.
Risk if skipped: Unsupported HTML in descriptions gets silently stripped and tables, images, or color spans disappear without warning.
Split or aggregate source files larger than 100 MB before upload. Asana caps native attachments at 100 MB per file; larger artifacts must be moved to Drive/Box/Dropbox and attached as a link.

3c. Audit-trail and ownership decisions

Capture the original creation date of every task in a dedicated "Source Created On" date custom field. The CSV importer re-stamps creation date to the import moment; the original is only preserved if you put it into a custom field.
Risk if skipped: Without a preserved creation date, every historical task looks like it was created on cutover day and breaks aging reports immediately.
Capture the original completion date for completed tasks in a "Source Completed On" date custom field plus a Status single-select set to "Complete". Pair this with a Rule that, when Status = Complete on import, marks the task complete and clears Status. Build the Rule before import.
Risk if skipped: Completed-task history without a re-completion mechanism leaves every imported closed task open in the destination.
Map source assignee identifiers to Asana user email addresses one-to-one. Use the user roster from Phase 2; unresolved assignees become unassigned tasks.
Decide the attachment strategy: re-upload binaries to the destination task versus preserve as external-storage links. Re-upload preserves the file inside Asana's 100 MB cap; linked files keep their permissions and are not bounded by Asana storage.

3d. PM-specific transforms

Collapse the source project hierarchy into Workspace → Team → Project → Section → Task → Subtask, capping subtasks at 5 levels. Deeper hierarchies must be flattened: either promote depth-6+ nodes to siblings, or fold them into the parent's description, or relocate them to their own project.
Risk if skipped: Subtasks beyond depth 5 are silently dropped by the importer with no error line for the affected row.
Translate source task dependencies into Asana's blocking / blocked-by model via the CSV "Dependent on" column. List the predecessor task name or row reference in the Dependent on column of the same CSV; cross-project dependencies are not date-shift-aware.
Risk if skipped: Cross-project dependencies that shift dates in the source do not propagate date shifts in Asana, so downstream timelines silently desynchronize.
Migrate Everhour or other source time-tracking entries into Asana's native Time tracking custom field. Asana provides a documented Everhour-to-Time-tracking-field migration path; for other time tools, re-load as Estimated time and Actual time columns on the task.
Risk if skipped: Time entries left in the source ledger after cutover make billing and capacity reports incomplete from day one.
Re-create comment threads by re-posting each historical comment as a task story, including a prefix with the original author and timestamp. The CSV importer does not carry comments; re-posted stories are timestamped at post time, so the prefix preserves the original conversation order.
Risk if skipped: Re-posted comments without an original-author prefix all appear to come from the service account, making thread attribution useless for audit.
Translate source custom-workflow statuses into either Asana Sections or a single-select Status custom field, not both. Sections work for visual board columns; a Status field works better for cross-project reporting through Portfolios. Pick one per project class and stay consistent.
Re-create recurring task rules at the destination — they are configured per-task in Asana, not migrated. Recurrence is a task-level setting ("set to repeat") and is not part of the CSV schema; configure on the template task post-import.
Risk if skipped: Recurring tasks left without their recurrence setting silently stop generating future instances after cutover.
Rebuild source Forms as Asana Forms; capture submitter-name and email questions explicitly. Asana Forms create tasks on submit and pre-fill assignee and project; mirror the source form fields one-to-one.
Stage the Rules and Bundles rebuild list with priority order. Rules cannot be migrated; document each Rule's trigger and action so they can be rebuilt in Phase 7 as Bundles where reused across projects.

Phase 4

Sandbox Test Migration

Find every problem here, before it costs you in production.

Phase 5

Production Cutover

A tightly-sequenced execution window — densest cluster of risk.

Phase 6

Validate

Prove the migration was correct before letting users in.

6a. Reconciliation

Compare total task counts per project: source baseline versus destination post-load. Investigate any variance beyond what the documented delta accounts for.
Risk if skipped: An unexplained gap of even a few tasks usually indicates a systemic transform bug affecting more rows than the visible miss.
Compare open task count by team in source versus destination. Run the same filter on both sides and confirm the totals match.
Compare completed task count per project, scoped to the historical window. Completed tasks rely on the Phase 3 Status field plus Rule mechanism; this check confirms the Rule fired.
Risk if skipped: If the completion-state Rule misfired, every imported "complete" task is still open and clutters live work views.
Cross-check 25–50 randomly-selected tasks field-by-field between source and destination. Stratify the sample: 10 from depth-1, 10 from deeper subtasks, 10 with attachments, 10 with custom fields populated, 10 with comments.
Risk if skipped: Sampling only depth-1 tasks misses the bugs that hit deep subtasks and attachment-heavy records.
Verify every custom field value arrived intact on the sampled tasks. Check single-select, multi-select, number, date, people, and formula outputs.

6b. Relationship validation

Verify a 20-task sample of parent-subtask links resolves correctly. Open each subtask and confirm its parent matches the source.
Risk if skipped: Broken parent links orphan subtasks visually under the project root, making them effectively invisible to the assignee.
Verify dependencies: open the predecessor of 10 sample tasks and confirm the blocking list contains the right successor. Dependencies established via the CSV "Dependent on" column should resolve in the task pane.
Verify attachments resolve: open 20 sampled tasks and confirm every attachment opens. Check both Asana-hosted re-uploads and external-storage links.
Risk if skipped: External links broken by post-migration storage permission changes (Drive folder moves, Box sharing changes) silently 404 with no surface alert in Asana.
Verify multi-homed tasks appear in every project they belong to. Asana lets one task live in multiple projects; if the source had similar multi-home behavior, confirm the import recreated each project membership.
Verify followers / collaborators on a sample of tasks resolved to existing destination users. Unresolved follower emails fail silently at import.

6c. Audit and compliance

Verify the original-creation-date strategy worked: open a sample of imported tasks and confirm "Source Created On" matches the source. If this field is empty on any sample task, the transform pipeline regressed.
Risk if skipped: Empty Source Created On on imported tasks means cutover-day-only timestamps and broken aging reports across every project.
Verify completed-task history: confirm Source Completed On is populated on every imported closed task. Spot-check against the source export.
Pull the Audit Log for the import window and confirm no unexpected event types. Audit log access is restricted to Service Accounts on Enterprise+, legacy Enterprise, or Enterprise with the Compliance Management Add-on; events are retained for 90 days.
Confirm data residency: if EU residency was elected, confirm task data is stored in the Frankfurt region. Customer task data including comments and attachments respects residency; user authentication and seat-count telemetry do not.
Risk if skipped: Residency misconfiguration discovered after live use creates a regulatory exposure that requires re-migrating the domain through Asana's data migration request flow.
Confirm retention policies: if data retention is enabled, validate inactivity rules match policy. The data retention feature targets inactive projects and orphan tasks; recovery window is 30 days from trashing.

6d. User acceptance

Have 3–5 power users per team walk through their day-one workflows in the destination. My Tasks view, project board view, completing a task, posting a comment, attaching a file, filtering by custom field.
Risk if skipped: Defects only visible inside daily workflow (broken filters, missing fields on board view) ship to users if power users do not catch them first.
Capture every defect in a tracking project with severity, owner, and target fix date. Severity 1 (blocking workflow) gets fixed before go-live; severity 2 and 3 ship as known issues with comms.

6e. Sign-off

Obtain written sign-off from the migration sponsor and each functional lead before Phase 7. Sign-off references the success criteria documented in Phase 0.
Risk if skipped: Skipping written sign-off makes the project owner the implicit owner of every post-migration data defect forever.

Phase 7

Post-Migration Cleanup

Wrap up so the team can move on; the source is not retired until this phase closes.

Watch list

Risks to track throughout

These risks live across multiple phases — keep an eye on them from kickoff through cutover.

Audit-trail re-stamping at import

Every CSV-imported task is stamped with creation date equal to the import moment, and every imported "completed" task lands open unless a destination Rule re-marks it. These two behaviors break aging reports and completion dashboards from day one if the Phase 3 "Source Created On" and "Source Completed On" custom-field plus Rule pattern is not applied. Validate them in Phase 6 before sign-off, not after users start filing tickets.
Rules, Bundles, Forms, Portfolios, and Goals do not migrate via CSV

The CSV Importer covers tasks, subtasks (to 5 levels), sections, custom fields, dependencies, and assignees. Everything else — automation logic, intake forms, cross-project rollups, goal hierarchies, and reports — is rebuilt manually in Phase 7. Underestimating that rebuild is the single most common reason cutovers ship on time but adoption stalls at 30 days. Treat Phase 7 as in-scope work, not afterwork.
Asana platform caps compound across rehearsals and re-runs

The 5-level subtask cap, the 500-option dropdown cap, the 150-fields-per-project cap, and the 100 MB per-file cap reward sizing jobs to fit headroom rather than running them at maximum throughput. Track cumulative bulk operations from Phase 4 onward and pace loads to stay within platform tolerances.
Tier-gated features assumed but not licensed

EU data residency, Sandboxes, Service Accounts, the audit log, the CSV user import, and parts of Compliance Management are gated to Advanced, Enterprise, or Enterprise+ tiers. Confirm the destination domain's exact tier in Phase 0 and re-check before each phase. A tier downgrade or a misread of the pricing matrix mid-project forces either a costly upgrade under deadline pressure or a re-scope of the migration plan.

monday Work Management→Asana Trello→Asana Jira→Asana Microsoft Project→Asana

See Asana migration overview All Project Management migrations Estimate your migration

POPULAR PLATFORMS

POPULAR MIGRATIONS

POPULAR PLATFORMS

POPULAR MIGRATIONS

POPULAR PLATFORMS

POPULAR MIGRATIONS

POPULAR PLATFORMS

POPULAR MIGRATIONS

POPULAR PLATFORMS

POPULAR MIGRATIONS

Migration Checklist: Moving to Asana

Decide & Plan

Pre-Migration Prep

1a. Source-system audit and cleansing

1b. Destination setup

1c. People prep

Source Export

Transform & Map

3a. Mapping spreadsheet

3b. Data transformation

3c. Audit-trail and ownership decisions

3d. PM-specific transforms

Sandbox Test Migration

Production Cutover

Validate

6a. Reconciliation

6b. Relationship validation

6c. Audit and compliance

6d. User acceptance

6e. Sign-off

Post-Migration Cleanup

Risks to track throughout

The complete Asana migration guide

Migration Checklist: Moving to Asana

Decide & Plan

Pre-Migration Prep

1a. Source-system audit and cleansing

1b. Destination setup

1c. People prep

Source Export

Transform & Map

3a. Mapping spreadsheet

3b. Data transformation

3c. Audit-trail and ownership decisions

3d. PM-specific transforms

Sandbox Test Migration

Production Cutover

Validate

6a. Reconciliation

6b. Relationship validation

6c. Audit and compliance

6d. User acceptance

6e. Sign-off

Post-Migration Cleanup

Risks to track throughout

Common migrations to Asana

The complete Asana migration guide