Migrate from raidlog.com to Trello

Each raidlog.com Project becomes a Trello Board. We preserve the project name, description, start date, and target date as board metadata. If the customer uses Trello Enterprise, we map raidlog.com's Enterprise Private Workspaces into Trello team spaces or individual boards based on the access-control scope. Projects are the top-level container and are migrated first so that all child RAID records resolve their parent board reference at import time.

raidlog.com Risks map to Trello cards with a 'Risk' label. The Risk's title, description, probability, impact, status, owner, and due date transfer to the card name, description, and custom fields (dropdown for probability, number for impact, dropdown for status, member for owner, date for due). Probability and impact numeric values map to Trello custom number fields. We preserve the risk's linked action items as card checklist items. Risk category and tags from raidlog.com map to Trello labels.

raidlog.com Action Items map to Trello cards with an 'Action' label. Assignee, due date, priority, and status transfer to Trello member, due date, label color (for priority), and list position (for status). We preserve the action's linkage to its parent Risk or Issue as a card link in the description. If the action is linked to a dependency, we create a checklist item noting the dependency reference rather than a native link.

raidlog.com Issues map to Trello cards with an 'Issue' label. Severity, status, owner, description, and resolution date migrate as custom fields and description. We use a custom field for severity (dropdown: Critical, High, Medium, Low) and a date field for resolution date. The original issue ID from raidlog.com is preserved in the card description for traceability.

raidlog.com Decisions map to Trello cards with a 'Decision' label. Owner, date made, date due, status, and rationale migrate to card member, created date, due date, list position (for status), and description. The rationale field (often multi-paragraph text) transfers to the card description with formatting preserved. Decision links to the related project are stored as a board reference in the card description.

raidlog.com Dependency records (A blocks B relationships) have no native Trello equivalent. We represent each dependency as a checklist item on the dependent card (the one being blocked), referencing the blocking card by name and raidlog.com dependency ID. This preserves the relationship without creating a functional dependency link. The customer can optionally use Trello's Card Links Power-Up to create manual cross-card references after migration.

raidlog.com Tags are managed via a dedicated Tags API and can be applied to any RAID record. We extract the full tag taxonomy and map each tag to a Trello Label by name and color. If the customer uses more than 25 distinct tags, we consolidate low-frequency tags into a single 'miscellaneous' label and note the full taxonomy in the migration inventory. Tag value mapping happens during the transform phase to ensure label names match exactly.

raidlog.com Users referenced as Owners across Risks, Actions, Issues, and Decisions map to Trello Members by email match. We resolve each raidlog.com owner_id to a Trello member who is already a board collaborator. Any raidlog.com owner without a matching Trello member is flagged in the reconciliation report for the customer to provision before final import. We do not create Trello accounts; we map to existing ones.

raidlog.com Lessons Learned are a supplementary log type with no dedicated API; they are accessed through the All RAID endpoint. We extract Lessons Learned records, apply a 'Lesson' label, and place them in a dedicated 'Lessons Learned' Trello board scoped to each project. The lesson text migrates as card description, and the related project is noted in the board name. We flag any Lessons Learned that reference a deleted or archived project as orphaned.

raidlog.com Change Log entries track project change requests with requester, date, status, and description. We map these to Trello cards with a 'Change' label in a dedicated 'Change Log' board per project. Requester migrates as card member, date as card created date, status as list position, and description as card description. The original change request ID is preserved in the description for audit purposes.

raidlog.com's supplementary Contact and Stakeholder List maps to a dedicated 'Stakeholders' board in Trello. Each stakeholder becomes a card with a 'Stakeholder' label, and contact details (name, email, role, organization) migrate as card description text. We do not create Trello members from stakeholder records unless the stakeholder is also a Trello user; stakeholder contact info is text-based only.

raidlog.com Enterprise Private Workspaces create isolated team environments with independent access controls. We map each Private Workspace to a Trello Team Space or a grouped set of boards under a workspace prefix. Access-control rules (who can view and edit) translate to Trello board permission settings. Free and Core plans have a single workspace and map to a single Trello workspace. This mapping requires explicit confirmation during scoping because workspace boundaries affect which boards each team can see.