Migrate from CAMMS to Microsoft Project

CAMMS Projects are the top-level containers in the hierarchy and map directly to Microsoft Project Project. We extract project name, description, project owner, start and finish dates, status, cost centre, and any custom project-level properties. Sub-projects in CAMMS map to sub-projects in Microsoft Project, preserving the hierarchy structure. Project status values (Active, On Hold, Closed) map to the corresponding Project Online or Project for Microsoft 365 status field. The project-level owner maps to a Resource record that we create before task import so that the OwnerId reference is satisfied at migration time.

CAMMS Tasks belong to Projects and carry status, assignees, start and end dates, effort estimates, and effort units. We map task structures preserving parent-child relationships and the full WBS hierarchy. Summary tasks in CAMMS become summary tasks in Microsoft Project; regular tasks map directly. Milestones in CAMMS (tasks with zero duration or a dedicated Milestone flag) become Microsoft Project milestones with both the Milestone checkbox and a duration of zero. Task-level attachments require a separate file-handling pipeline after the task import completes.

CAMMS Risks are linked to Projects and contain likelihood, impact, owner, mitigation plan, and status. Microsoft Project has no native Risk object, so we carry Risk data as custom fields on the associated task or as a custom enterprise text field on the project. We extract the full risk register from CAMMS and create a custom task-level field structure with fields for Risk Title, Likelihood (High/Medium/Low), Impact (High/Medium/Low), Owner, Status, Mitigation Plan, and Due Date. We create a separate Risks Register view in Microsoft Project that surfaces these custom fields in a tabular format for risk-tracking workflows. CAMMS's risk-to-issue associations require explicit cross-object mapping as a custom text field on the Issue record.

CAMMS Issues are related but distinct from Risks and carry status workflow, priority, owner, and linked project context. We map Issues similarly to Risks — as custom fields on the associated task — with fields for Issue Title, Status, Priority (Critical/High/Medium/Low), Owner, Description, and Linked Project. Issue-to-Risk associations migrate as a text field containing the related Risk ID. If the customer maintains a high volume of active Issues, we recommend creating a separate Issues Register SharePoint list linked from the project for ongoing management post-migration.

CAMMS Budget entries track planned cost against actuals per project or work package, including cost codes, budget periods, and variance. We extract budget lines including cost codes, planned amounts, and actuals, and map planned budget amounts to the Microsoft Project task Fixed Cost fields or resource-based cost fields depending on whether the budget is task-level or summary-level. Variance data migrates as a custom cost field variance__c. Cost code schemas vary by CAMMS deployment and may require a custom field for the code reference. CAMMS Budget status (Approved, Pending, Over Budget) migrates as a custom picklist field on the project.

CAMMS Meeting records contain agenda items, attendees, and minutes linked to the originating project. Microsoft Project has no native meeting object, so we carry meeting content as task notes on a dedicated Meeting Notes task or as a SharePoint list linked from the project SharePoint site. Attendee lists migrate as resource assignments on the Meeting Notes task. If the organisation relies heavily on the CAMMS Meetings module, we recommend setting up a recurring agenda and minutes template in Microsoft Teams connected to the project SharePoint site post-migration.

Documents attached to CAMMS Projects, Tasks, Risks, and Issues are stored in CAMMS's document management layer and must be exported as files separately from the record data. We run a parallel attachment export pipeline that downloads files in their original format, recreates the folder hierarchy in our staging environment, and re-links each file to its parent task after import into Microsoft Project's connected SharePoint site. Large portfolios with hundreds of attachments require additional storage provisioning and transfer time. We verify all re-links after migration against the original CAMMS document manifest.

CAMMS User accounts, resource allocations, and utilisation data are extracted from the workforce module. Role-based access assignments map to Microsoft Project Resources. Resource names, email addresses, and role titles migrate to Resource records in Microsoft Project. If CAMMS stores utilisation percentages or allocation hours per project, we map these to assignment fields or a custom resource field. Inactive CAMMS users are created as inactive Resources in Microsoft Project to preserve historical assignment data. The customer's Microsoft 365 tenant admin provisions the underlying User records in Entra ID if they do not already exist.

CAMMS custom fields defined by individual deployments are not governed by a stable schema and have no documented export mechanism. We do not migrate custom fields automatically; we ask customers to provide a written inventory of all active custom fields, their data types, and their current values before scoping. We then map each one individually to Microsoft Project custom fields (Text, Number, Date, Picklist) on the appropriate object. Any custom fields with no Microsoft Project equivalent are flagged as manual carry-over items and documented for the customer's admin.

CAMMS approval workflows and stage-gate definitions per project type have no direct Microsoft Project equivalent. Microsoft Project Online and Project for Microsoft 365 do not expose native approval chain builders inside the project schedule. We deliver a written inventory of every active CAMMS approval workflow with its stage gates, escalation paths, and sign-off conditions, and the customer's admin rebuilds these in Power Automate connected to the project SharePoint site or Project Online's approval features. This is explicitly outside our migration scope as standard delivery.