Migrate from Synergy to Microsoft Project

Synergy Projects map 1:1 to Microsoft Project files or Project for the Web Projects. We extract Project-level metadata including creation timestamps, project status, custom fields, and project-level notes. The destination Project is created before any Task import so that the file or database reference is available during Task load. If the customer uses Project Online or Project for the Web, we provision the project via the PWA REST API with project properties set from the Synergy source.

Synergy Tasks map 1:1 to Microsoft Project Tasks with hierarchy preserved. We extract the full WBS (Work Breakdown Structure) numbering, parent-child relationships, start and finish dates, duration, percent complete, and predecessor dependencies. In Microsoft Project, predecessor links become predecessor task relationships (Finish-to-Start, Start-to-Start, etc.). We map Synergy's custom fields per Task to Microsoft Project enterprise custom fields or local custom fields, and we snapshot the complete custom field schema before migration to restore any null fields that Synergy's API omits from output.

Synergy custom fields (text, number, currency, date, dropdown, multi-select) map to Microsoft Project local custom fields or Project Online enterprise custom fields. We pre-snapshot the complete custom field schema including null and unset fields, because Synergy's API omits empty custom fields from JSON output and the Microsoft Project CustomFields collection has the same behavior. We use the pre-snapshot to ensure every field defined in Synergy has a corresponding custom field in Microsoft Project, populated with type-appropriate defaults for null values. Dropdown fields in Synergy require lookup table creation in Microsoft Project before the task import runs.

Synergy's Job Structure defines folder layouts, naming rules, folder-level permissions, issue types, and dashboard configurations that are tightly coupled to individual firm setups. Microsoft Project has no direct equivalent of folder-level permissions or firm-specific issue types. We extract the Job Structure as a manifest with the full folder hierarchy, apply naming conventions to the WBS outline where Microsoft Project supports them, and flag folder-level permission models and issue type configurations as requiring manual rebuild in SharePoint permissions or Microsoft Teams channels post-migration.

Synergy files include content, all versions, change records (who and when), and file-level permissions. Microsoft Project stores files in SharePoint or OneDrive, with version history managed at the SharePoint level. We transfer binary file content alongside version history metadata and change records, linking the SharePoint file URL to the corresponding Synergy Project or Task via a custom field in Microsoft Project. 12d Model project files are supported as binary transfers without native viewer migration.

Synergy Contacts are stored in the platform but the public API does not expose a Contacts endpoint. We access Contacts via the native import/export JSON bundle which auto-collects associated groups and contact attributes. In Microsoft Project, there is no native Contact object; we map Contacts to Resources in the Resource Sheet (for team members assigned to tasks) or to a linked SharePoint Contact List (for clients and external stakeholders). Contact-to-resource mapping is done by email match.

Synergy Teams define group-level permissions and role assignments for Projects and Jobs. The native import/export tool handles Teams as part of the metadata bundle. Microsoft Project does not have a standalone Team object; team membership is represented through task assignments and the Resource Sheet. We extract team roles and map them to Microsoft Project resource roles (generic resources, material resources, or cost resources), and flag role-based permission configurations for manual rebuild in SharePoint site permissions or Azure Active Directory groups.

Synergy Associations link Jobs, Tasks, and other objects to form cross-reference relationships that reflect cross-project dependencies. Microsoft Project has no native cross-record association object. We map these relationships to Task Notes (for inline references) or Hyperlinks (for external document links) and provide a written cross-reference manifest for the customer's PMO admin to rebuild as formal cross-project dependencies in Microsoft Project or as items in a linked Excel resource.

Synergy stores activity records (calls, emails, meetings, tasks) that do not have a public API endpoint. The native import/export bundle bundles these as part of the job and folder metadata package. Microsoft Project does not have a native Activity timeline equivalent; we map engagement records to Task Notes (for inline activity context) or export them to a SharePoint list linked to the Project, preserving the activity type, date, and associated contact or team member. Customers requiring full activity history as importable records should plan a SharePoint-based activity log as the destination.

Synergy Attributes store metadata values tied to Jobs, Tasks, and Files. They are collected automatically by the import/export tool as part of the job and folder metadata package. Microsoft Project has no standalone Attribute object; we map Attribute key-value pairs to Microsoft Project custom fields (if the attribute applies to a project or task) or to Task Notes (for contextual annotations). Attribute naming conventions are preserved as field names or note prefixes in the destination.