Migrate your Planview AdaptiveWork data

Projects are the primary container in AdaptiveWork, supporting custom fields, baseline schedules, financial tracking, and resource assignments. We preserve all standard fields plus custom properties during migration and maintain the Project ID as the primary key for downstream dependency mapping.

Tasks are the core work unit and support unlimited nesting via parent-child links, allowing grandchild tasks under Projects. We migrate the full task hierarchy preserving predecessor/successor dependencies and preserving custom fields. Picklist-type custom fields display on card views; free-text custom fields do not—this is handled as a post-migration configuration note.

Milestones are tracked as date-driven entities that can be associated with Projects or Tasks. Roadmap visibility is a separate configuration from the Milestone record itself. We preserve milestone dates, names, and associations, but roadmap display settings must be reconfigured in the destination system.

Users in AdaptiveWork include email, name, role, and working calendar definitions. We map User records preserving the system ID as a foreign key so that task assignments and resource allocations resolve correctly in the destination system.

Custom fields are widely supported and highly configurable across entity types. However, picklist fields and free-text fields behave differently in UI rendering (picklists appear on hybrid view cards; free-text does not). We migrate all custom field definitions and values as structured data, flagging picklist-vs-free-text differences for the customer to validate post-migration.

Workflow Rules automate actions based on criteria such as status changes, field updates, or date thresholds. These are custom configurations that may not have a direct equivalent in destination platforms. We export the rule definitions and flag whether equivalent automation exists in the target system.

Validation Rules enforce data quality at the entity level and do not fire on the AdaptiveWork mobile app—a known limitation. We document all validation rules during scoping and map them to equivalent constraints or automation in the destination where possible.

Task-to-task predecessor/successor dependencies are preserved as structured links. We resolve dependency chains during migration to ensure that schedule logic in the destination system reflects the original project logic.

Documents are managed via SharePoint or Box integration in AdaptiveWork. The document references (URLs, share paths) can be migrated, but the actual files must be transferred separately via the source document system. We flag this dual-track approach upfront.

Time entries in AdaptiveWork track labor against Tasks and Projects and support approval workflows. We migrate time entry records with their task association and date, preserving the financial data needed for billing and reporting in the destination.

AdaptiveWork tracks budget, costs, and revenue at the Project level. We migrate financial line items preserving amounts, cost types, and budget-vs-actual comparisons. Currency handling and exchange rates must be confirmed during scoping.

Customers is a module for linking Projects to external client organizations. The destination CRM may model these as Accounts, Contacts, or a custom object. We map the customer entity and its project associations to the destination structure.

Project and task templates in AdaptiveWork encapsulate workflow structure, default fields, and pre-populated tasks. We export template definitions, but template-as-structure must be rebuilt in destination systems that do not support template importing.

Resource capacity planning uses user working calendars, skills, and availability to calculate workload distribution. The underlying allocation data migrates, but capacity-planning algorithms are platform-specific and must be reconfigured in the destination.