Migrate from CAMMS to Trello

CAMMS Projects are the top-level container for all child records. We map each CAMMS Project to a Trello Board. If CAMMS contains sub-project hierarchies, we flatten them into separate Boards within a Trello Workspace and use a naming convention (Parent Project > Sub-Project) for disambiguation. Project status, owner, start/end dates, and cost centre map to Board description fields and custom fields on a Project Info card. The Workspace name in Trello is set to the customer's organisation name or a top-level portfolio identifier.

CAMMS Tasks belong to Projects and carry status, assignees, start/end dates, and effort estimates. We map each Task to a Trello Card, placing it in a List that corresponds to the Task's CAMMS status field. Parent-child Task relationships are preserved by converting sub-tasks to checklist items on the parent Card (for lightweight hierarchies) or to linked Cards using Trello's Card Links Power-Up (for deeper hierarchies that require independent tracking). Task attachments require a parallel file export pipeline.

CAMMS Risks are linked to Projects and contain likelihood, impact, owner, and mitigation plans. Trello has no native risk object, so we map Risks to Cards within the project Board using Trello Custom Fields (Likelihood, Impact, Risk Owner, Mitigation Status, Due Date) added via the Custom Fields Power-Up. Risk score calculations (e.g., Likelihood x Impact) are preserved as a custom formula field or as a colour-coded Label if Custom Fields are not available on the destination Trello tier. Risk-to-Issue associations require explicit cross-reference notes on both Cards.

CAMMS Issues are related but distinct from Risks, with their own status workflow, priority, and linked project context. We map Issues to Trello Cards using a separate List (e.g., 'Issues') within the project Board, distinct from the Task List. Issue priority, status workflow, and owner map to Custom Fields. Issue-to-Risk associations are preserved as cross-references in Card descriptions. If CAMMS Issues have a priority scoring model, we represent it as a numeric Custom Field.

Budget entries in CAMMS track planned cost against actuals per project or work package, including cost codes, periods, and variances. Trello has no native financial tracking. We offer two strategies: (1) map Budget lines to Cards in a dedicated Finance Board within the Workspace, with Planned, Actual, and Variance as Custom Fields per Card; or (2) carry a budget summary as rich text in the Board description and a per-period budget summary card. Currency formatting and cost code schemas vary by CAMMS deployment; we standardise these during the transform phase before import. The customer chooses the strategy during scoping.

Meeting records in CAMMS contain agenda items, attendees, and minutes. We map Meetings to Trello Cards in a dedicated Meetings List within the project Board. Agenda items become checklist items on the Card. Attendees are added as Card Members (we resolve CAMMS user accounts to Trello member email addresses via the user mapping). Meeting minutes are stored as Card descriptions. Meeting attachments (documents, PDFs) are exported as files and reattached to the Card.

Documents attached to CAMMS Projects, Tasks, Risks, Issues, or Meetings are stored in CAMMS's document management layer. We run a parallel attachment export pipeline that downloads files in their original format and recreates the folder hierarchy in our staging environment. After Cards are created in Trello, we reattach each file to its parent Card via the Trello API. Large portfolios with hundreds of attachments require additional storage provisioning and transfer time. Files are reattached in original format with the original filename preserved.

User accounts, resource allocations, and utilisation data are extracted from CAMMS workforce modules. We resolve CAMMS users by email address to Trello member accounts in the destination Workspace. Role-based access assignments (Project Manager, Risk Owner, Resource) are mapped to Trello Labels by role (e.g., Label: Project Manager, Label: Risk Owner). Inactive CAMMS users are flagged in the reconciliation report for the customer's admin to handle before migration begins.

CAMMS allows organisations to define approval chains and stage-gate workflows per project type. Trello Automation and Butler support rule-based triggers (when a Card moves to a List, send a notification, add a member) but do not replicate the formal approval routing model that CAMMS uses in regulated environments. We do not migrate approval chains as code. We deliver a written inventory of every active CAMMS approval chain and stage gate with its trigger conditions, approver sequence, and recommended Trello Automation equivalent, so the customer's admin can rebuild them post-migration.

CAMMS Workflows (automated actions triggered by field changes, status transitions, or date events) have no direct Trello equivalent. Trello Automation supports board-level rules and cross-board triggers, but the trigger models and action types differ structurally from CAMMS's workflow engine. We do not migrate Workflows as code. We deliver a written inventory of every active CAMMS Workflow with its trigger, conditions, actions, and a recommended Trello Automation or Butler command equivalent, so the customer's admin can rebuild them post-migration.

CAMMS allows administrators to define custom fields on Projects, Tasks, Risks, and other objects. These custom fields have no published export schema. We do not auto-migrate CAMMS custom fields. Instead, we ask the customer to provide a written inventory of all active custom fields, their data types, and current values before scoping. We then map each one to a Trello Custom Field (text, number, date, dropdown, or checkbox) where supported, and flag any that exceed Trello Custom Field type support for manual carry-over.

CAMMS consolidates project status, budget variance, and risk exposure into executive portfolio dashboards. Trello does not have a native portfolio dashboard equivalent; the Workspace home page provides a board overview but lacks the structured reporting model. We recommend using Trello Dash or a third-party BI connector (e.g., Zapier to Google Sheets to Looker) to rebuild portfolio reporting post-migration. As part of migration scope, we deliver a data export of portfolio-level summary metrics from CAMMS that the customer's admin can use to seed the replacement reporting layer.