Migrate from Planview AdaptiveWork to Microsoft Project

AdaptiveWork Projects map to Microsoft Project schedule files (.mpp for desktop or Project Online project plans). The AdaptiveWork project name, start date, finish date, baseline schedule, and all standard project-level fields migrate as summary-level project properties. Financial management fields (budget, cost types, revenue) have no native Microsoft Project equivalent and are documented as custom fields requiring manual post-migration setup. The project status field from AdaptiveWork does not map to a standard Microsoft Project field and is preserved as a custom field on the project summary task.

AdaptiveWork Tasks map to Microsoft Project tasks with the full parent-child hierarchy preserved. Unlimited nesting in AdaptiveWork translates to the outline structure in Microsoft Project where summary tasks contain subtasks. We resolve the hierarchy by following the parent-object link chain from AdaptiveWork and building the corresponding WBS outline in Microsoft Project. Duration, start date, finish date, and the predecessor-successor chain migrate directly. We flag that the duration-versus-work calculation mismatch documented in AdaptiveWork's own community (where a fixed-duration task recalculates work differently on import) is resolved by setting the Microsoft Project task to Fixed Duration before import to match the source calculation behavior.

AdaptiveWork Milestones map to Microsoft Project tasks with Duration = 0 and the Milestone flag set to Yes. Milestone dates migrate as the task Finish Date. Note that Milestones and Custom Objects in AdaptiveWork are separate entity types that cannot be blended in a single grid view—Microsoft Project similarly keeps milestones as task-level markers rather than a separate object type. The Roadmap visibility configuration from AdaptiveWork has no Microsoft Project equivalent and is documented for the customer's PMO to rebuild as a separate view or Power BI report.

AdaptiveWork Users map to Microsoft Project resources. We extract the name, email, role, and working calendar definition from each AdaptiveWork User record. The working calendar in AdaptiveWork (which drives capacity planning and work-hour calculations) translates to the resource calendar in Microsoft Project. However, AdaptiveWork's automated capacity modeling using regional and personal working calendars does not migrate as an algorithm—only the calendar definition itself moves. Resource rates from AdaptiveWork's cost rate matrix migrate to the resource Cost Rate table in Microsoft Project if the Business or Enterprise tier is the source.

AdaptiveWork resource assignments (linking a User to a Task with allocation percentage or hours) map to Microsoft Project assignments. We preserve the allocation percentage as the Units field and the assignment's planned hours as the Work field. The duration-versus-work calculation policy in AdaptiveWork (documented in Planview's own community as a source of import discrepancies) is resolved by setting Fixed Duration on the Microsoft Project task before assignment data loads, which prevents the platform from recalculating work based on a default effort-driven model.

Task-to-task predecessor-successor dependencies from AdaptiveWork map to Microsoft Project predecessor links. We resolve each dependency chain during migration by matching the successor task's predecessor field to the predecessor task's task ID in the destination file. Finish-to-Start, Start-to-Start, Finish-to-Finish, and Start-to-Finish dependency types from AdaptiveWork map to the corresponding Microsoft Project dependency types. Lag time and lead time from AdaptiveWork migrate as positive or negative day offsets in the predecessor link.

AdaptiveWork picklist-type custom fields map to Microsoft Project custom fields. We map the picklist values to the allowed values in a custom drop-down field. Note that picklist fields in AdaptiveWork render on hybrid view cards whereas free-text custom fields do not—this rendering distinction has no Microsoft Project equivalent since Microsoft Project does not have AdaptiveWork-style hybrid card views. We flag which picklist fields were used for card-level visibility so the customer can prioritize rebuilding those as visible columns in their Project Online views.

AdaptiveWork free-text custom fields map to Microsoft Project custom text fields. The content migrates as-is. We note that free-text fields in AdaptiveWork do not appear on card views by default—a known AdaptiveWork limitation that customers sometimes misinterpret as missing data. After migration, free-text values will appear as custom field columns in Microsoft Project's Task Sheet or Resource Sheet views, which may represent a visibility improvement over the source system.

AdaptiveWork documents are managed through SharePoint or Box connectors rather than stored natively. We migrate the document reference URL (the SharePoint path or Box share link) as a text value in a custom field. The actual file content must be transferred separately through the source document system's export function. We split the migration into a records track (handled by FlitStack AI for the URL references) and a files track (handled by a separate document migration step using SharePoint or Box's native export tools). For Microsoft Project Online destinations, we document how to re-link document references to the new SharePoint document library.

AdaptiveWork time entries linked to Tasks migrate as actual work values on the corresponding Microsoft Project assignments. We map the time entry date, hours, and task association, preserving the financial labor data for cost tracking. Note that Microsoft Project does not have an approval workflow for time entries—time entries migrate as historical actual work values rather than as pending approvals. If the customer requires time approval workflows, we document this as a Power Automate rebuild recommendation.

AdaptiveWork Custom Objects (gated behind Business and Enterprise tiers) have no direct Microsoft Project equivalent because Microsoft Project is a single-schedule data model rather than an entity-relationship platform. We handle this in two ways depending on the Custom Object's purpose: if it represents task-level attributes, we flatten the fields into custom task fields on the relevant tasks; if it represents a related entity with its own record lifecycle, we document the Custom Object schema and recommend either a SharePoint list, a Power Apps entry form, or a separate database as the receiving system.

AdaptiveWork baseline schedules (capturing the original planned start and finish dates at the time of baseline creation) map to Microsoft Project baseline fields. We migrate the baseline start and baseline finish for each task. Note that Microsoft Project supports multiple baseline slots (Baseline, Baseline1-Baseline10) whereas AdaptiveWork typically stores one active baseline. We map the primary AdaptiveWork baseline to Microsoft Project Baseline and flag whether the customer uses multiple baseline scenarios for what-if analysis, which would require manual slot selection post-migration.