Migrate from CAMMS to monday Work Management

CAMMS Projects are the top-level containers with sub-project hierarchies. We extract full project hierarchies including parent-child relationships and map each root project to a monday.com Board. Sub-projects map to Groups within the Board or to sub-Board folders depending on the complexity of the hierarchy. Project status, owner, start/end dates, and cost centre map to Board columns. We use the monday.com API to create Boards in dependency order so that folder relationships are established before Items are loaded.

CAMMS Tasks belong to Projects and carry status, assignees, start/end dates, and effort estimates. We map task structures preserving parent-child relationships via the Subitems column in monday.com (one level of subtasks) or via a linked Items relationship for deeper hierarchies. Task-level attachments require a parallel file-handling pipeline (see Gotchas). Status values from CAMMS map to monday.com Status column options configured to match the customer's workflow stages.

CAMMS Risks are linked to Projects and contain likelihood, impact, owner, and mitigation plans. Risk scores (likelihood x impact) calculate from CAMMS fields. We create a Risks Board or a Risk Group per project Board and map Risk fields to monday.com columns: Status (Open, Mitigated, Closed), Priority (High/Med/Low via Labels), Risk Owner (People column), Likelihood and Impact (Number columns), and Mitigation Plan (long-text column). Risk-to-Issue associations migrate as Linked Items.

CAMMS Issues are related but distinct from Risks and contain status workflow, priority, and linked project context. Issue-to-risk associations require explicit cross-object mapping via monday.com Linked Items. We map Issue priority to a Labels column and Issue status to a Status column. Issues without an existing Risk association in CAMMS are imported first, then Risk associations are resolved via item ID lookup after both objects are loaded.

CAMMS Budget entries track planned cost against actuals per project or work package. We evaluate three migration paths during scoping: (1) Numeric columns on the project Board for cost tracking with Formula columns for variance; (2) a separate Budget Board with Items representing budget lines and a link back to the project Board; (3) CSV import into a dedicated budget integration. Currency formatting standardises during transform. Cost code schemas from CAMMS map to a Text column or a multi-select Status column depending on complexity.

Meeting records contain agenda items, attendees, and minutes. We create a Meetings Board or Group per project and map meeting content to Items: Date and time (Date column), Location (Text column), Attendees (People column), Agenda (long-text column), and Minutes (long-text column). Meeting attachments extract as files and re-attach to the Item via monday.com file upload. If CAMMS stores recurring meetings as a series, we create individual Items linked by a recurrence group.

Documents attached to CAMMS projects, tasks, risks, and meetings are stored in CAMMS's document management layer. We export files in their original format, recreate the folder hierarchy in our staging environment, and re-attach each file to its parent Item after import into monday.com. Large portfolios with hundreds of attachments require additional storage provisioning. We note that monday.com Enterprise offers 500 GB storage per seat; Standard includes 1,000 GB workspace storage.

CAMMS user accounts, resource allocations, and utilisation data extract from CAMMS workforce modules. Role-based access assignments in CAMMS require mapping to monday.com's permission model (Member, Viewer, Admin per Workspace). We match CAMMS users by email address. Inactive users with historical assignments are mapped as Item assignees in monday.com but added as deactivated members if the customer requires audit trail preservation.

CAMMS custom fields defined per deployment have no documented export mechanism or stable schema. We do not auto-migrate custom fields. Instead, we ask the customer to provide a written inventory of all active custom fields with their data types and current values before scoping. We then evaluate each against monday.com's 25+ column types and map where direct equivalents exist (e.g., CAMMS text field to Text column, CAMMS date to Date column). Any custom fields without a monday.com equivalent are flagged as manual carry-over items documented in the migration handoff.

CAMMS supports nested sub-projects within a parent project. We map the top two levels of project hierarchy to monday.com Board Folders (for the portfolio level) and Boards within folders (for the project level). Sub-projects beyond two levels flatten to Groups within the Board or to Items with a parent-child link column. We validate the hierarchy depth with the customer during scoping because the chosen mapping affects board navigation and reporting.

CAMMS risk scores are calculated from Likelihood x Impact fields. We create a monday.com Formula column with the expression {Likelihood} * {Impact} to replicate the risk score calculation on import. Note that CAMMS uses integer scales (e.g., 1-5) while monday.com Formula treats all numbers as decimals; we normalise the scale during transform to produce consistent risk score outputs.

CAMMS approval chains and stage gates are defined per project type. monday.com does not have a native approval workflow engine beyond Status column stages and automation triggers. We map CAMMS approval stages to monday.com Status column options and document the automation triggers required to replicate each approval chain (e.g., When Status changes to 'Pending Review', notify approver). The customer rebuilds these automations in monday.com's native automation builder post-migration.