Migrate from Planisware Enterprise to Microsoft Project

Planisware Project records map to Microsoft Project plans or Project Online projects. We preserve project name, start date, finish date, WBS code, task hierarchy, and owner assignment during XML export. The Planisware project status workflow (custom states like 'Proposal', 'Approved', 'On Hold') maps to a Microsoft Project custom field or status flag we configure during import. Active vs. archived project filtering happens during the export query so that only current projects migrate.

Planisware Portfolios have no native Microsoft Project equivalent. We extract the portfolio-to-project membership table from Planisware, then map each portfolio-project relationship to a SharePoint Online list (with project name, portfolio name, and status columns) or an Enterprise Project Type filter in Project Online Project Center. We deliver a written portfolio hierarchy document listing every portfolio, its member projects, and the recommended SharePoint or Project Center structure to recreate the relationship in the destination.

Planisware Resources map to Microsoft Project Resources. We preserve resource name, type (material vs. work), Max Units (capacity percentage), Standard Rate, and Overtime Rate from Planisware's resource pool. Resource calendars (PTO, holidays, working time exceptions) migrate as Project calendar entries. Planisware's skill profiles and cost rates transfer to custom resource fields in Microsoft Project since Project does not have a native skill matrix object.

Planisware Activities map to Microsoft Project Tasks. We preserve task name, start and finish dates, duration, work (hours), WBS hierarchy, and assignment rows linking tasks to resources. Task constraints ('Do Not Start Before', 'Must Finish On', etc.) migrate as Project constraint types. We flatten Planisware's deep WBS hierarchies (which can exceed Microsoft Project's 10-level cap) into a compatible structure and note any overflow tasks for manual reorganization post-migration.

Planisware task-to-task and project-to-project dependencies map to Microsoft Project task dependency links (Finish-to-Start, Start-to-Start, etc.). We extract the full dependency graph from Planisware's link table and recreate links by task name match in the destination. The 20-link-per-task ceiling in Microsoft Project requires a consolidation step: tasks with more than 20 dependencies are flagged in the scoping report, and the customer decides which links to preserve as the primary schedule drivers, with the remainder documented for manual re-creation.

Planisware financial objects (budgets, actuals, forecasts, cost codes) store in cost fields and custom fields in Microsoft Project. We map Planisware cost code values to Project cost fields (Cost1-Cost10) and use custom text or number fields for non-monetary financial attributes. Baseline costs migrate to Project baseline fields. The Planisware financial coding structure (often a multi-segment code like 'DEPT-PROGRAM-ACTIVITY') maps to a custom WBS prefix or text field, not to a native Project cost breakdown structure.

This is the highest-risk mapping in the migration. Microsoft Project Online enforces a hard limit of 10 enterprise custom fields per project. Planisware Enterprise implementations routinely exceed 10 custom fields per project. We conduct a custom field audit during scoping, rank fields by usage frequency and business criticality, and select the top 10 for import. Fields that exceed the limit are documented in a custom field gap report with their source values, and the customer rebuilds the overflow in a SharePoint Online list or Power Apps companion application post-migration. Project Desktop local fields do not have this ceiling and are an option for flat-file migration without Project Online.

Planisware custom status workflows (often with stages like 'Concept', 'In Planning', 'In Execution', 'On Hold', 'Closed') are implementation-specific. We map each active Planisware status to a value in a Microsoft Project custom picklist field. Status transition rules (which roles can approve which transitions) do not migrate; we deliver a written status workflow map listing every status, its valid transitions, and the recommended Project Online status field configuration to preserve the same visual workflow in SharePoint or Power Apps.

Planisware calendars (working time, exceptions, holidays, shift patterns) migrate to Microsoft Project base calendars and calendar exceptions. Resource-specific calendars (when different teams have different working hours) map to resource calendars in Microsoft Project. We preserve holiday calendars, PTO exceptions, and non-standard working weeks as calendar exceptions.

Planisware document blobs are stored in a proprietary format inaccessible outside the Planisware application. We extract document metadata (filename, linked project, linked activity, upload date, uploader) and map it to a SharePoint Online document library structured by project. The customer extracts the original files from Planisware's file store separately and uploads them to the SharePoint library using the provided metadata manifest as a naming and foldering guide. Document content does not migrate.

Planisware Users mapped as project or activity owners migrate to Microsoft Project Resources with the resource type set to Material for non-time-tracking users and Work for resources who log time. We resolve owners by email match. Any Planisware user without a corresponding Microsoft 365 account or Project Online user goes to a reconciliation queue for the customer's admin to provision before final import. Role and permission assignments do not migrate since Project Desktop and Project Online use separate permission models from Planisware's role-based access control.