Project Management migration
Field-level mapping, validation, and rollback between Pegasus Systems and Microsoft Project. We move data and schema; workflows are rebuilt natively in Microsoft Project.
Pegasus Systems
Source
Microsoft Project
Destination
Compatibility
5 of 11
objects map 1:1 between Pegasus Systems and Microsoft Project.
Complexity
BStandard
Timeline
3-5 weeks
Overview
Moving from Pegasus Systems to Microsoft Project is a shift from an agency-management platform with integrated finance, time tracking, and client billing to a dedicated scheduling and resource management tool. Pegasus holds Jobs, Clients, Timesheets, Expenses, Invoices, and Media Campaigns; Microsoft Project stores Projects, Tasks (WBS), Resources, Assignments, Baselines, and custom fields inside an MPP file or Project Online PWA database. The migration requires a schema decision upfront: whether active projects come in as MPP files for desktop use or as Project Online PWA projects for web collaboration, since the delivery format changes how we handle custom fields, resource pools, and baselines. Pegasus has no documented public API, so we extract from Pegasus's native Excel export templates, parse the structured output, and chunk it into Microsoft Project XML or CSV import format. Financial data (invoices, expenses, accounts payable) has no native home in Microsoft Project and is flagged for an external reporting or accounting tool rebuild. Workflows and billing automations in Pegasus do not migrate; we deliver a written inventory of these for the customer's project manager to recreate manually or via Power Automate.
Every standard and custom field arrives verified.
AI proposes the map; you confirm before any record moves.
Parent–child, lookups, and ownership stay linked.
Calls, emails, meetings — with original timestamps.
Documents, uploads, and inline notes move with the record.
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a Pegasus Systems object lands in Microsoft Project, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
Pegasus Systems
Client
Microsoft Project
Custom Fields or SharePoint List
lossyPegasus Clients with contact information, campaign history, and performance analytics have no native equivalent in Microsoft Project. We map the primary client name and contact to a project-level custom field (Client Name, Client Contact) and store the full client record in a companion SharePoint List linked to the project site. If the destination is Project Online, the client metadata lives in a PWA enterprise custom field lookup table.
Pegasus Systems
Job
Microsoft Project
Project
1:1Pegasus Jobs are the project-level container holding timelines, task lists, and resource allocation data. Each Job maps to a Microsoft Project file (MPP or PWA project). Pegasus job status, start date, finish date, and custom properties migrate to Project-level custom fields. We extract task lists from Pegasus and reconstruct them as a WBS hierarchy in Microsoft Project, with Pegasus task order preserved as WBS outline position.
Pegasus Systems
Job Task List
Microsoft Project
Task (WBS hierarchy)
1:manyPegasus Jobs contain hierarchical task structures that map to Microsoft Project Tasks with a WBS outline. We parse the task hierarchy from the Pegasus export, set Task Name, Start, Finish, Duration, and Predecessors (where dependencies are expressed), and preserve the original Pegasus task order as WBS number. Task-level custom fields from Pegasus map to local Microsoft Project custom fields or enterprise custom fields depending on whether the destination is PWA.
Pegasus Systems
User / Owner
Microsoft Project
Resource
1:1Pegasus Users and Owners with role information map to Microsoft Project Resources. We extract all distinct Pegasus users referenced on Jobs, Timesheets, and Expenses, create a Resource record for each, and set the Resource Type (Material or Work). Max Units are set to 100% for named resources unless Pegasus timesheet utilisation data indicates otherwise. Resource rates are populated from Pegasus user role data where available.
Pegasus Systems
Job Resource Allocation
Microsoft Project
Assignment
1:1Pegasus Job resource allocation data maps to Microsoft Project Assignments. Each assignment links a Resource to a Task and carries Assignment Owner, percent allocation, and start/end dates. We compute Work (in hours) from Pegasus allocation percentages and project duration, and set Assignment Units to the Pegasus allocation fraction. Overtime work flags from Pegasus map to Assignment overtime fields where supported.
Pegasus Systems
Timesheet
Microsoft Project
Task Progress / Actual Work
lossyPegasus Timesheets with per-minute billable and non-billable flags have a structural mismatch in Microsoft Project. Project stores actual work against Assignments, not as a standalone timesheet object. We aggregate Pegasus timesheet entries by task and user, set Actual Work on Assignments, and mark the task Status Percent Complete from the aggregated timesheet data. Billable/non-billable flags are stored in custom fields. Note: Microsoft Project does not natively replace a timesheet approval workflow; Project Online requires a separate timesheet solution (Project Time or a third-party add-in).
Pegasus Systems
Expense
Microsoft Project
Task Cost / Custom Fields
lossyPegasus Expense records with vendor, amount, date, and job association have no native home in standard Microsoft Project. We map expense amounts to task-level Cost fields where a 1:1 expense-to-task relationship exists, and to project-level custom fields (Total Expenses, Budget Variance) for summary expense data. Full expense ledger with vendor detail is exported separately as a CSV for the customer to import into an accounting tool or Power BI.
Pegasus Systems
Invoice
Microsoft Project
Not migrated (finance gap)
lossyPegasus Invoices generated from job costs and timesheet data cannot migrate into Microsoft Project. Project has no invoice object. We extract invoice headers, line items, amounts, and payment status as a structured CSV export. The customer reconciles this with their new accounting or invoicing tool post-migration. Locked financial periods in Pegasus are flagged during scoping; we do not attempt to reopen or re-post to locked periods.
Pegasus Systems
Media Campaign
Microsoft Project
Project Custom Fields
1:1Pegasus Media Campaigns aggregate campaign metadata, client meetings, and new projects. We extract campaign name, status, start/end dates, and key metadata as project-level custom fields in Microsoft Project. Live metrics from Pegasus are migrated as a static snapshot; real-time campaign analytics require a connector to the media platform (Google Ads, Meta Ads, etc.) that is outside Microsoft Project's native scope.
Pegasus Systems
Custom Fields (Job-level)
Microsoft Project
Custom Fields (Project or Task)
lossyPegasus custom fields on Jobs require explicit per-field mapping to Microsoft Project custom fields. We document all Pegasus custom field names, data types, and picklist values during discovery. Text fields map to Microsoft Project custom text fields; numeric fields map to cost or number fields; picklist values map to custom flag or text fields. For PWA destinations, we provision enterprise custom fields before migration. For MPP desktop destinations, we add local custom fields per project file.
Pegasus Systems
Attachment
Microsoft Project
Document (SharePoint / Project Site)
1:1Documents and files attached to Pegasus Jobs, Clients, or Invoices are extracted as binary blobs or URLs. We preserve attachment associations by mapping each attachment to the corresponding document library in the destination SharePoint site (for Project Online) or a named folder alongside the MPP file (for desktop). Large binary blobs (>50MB) are skipped and listed in a gap report for manual handling.
| Pegasus Systems | Microsoft Project | Compatibility | |
|---|---|---|---|
| Client | Custom Fields or SharePoint Listlossy | Fully supported | |
| Job | Project1:1 | Fully supported | |
| Job Task List | Task (WBS hierarchy)1:many | Fully supported | |
| User / Owner | Resource1:1 | Fully supported | |
| Job Resource Allocation | Assignment1:1 | Fully supported | |
| Timesheet | Task Progress / Actual Worklossy | Fully supported | |
| Expense | Task Cost / Custom Fieldslossy | Fully supported | |
| Invoice | Not migrated (finance gap)lossy | Fully supported | |
| Media Campaign | Project Custom Fields1:1 | Fully supported | |
| Custom Fields (Job-level) | Custom Fields (Project or Task)lossy | Fully supported | |
| Attachment | Document (SharePoint / Project Site)1:1 | Fully supported |
Gotchas + challenges
Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.
Pegasus Systems gotchas
No documented public API means bulk exports require workarounds
Reporting module defects cause visibility gaps in migrated data
Financial period locking may cause re-opening conflicts
Change management scope creep can inflate migration timelines
Microsoft Project gotchas
Project for the web is being retired and merged into Microsoft Planner
Planner-tier portfolio features are incomplete despite Plan 5 labeling
Web app constraint controls are weaker than the Windows desktop client
Project requires a separate license not bundled with standard Microsoft 365
Project Online API is edition-gated and inconsistently documented
Pair-specific challenges
Migration approach
Discovery and export method agreement
We audit the Pegasus instance across Jobs, Clients, Users, Timesheets, Expenses, Invoices, Media Campaigns, and custom fields. Because Pegasus has no public API, we work with the customer to identify the correct export method: Pegasus Excel import templates for timesheet and forecast data, direct data extracts arranged through Pegasus's change management team, or CSV/manual exports. We document the full Pegasus schema, identify locked financial periods, and agree on the export method before migration scoping is finalised. We simultaneously confirm the Microsoft Project destination: desktop MPP files, Project Online PWA, or Project for the Web, since the destination format changes the import pipeline entirely.
Destination setup and schema design
For Project Online PWA destinations, we provision the PWA site, configure enterprise custom fields to match Pegasus custom field names and types, set up the resource pool (populated from Pegasus Users and Owners), and define the enterprise calendar. For desktop MPP destinations, we create a master project template with the required custom fields and calendar settings. We define the WBS mapping rule: how Pegasus task hierarchy translates into Microsoft Project outline levels, task names, durations, and predecessor links. We also flag the finance gap during this step and agree on the CSV export format for Invoices and Expenses.
Data extraction and transformation pipeline
We receive Pegasus data exports in their native format (Excel or CSV), parse the structured output, and run the transformation pipeline. Jobs become Projects; Pegasus task lists become WBS tasks; Pegasus Users and Owners become Resources; allocation percentages become Assignment Units. We aggregate timesheet entries by task and user and set Actual Work on Assignments. Expenses and budget data populate cost fields. The pipeline outputs Microsoft Project XML or CSV import files, plus a finance CSV for Invoices and Expenses. Each object emits a row-count report against the source extract for reconciliation.
Sandbox migration and validation
We run a full migration into a test environment: a test PWA site for Project Online destinations or a test folder for MPP desktop files. The customer's project manager validates record counts, spot-checks ten to twenty migrated projects against the Pegasus source, confirms that task hierarchy, durations, and resource assignments look correct, and reviews the WBS outline for accuracy. Any mapping corrections (custom field type mismatches, missing task hierarchy levels, incorrect resource assignments) happen in the transformation pipeline at this stage before production migration. Finance CSV exports are also validated for completeness.
Production migration in dependency order
We run production migration in record order: Resources (from Pegasus Users and Owners), then Projects (from Pegasus Jobs), then Tasks (WBS from Pegasus task lists), then Assignments (from Pegasus resource allocations), then Actuals (from Pegasus Timesheets). For Project Online, we use the PWA REST API with batch chunking and rate-limit handling. For desktop MPP, we import via the XML schema. Each phase emits a row-count reconciliation report. Locked financial period records from Pegasus are flagged and excluded from Project import; they appear only in the finance CSV export.
Cutover, validation, and rebuild handoff
We freeze Pegasus writes during cutover, run a final delta migration of any records modified during the migration window, then hand over the production Microsoft Project environment. We deliver the finance CSV export (Invoices, Expenses) and a written inventory of Pegasus Workflows, billing automations, and approval chains that require manual rebuild in Microsoft Project, Power Automate, or a separate accounting tool. We support a three-day hypercare window where we resolve any record-level reconciliation issues. We do not rebuild Pegasus automations as Power Automate flows inside the migration scope; that is a separate engagement.
Platform deep dives
Pegasus Systems
Source
Strengths
Weaknesses
Microsoft Project
Destination
Strengths
Weaknesses
Complexity grading
Standard Project Management migration. 2 of 8 objects need a mapping; the rest are 1:1.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across Pegasus Systems and Microsoft Project.
Object compatibility
2 of 8 objects need a mapping; the rest are 1:1.
Field mapping clarity
Field mapping is derived from defaults — final spec confirmed during the sample migration.
Timeline complexity
8-object category — typical timelines run 2–7 days end-to-end.
API constraints
Pegasus Systems: Not publicly documented.
Data volume sensitivity
Pegasus Systems doesn't expose a bulk API — REST + parallelization used for high-volume runs.
Estimator
Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.
Step 1
Pick a category, then your source and destination platforms.
Category
FAQ
Answers to the questions buyers ask most during Pegasus Systems to Microsoft Project migration scoping. Not seeing yours? Book a call.
Walk through your Pegasus Systems to Microsoft Project migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave Pegasus Systems
Other ways to arrive at Microsoft Project
Same-Project Management migrations
Ready when you are
Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.