Project Management migration
Field-level mapping, validation, and rollback between Antura and Asana. We move data and schema; workflows are rebuilt natively in Asana.
Antura
Source
Asana
Destination
Compatibility
7 of 12
objects map 1:1 between Antura and Asana.
Complexity
BStandard
Timeline
4-6 weeks
Overview
Moving from Antura to Asana requires navigating a platform whose core difference is API access. Antura offers no publicly documented REST or bulk API endpoint, forcing all data extraction through CSV exports from the application UI. This means migration timelines are longer than API-native platforms, with a manual extraction phase for each major object type. Antura organizes work in a flat task hierarchy under Projects and Sub-projects, while Asana supports tasks with subtasks, multiple project views (List, Board, Timeline, Calendar), and milestone tracking. We handle the CSV extraction coordination, Swedish-language field name mapping, custom field schema discovery (Antura allows per-organization customization), and resource-to-Asana-member resolution. Portfolio structures in Antura map to Asana Portfolios on the Business tier or to a team-grouping convention on lower tiers. Workflow configurations, project templates, and document version histories do not migrate; we deliver a written inventory of these for the customer's admin to rebuild in Asana Rules and project templates post-migration.
Every standard and custom field arrives verified.
AI proposes the map; you confirm before any record moves.
Parent–child, lookups, and ownership stay linked.
Calls, emails, meetings — with original timestamps.
Documents, uploads, and inline notes move with the record.
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a Antura object lands in Asana, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
Antura
Project
Asana
Project
1:1Antura Projects map to Asana Projects with project name, description, start date, due date, status, and owner preserved. Antura's project status workflows map to Asana project status indicators (on track, at risk, off track). Owner resolution happens via email match against Asana workspace members; any owner without a matching Asana user enters a reconciliation queue for the customer's admin to provision before record import.
Antura
Sub-project
Asana
Project (nested under parent) or Section
1:1Antura Sub-projects map to Asana Projects nested under the parent Project, or to Asana Sections if the customer prefers a flatter structure. We resolve the parent-child relationship using Antura's project hierarchy export and create either sub-Projects or Sections based on the customer's scoping preference. Sub-project metadata (dates, budget, owner) map to the destination project fields.
Antura
Task
Asana
Task
1:1Antura Tasks map to Asana Tasks with title, description, assignee, start date, due date, and status preserved. Antura's flat task structure maps directly to Asana's task model. Any task flagged as a milestone in Antura maps to an Asana Milestone (Premium+ required). Tasks without an assignee in Antura become unassigned tasks in Asana; we preserve the original task owner in a custom field antura_owner__c for audit.
Antura
Milestone
Asana
Milestone
1:1Antura Milestones map to Asana Milestones on Premium tier and above. Milestone dates and names migrate directly. Antura milestones without a linked project map to a default Asana project designated during scoping. Note that Asana does not support milestones on the Free plan; we flag this and recommend upgrading to Premium or placing milestones in a separate tracking project on lower tiers.
Antura
Resource
Asana
User (workspace member)
1:1Antura Resources (employees with capacity, skills, cost rates, and utilization) map to Asana workspace members. We extract the Antura resource list and match by email address to Asana users. Capacity and utilization percentages migrate to a custom field resource_capacity__c on the user's Asana profile or to a custom project-level field. Cost rates migrate to a custom field cost_rate__c. Skills migrate to a multi-select picklist custom field skills__c if the customer requests it during scoping.
Antura
Time Entry
Asana
Task (with time tracking)
1:1Antura Time Entries (hours, date, description linked to Tasks or Projects) map to Asana Tasks with time entries. On Asana Premium and above, we use Asana's native time tracking feature to log hours against tasks. On lower tiers, we create a custom time_tracked_hours__c numeric field and a time_entry_date__c date field per task, with a separate Time Entries report delivered as a CSV for the customer's admin to import into a time-tracking integration like Toggl or Harvest post-migration.
Antura
Risk
Asana
Task (with risk classification)
1:manyAntura Risks (severity, probability, owner, mitigation fields) map to Asana Tasks with a risk_type__c custom field set to 'Risk'. Risk severity maps to priority (high = urgent, medium = high, low = normal). Probability percentage maps to risk_probability__c custom field. Mitigation description migrates to the task description with a 'Mitigation' section. We recommend a dedicated Asana project for risk tracking so risks aggregate in a single portfolio view.
Antura
Issue
Asana
Task (with issue classification)
1:manyAntura Issues (severity, owner, description fields) map to Asana Tasks with an issue_type__c custom field set to 'Issue'. Issue severity maps to priority. The original Antura issue description migrates to the task description. Issues and Risks split into separate task types so the customer can filter by type in Asana's project views.
Antura
Portfolio
Asana
Portfolio or Team grouping
lossyAntura Portfolios (grouping Projects with priority, status, and strategic alignment) map to Asana Portfolios on Business tier ($24.99/user/month). On lower tiers, we map portfolio membership to Asana Teams with a naming convention (e.g., 'Portfolio - Strategic Initiatives') and add a portfolio_priority__c custom field to each project. Strategic alignment fields map to a custom field strategic_alignment__c text field. We recommend the Business tier for organizations that rely heavily on portfolio-level reporting.
Antura
Cost Record
Asana
Custom fields on Project or Task
1:1Antura Cost Records (estimates, budgets, actuals, forecasts per Project) map to numeric custom fields on the Asana Project: cost_estimate__c, cost_budget__c, cost_actual__c, cost_forecast__c. Multi-currency handling requires the customer to confirm their Asana workspace currency setting during scoping; we note that Asana does not natively support multi-currency so conversions use the exchange rate at migration date.
Antura
Document (metadata)
Asana
File attachment reference
lossyAntura Document metadata (name, type, date, owner) migrates to a document registry CSV delivered to the customer. Actual binary files cannot transfer through standard data migration methods because Antura stores documents as binary attachments without a documented file access API. We recommend the customer export documents from Antura to a shared cloud location (Google Drive, SharePoint, Dropbox) and reattach them to Asana tasks post-migration. We provide a document mapping table linking Antura document IDs to Asana task targets.
Antura
Custom Field (per-organization)
Asana
Custom Field (per-project)
lossyAntura custom fields (organization-specific fields on Projects, Tasks, and Resources) require a discovery phase before migration because Antura has no public metadata API for external schema introspection. We guide the customer through a full custom field export from Antura's admin interface, map each field to an Asana custom field, and configure custom field settings per project in Asana. Field types (text, number, date, dropdown, checkbox) map to Asana custom field types. Any custom field without a clear Asana equivalent enters a mapping exception list for the customer's admin to resolve.
| Antura | Asana | Compatibility | |
|---|---|---|---|
| Project | Project1:1 | Fully supported | |
| Sub-project | Project (nested under parent) or Section1:1 | Fully supported | |
| Task | Task1:1 | Fully supported | |
| Milestone | Milestone1:1 | Fully supported | |
| Resource | User (workspace member)1:1 | Fully supported | |
| Time Entry | Task (with time tracking)1:1 | Fully supported | |
| Risk | Task (with risk classification)1:many | Fully supported | |
| Issue | Task (with issue classification)1:many | Fully supported | |
| Portfolio | Portfolio or Team groupinglossy | Fully supported | |
| Cost Record | Custom fields on Project or Task1:1 | Fully supported | |
| Document (metadata) | File attachment referencelossy | Fully supported | |
| Custom Field (per-organization) | Custom Field (per-project)lossy | Fully supported |
Gotchas + challenges
Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.
Antura gotchas
Custom field schema discovery requires manual scoping
No public API documentation for bulk export
Document attachments require separate file transfer
Swedish-language interface affects default field names
Asana gotchas
Automation rules have no export representation
API rate limits cap bulk migration throughput
Portfolios are view-only objects that do not hold data
Custom field enum options cannot be updated via API
Subtasks do not appear in project views by default
Pair-specific challenges
Migration approach
Discovery and CSV extraction planning
We conduct a scoping call to audit the customer's Antura instance: object counts (Projects, Sub-projects, Tasks, Resources, Risks, Issues, Milestones, Time Entries, Documents), custom field schema inventory, Antura instance language setting, and any non-standard configurations. We deliver a CSV extraction guide that walks the customer's Antura admin through exporting each object type with the correct column headers and delimiter settings. We also identify any Antura consultant-managed API access that could accelerate extraction. The discovery output is a written migration scope, CSV extraction checklist, and Antura-to-Asana custom field mapping table.
Custom field schema discovery and mapping
Because Antura allows per-organization custom field creation with no public metadata API, we guide the customer through a full custom field inventory export from Antura's admin interface. We map each Antura custom field to an Asana custom field type (text, number, date, enum, multi-enum) and configure custom field settings per Asana project. Field dependencies (e.g., a dropdown field that feeds a reporting dashboard) are documented and carried forward. We flag any Antura custom field without a clear Asana equivalent in a mapping exception list for the customer to resolve during the sandbox validation phase.
Sandbox migration and reconciliation
We run a full migration into the customer's Asana workspace (or a designated sandbox project) using production-like data volume from the CSV exports. The customer reconciles record counts, spot-checks 25-50 random records against the Antura source, and validates that custom fields display correctly per project. Swedish-language field name mapping is validated in this phase. The customer signs off the mapping and schema before production migration begins. Any mapping corrections, custom field type adjustments, or portfolio grouping decisions happen here, not in production.
Resource and user mapping
We extract every distinct Antura Resource and match by email against the Asana workspace member list. Resources without a matching Asana user enter a reconciliation queue. The customer's admin provisions missing Asana users (active or inactive depending on whether the original Antura resource is still active). Capacity, utilization, and cost rate fields are mapped to custom fields on the user's profile or project. Skills migrate to a multi-select custom field. Owner resolution must complete before project and task import because OwnerId is a required reference on most Asana records.
Production migration in dependency order
We run production migration in record-dependency order: Users (manual provisioning validated), Projects (with status and dates), Sub-projects (linked to parent Projects), Milestones (linked to Projects; Premium+ required), Tasks (with assignee, dates, and custom fields), Risks and Issues (as typed tasks with classification custom fields), Time Entries (as native time tracking on Premium+ or custom fields on lower tiers), and Cost Records (as numeric custom fields on Projects). Document metadata migrates to a registry CSV with reattachment instructions. Each phase emits a row-count reconciliation report before the next phase begins.
Cutover, validation, and template rebuild handoff
We freeze Antura writes during cutover and run a final delta migration of any records modified during the migration window. We enable Asana as the system of record and deliver a project template inventory document listing every Antura project template structure requiring rebuild in Asana. We also deliver a workflow inventory (if Antura workflow configurations exist) with recommended Asana Rules equivalents for the customer's admin to rebuild. We support a one-week hypercare window where we resolve any reconciliation issues. We do not rebuild Antura workflows or project templates as Asana automations inside the migration scope; that is a separate engagement or an internal admin task.
Document file transfer coordination
We provide a document mapping table linking each Antura document (by internal ID) to its target Asana project or task. The customer exports Antura documents to a shared cloud location and reattaches them to Asana tasks. We provide step-by-step reattachment instructions and a file-naming convention that matches the mapping table. For organizations with over 500 documents, we recommend a bulk file-transfer tool (Google Drive migration tools, SharePoint migration assistant) and provide the mapping CSV as input to that process.
Platform deep dives
Antura
Source
Strengths
Weaknesses
Asana
Destination
Strengths
Weaknesses
Complexity grading
Standard Project Management migration. 2 of 8 objects need a mapping; the rest are 1:1.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across Antura and Asana.
Object compatibility
2 of 8 objects need a mapping; the rest are 1:1.
Field mapping clarity
Field mapping is derived from defaults — final spec confirmed during the sample migration.
Timeline complexity
8-object category — typical timelines run 2–7 days end-to-end.
API constraints
Antura: Not publicly documented.
Data volume sensitivity
Antura doesn't expose a bulk API — REST + parallelization used for high-volume runs.
Estimator
Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.
Step 1
Pick a category, then your source and destination platforms.
Category
FAQ
Answers to the questions buyers ask most during Antura to Asana migration scoping. Not seeing yours? Book a call.
Walk through your Antura to Asana migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave Antura
Other ways to arrive at Asana
Same-Project Management migrations
Ready when you are
Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.