Migrate your ProjectManager data
Cloud-based project and portfolio management SaaS built for enterprise PMOs that need real-time dashboards, resource scheduling, and automated cost tracking across multiple simultaneous projects.
In its favor
Why people choose ProjectManager
The signal that keeps ProjectManager on the shortlist. Sourced from G2, Capterra, and customer scoping calls.
Real-time portfolio dashboards that aggregate time, cost, and workload across all active projects without requiring manual refresh or separate exports.
Advanced scheduling engine that handles task dependencies and automatically cascades date changes when upstream tasks shift.
Automated time and cost tracking built into the platform, eliminating the need for separate timesheet tools in simple deployments.
Resource management views that show team workload color-coded by allocation, flagging overloaded assignees across the portfolio.
Enterprise-tier security including SAML SSO and MFA, making it suitable for regulated industries requiring centralized identity management.
The mobile app is described as a lite version of the desktop interface, frustrating field teams who need full Gantt and task functionality on-site.
New users report a steep learning curve with no guided onboarding flow, leading to low adoption in organizations that skip formal training.
Report customizations and forecasting capabilities are limited compared to purpose-built BI tools, limiting insight depth for data-driven PMOs.
The interface is described as cluttered with an outdated aesthetic, particularly compared to newer visually-driven alternatives like monday.com or Asana.
Integration with external CRMs, ERPs, or time-tracking tools often requires expensive add-ons not included in base licensing.
Reasons to switch
Why people leave ProjectManager
The recurring reasons buyers give for replacing ProjectManager. Presented as facts, not knocks.
Platform scorecard
Strengths, weaknesses, and where ProjectManager fits
Grades across six dimensions, plus a SWOT-style view of where the platform shines and where it falls short.
SWOT — strengths, weaknesses, and use-case fit
Strengths
Weaknesses
Where it works
Where it struggles
Pricing tiers
ProjectManager pricing overview
ProjectManager uses three named tiers—Pro, Business, and Enterprise—with pricing upon request rather than publicly listed per-seat rates. Enterprise includes enhanced security, SSO, and volume-based collaborator roles, while lower tiers are licensed per user with core project and portfolio features gated across tiers.
Pro
Tier 1 of 3
Pricing upon request (per user/month, tiered)
What's included
Need help selecting your Project Management?
Book a free 30 minute consultationPricing is informational. FlitStack AI does not bill on ProjectManager's schedule — see our quote-based pricing →
What gets migrated
ProjectManager object support
Object-by-object support for ProjectManager migrations. Per-pair details surface during scoping.
Projects
Fully supportedProjects are the top-level container in ProjectManager's data model. Each Project has standard fields (name, dates, status) plus optional custom ProjectFields. We migrate all standard fields 1:1 and preserve custom field definitions as ProjectField records before importing field values.
Tasks
Fully supportedTasks belong to Projects and support parent-child hierarchies, dependencies, and TaskStatus values. The API exposes TaskFields and TaskMetadata. We reconstruct the WBS structure and preserve TaskStatus state across the migration.
TaskAssignees
Fully supportedTaskAssignees link Resources to Tasks and drive the workload view. We map assignee records from the source system to Resources in the destination Workspace, maintaining the assignment relationship through the API.
ProjectFields
Mapping requiredProjectFields are custom properties scoped to the Workspace. Field types include string, number, date, and choice. We discover existing ProjectField definitions via GET /api/data/projects/fields and map source custom fields to matching definitions or create new ones as needed.
TaskFields
Mapping requiredTaskFields work identically to ProjectFields but are scoped to Tasks. We handle both field definitions and per-record values using PUT /api/data/projects/{projectId}/fields/{fieldId}. Not all PM platforms expose per-task custom fields; we flag this gap during scoping.
Resources
Fully supportedResources represent team members or equipment. They can have ResourceSkills and belong to ResourceTeams. We map Resources from the source system, preserving availability windows and cost rates where exposed.
ResourceTeams
Fully supportedResourceTeams group Resources for reporting and scheduling. We preserve team memberships and cross-reference with TaskAssignees to ensure workload views are accurate post-migration.
Risks
Fully supportedRisks are standalone objects linked to Projects. Each Risk can have RiskFiles attached. We migrate all open Risks and preserve their severity, status, and linked ProjectId.
Timesheets
Mapping requiredTimesheets record actual hours logged by Resources against Tasks. Billing rates are sometimes embedded in historical Timesheet records. We flag Timesheet data during discovery because rate structures vary widely between platforms.
Tags
Fully supportedTags and TaskTags are lightweight labeling objects. We preserve tag names and associations as simple string values that map to the destination platform's tagging schema.
Teams
Fully supportedTeams is a distinct organizational object separate from ResourceTeams. We map team memberships to match source access patterns.
UserRoles
Mapping requiredUserRoles define permissions within a Workspace. Role definitions are proprietary to ProjectManager. We map source permission profiles to the closest matching built-in role, flagging custom role requirements for manual post-migration setup.
| Object | Support | Notes |
|---|---|---|
| Projects | Fully supported | Projects are the top-level container in ProjectManager's data model. Each Project has standard fields (name, dates, status) plus optional custom ProjectFields. We migrate all standard fields 1:1 and preserve custom field definitions as ProjectField records before importing field values. |
| Tasks | Fully supported | Tasks belong to Projects and support parent-child hierarchies, dependencies, and TaskStatus values. The API exposes TaskFields and TaskMetadata. We reconstruct the WBS structure and preserve TaskStatus state across the migration. |
| TaskAssignees | Fully supported | TaskAssignees link Resources to Tasks and drive the workload view. We map assignee records from the source system to Resources in the destination Workspace, maintaining the assignment relationship through the API. |
| ProjectFields | Mapping required | ProjectFields are custom properties scoped to the Workspace. Field types include string, number, date, and choice. We discover existing ProjectField definitions via GET /api/data/projects/fields and map source custom fields to matching definitions or create new ones as needed. |
| TaskFields | Mapping required | TaskFields work identically to ProjectFields but are scoped to Tasks. We handle both field definitions and per-record values using PUT /api/data/projects/{projectId}/fields/{fieldId}. Not all PM platforms expose per-task custom fields; we flag this gap during scoping. |
| Resources | Fully supported | Resources represent team members or equipment. They can have ResourceSkills and belong to ResourceTeams. We map Resources from the source system, preserving availability windows and cost rates where exposed. |
| ResourceTeams | Fully supported | ResourceTeams group Resources for reporting and scheduling. We preserve team memberships and cross-reference with TaskAssignees to ensure workload views are accurate post-migration. |
| Risks | Fully supported | Risks are standalone objects linked to Projects. Each Risk can have RiskFiles attached. We migrate all open Risks and preserve their severity, status, and linked ProjectId. |
| Timesheets | Mapping required | Timesheets record actual hours logged by Resources against Tasks. Billing rates are sometimes embedded in historical Timesheet records. We flag Timesheet data during discovery because rate structures vary widely between platforms. |
| Tags | Fully supported | Tags and TaskTags are lightweight labeling objects. We preserve tag names and associations as simple string values that map to the destination platform's tagging schema. |
| Teams | Fully supported | Teams is a distinct organizational object separate from ResourceTeams. We map team memberships to match source access patterns. |
| UserRoles | Mapping required | UserRoles define permissions within a Workspace. Role definitions are proprietary to ProjectManager. We map source permission profiles to the closest matching built-in role, flagging custom role requirements for manual post-migration setup. |
Gotchas
What to watch for in ProjectManager migrations
Issues we've hit on past ProjectManager migrations, tagged by severity. FlitStack AI handles every one — surfacing them up front because buyer engineering teams want to know.
Custom field migration requires two-step API process
Dynamic scheduling recalculates dates during import
Historical timesheet billing rates vary by source
ResourceTeam vs Teams object distinction
| Severity | Issue |
|---|---|
| Medium | Custom field migration requires two-step API process |
| Medium | Dynamic scheduling recalculates dates during import |
| Low | Historical timesheet billing rates vary by source |
| Low | ResourceTeam vs Teams object distinction |
Leaving ProjectManager?
Where ProjectManager customers move next
5 destinations ProjectManager can migrate to.
How a ProjectManager migration works
Four steps, ProjectManager-specific
Connect
Bearer token into ProjectManager. Scopes limited to read-only on the data we move.
Map
We translate ProjectManager-specific structures (custom fields, objects, value lists) to the destination's model.
Sample
Test with a 50–200 record subset to validate ProjectManager quirks before production.
Migrate
Full migration with ProjectManager rate-limit handling. Rollback available throughout.
FAQ
ProjectManager migration FAQ
Answers to the questions buyers ask most during ProjectManager migration scoping. Not seeing yours? Book a call.
Can't find your answer?
Walk through your ProjectManager migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationOther project management tools we support
Ready when you are
Migrate ProjectManager.
Without the rebuild.
Free scoping call with a migration engineer. Tell us about your ProjectManager setup and destination — written quote back within a business day.