Migrate from raidlog.com to monday Work Management

Raidlog.com Projects map to monday.com Workspaces or a top-level Board with a project-name group. We create a dedicated board per project (or a single board with project-level groups if the customer prefers consolidation) and preserve project metadata including name, description, start date, target date, and owner. The Project object is the top-level container, so it migrates first before any child RAID records to satisfy monday.com's board structure dependencies.

Risks migrate to items in a dedicated Risk Board or a Risk group within the project board. We map standard fields: Risk title becomes Item name, description becomes the Item description column, probability maps to a custom number or dropdown column (1-5 scale), impact maps to a custom dropdown (Low/Medium/High/Critical), status maps to a Status column, owner maps to the monday.com Person column, and due date maps to a Date column. Probability and impact values are preserved for downstream heat map calculation. If monday.com Pro is licensed, we use the Formula column for an automated Risk Score = Probability x Impact calculation.

Action Items migrate to items in a dedicated Actions Board or Actions group. We map assignee to the monday.com Person column, due date to the Date column, priority to a Priority dropdown column, status to Status column, and description to the Item description. The action-to-risk linkage is preserved as a custom text or item link column referencing the migrated Risk item, which we resolve after the Risk board migration completes.

Issues migrate to items in a dedicated Issue Board. We map severity to a custom Severity dropdown column, status to Status, owner to Person, description to Item description, and resolution date to a Date column. The Issue object's structured fields (severity, owner, resolution date) require custom columns in monday.com since no native equivalent exists. Issues are treated as separate from Risks in raidlog.com and remain separate boards or groups in monday.com to preserve the governance distinction.

Decisions migrate to items in a dedicated Decisions Board. We map decision title to Item name, rationale to Item description, owner to Person column, date made to a Date column, date due to a Date column, and status to Status. The decision-to-project linkage is preserved as a Connect Boards column linking the Decision item to the project board. Decisions lack a native assignee field in monday.com so owner becomes a Person column annotation.

Dependencies present the highest reconstruction challenge because monday.com has no native inter-item dependency object equivalent to RAIDLOG's Dependency log type. We create a Dependents Board where each item represents a dependency relationship with From Item and To Item columns (populated as item link columns) and dependency type (blocks, is blocked by, related to). Alternatively, for customers with monday.com Pro, we use Connect Boards columns on the source items to establish item-level links. We flag which items were linked dependencies at migration time in a dependency_map field so nothing falls through the grid.

Lessons Learned have no dedicated API endpoint in raidlog.com and must be reconstructed from the All RAID endpoint response. We extract Lessons Learned entries as items in a dedicated Lessons Learned board linked to the source project. The Lessons Learned content becomes Item description, the source risk or action reference becomes a Connect Boards or text column, and the lesson category becomes a Tags column. This mapping is partial: if Lessons Learned were entered as free-form text without structured tags, the reconstruction is limited to the text content.

Change Log entries have no dedicated API and are reconstructed from the All RAID endpoint. Each Change Log row becomes an item in a Change Log board with columns for requester (Person column), date (Date column), status (Status column), description (Item description), and related project (Connect Boards column). Change Log reconstruction is scoped to structured entries; informal change notes captured in risk or issue descriptions are not extracted.

Raidlog.com Tags are managed via a dedicated Tags API and can be applied to any RAID record. We extract the full tag taxonomy during scoping and apply explicit value mapping during import. In monday.com, we use either the native Tags column (available on Standard and above) or the Labels column depending on the customer's preferred grouping. Tag naming conventions differ between platforms, so we perform a value-map reconciliation during the extract phase to avoid duplicate tags in monday.com.

Raidlog.com Users are referenced by ID across Risks, Actions, Issues, and Decisions as the assigned Owner. We extract all distinct owner IDs and resolve them by email match against the monday.com workspace members. Any raidlog.com Owner without a matching monday.com user account is held in a reconciliation queue for the customer admin to provision before record import resumes. Ownerless records are flagged and assigned to a default monday.com user or left unassigned pending admin direction.

The Stakeholder List in raidlog.com is a supplementary log for tracking project stakeholders and contacts. We export it as a distinct record set and map to a Stakeholder Board in monday.com with columns for name, role, email, and project link. Stakeholder records do not map to monday.com Contacts because monday.com Work Management does not have a native contact object; if CRM is also licensed, we can map to monday.com Contacts on a separate CRM board.

Raidlog.com's grid UI supports linking to external files but does not expose a native file attachment API. We do not migrate binary attachments directly. We export the file reference URLs from each RAID record and include them in a file_references.csv alongside the migration deliverables. The customer admin manually re-links supporting documents in monday.com items post-migration. This gap is documented in the handoff report with each record's missing attachment flagged.