Migrate from Planisware Enterprise to Asana

Planisware Projects map directly to Asana Projects. We extract standard fields including project name, description, start and end dates, status, owner assignment, and all active custom properties via file-based bulk export or oData API with conservative page sizing. The Asana Project workspace is determined during scoping based on team structure. Custom properties from Planisware become Asana Custom Fields on the project, preserving data type (text, number, date, person, or dropdown).

Planisware Portfolios map to Asana Portfolios, which are available from the Business tier ($24.99/user/mo) and above. We extract portfolio membership (member projects), portfolio-level budgets and strategic alignment attributes, and re-create the portfolio hierarchy in Asana. Portfolio goals and strategic flags migrate as Asana Custom Fields. Note that Asana Portfolios aggregate project-level data; they do not support nested sub-portfolios, so deeply nested Planisware portfolio hierarchies are flattened to a two-level structure.

Planisware Resource records map to Asana Users. We extract allocation percentages, skill profiles, and cost rates from Planisware and store allocation data as Asana Custom Fields on tasks assigned to the user. Planisware's capacity modeling (available hours, utilization percentage) migrates as a workload reference in a linked Custom Field. Note that Asana does not have a dedicated resource pool object; resource forecasting requires the Workload view in Asana Business or Enterprise, which is based on task assignment rather than a capacity ledger.

Planisware Activities and sub-activities map to Asana Tasks and Subtasks. We flatten the task tree during extraction and re-hydrate the hierarchy in Asana using Subtasks or Section groupings based on the customer's preference during scoping. Task status, priority, start and due dates, assignees, and description migrate. Task dependencies (Finish-to-Start, Start-to-Start, Finish-to-Finish) migrate to Asana Dependencies, which require the Enterprise tier on the destination.

Project-to-project and task-to-task dependencies are stored in a separate link table in Planisware. We extract the full dependency graph and recreate it in Asana using the native dependency feature, which supports Predecessor and Dependent task relationships. Asana dependencies require the Enterprise tier. If the customer is on Business or below, we document the dependencies as a Custom Field (text list of dependent task names) and note the rebuild requirement in the handoff document.

Planisware financial objects (cost codes, budgets, actuals, forecasts) have no direct Asana equivalent. We extract the financial ledger entries and re-map cost codes to a chart of accounts stored as Asana Custom Fields at the project level. Financial values (budget, actual, variance) migrate as Number-type Custom Fields. Customers with complex financial reporting requirements are advised to maintain a linked Google Sheets or Excel reference connected to the Asana project via the Google Sheets integration rather than relying on Asana's native numeric fields for ERP-style reporting.

Custom fields on any Planisware object are highly implementation-specific and require a pre-migration schema discovery phase. We catalog all active custom field definitions (field name, data type, picklist values, default values) and create the equivalent Asana Custom Field during destination schema setup. Dropdown fields map to Asana enum Custom Fields with the same options. Number fields map to Asana numeric Custom Fields. Text fields map to Asana text Custom Fields. Date fields map to Asana date Custom Fields. We flag any Planisware custom field that uses a data type Asana does not support (e.g., complex formulas, currency with live exchange rates) and propose a workaround during scoping.

Documents uploaded within Planisware are stored in a proprietary format and cannot be accessed without the Planisware application. We migrate document metadata (filename, linked object, upload date, file size) as Asana Custom Fields or a task description note. The document blobs themselves are not migrated. The customer must extract the original files from Planisware's document store separately and re-upload them to the migrated Asana tasks post-migration. We provide a re-upload script as part of the post-migration deliverables.

User accounts and owner assignments are extractable from Planisware. We resolve Planisware owners by email match against the destination Asana workspace members. Owners without a matching Asana User are held in a reconciliation queue for the customer's admin to provision before record import resumes. Role and permission structures from Planisware do not map directly to Asana's permission model; we document the current role assignments as a written inventory for the admin to reconfigure in Asana's member management and project permission settings.

Planisware's custom status workflows and pipeline stages vary by implementation. We map Planisware status values to Asana Sections within projects or to a Status-type Custom Field, depending on whether the customer uses the Planisware status as a filterable project-level attribute or a per-task workflow state. The customer approves the status mapping table during scoping. Automated status transitions (Planisware workflow rules) do not migrate; we document the current automation logic for rebuild in Asana Rules.

Planisware Risk and Issue objects migrate to Asana Tasks with a Risk/Issue type Custom Field to distinguish them from standard project tasks. Risk probability, impact, and mitigation dates migrate as additional Custom Fields (number and date types). The risk register migrates as a dedicated Asana project with tasks representing individual risks, allowing the project team to manage risk response actions within the same tool.

Change Requests in Planisware migrate to Asana Tasks with a Change Request type Custom Field. Change request ID, description, approval status, and implementation date migrate as Custom Fields. If the Planisware implementation tracks change request approval workflows, we document the workflow logic in the automation handoff inventory for rebuild in Asana Rules. Scope-change-linked tasks are connected via Asana dependencies to their originating change request task.