Project Management migration
Field-level mapping, validation, and rollback between BrightWork and Trello. We move data and schema; workflows are rebuilt natively in Trello.
BrightWork
Source
Trello
Destination
Compatibility
4 of 12
objects map 1:1 between BrightWork and Trello.
Complexity
BStandard
Timeline
2-3 weeks
Overview
Migrating from BrightWork to Trello is a structural downgrade in portfolio and reporting capability in exchange for a lighter, more accessible task board. BrightWork has no public REST API; we extract via SharePoint list export, handling custom fields as SharePoint list columns and RAID entries as structured child records. Trello receives these as Boards (one per BrightWork Project), Cards (per Task), Custom Fields (where types align), and attachments (per Card). Portfolio-level Status Reports, Program roll-ups, and structured RAID logging have no native Trello equivalent, so we surface them as labeled Cards with checklist summaries and deliver a written reference document for the customer to rebuild in Trello Labels and Butler automations. We do not migrate BrightWork workflows or automations; these require manual rebuild in Trello Butler or Power-Ups after cutover.
Every standard and custom field arrives verified.
AI proposes the map; you confirm before any record moves.
Parent–child, lookups, and ownership stay linked.
Calls, emails, meetings — with original timestamps.
Documents, uploads, and inline notes move with the record.
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a BrightWork object lands in Trello, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
BrightWork
Project
Trello
Board
1:1BrightWork Projects map directly to Trello Boards. We extract the project name, description, start and end dates, and assigned Project Manager from the SharePoint Project Area list and create one Board per Project. The project manager is set as a Board member with admin role. Portfolio Programs create separate Boards linked via a board reference document rather than a native link, since Trello has no parent-child board hierarchy at the platform level.
BrightWork
Program
Trello
Board (parent)
1:manyBrightWork Programs group multiple Projects and roll up to a portfolio-level Status Report. We map each Program to a parent Board whose purpose is to consolidate related project boards. We deliver a Program-to-Board mapping table as part of the migration output, noting that Trello does not natively roll up status across boards; this requires a Trello Power-Up or manual consolidation process for ongoing use.
BrightWork
Portfolio Status Report
Trello
Card summary + reference document
lossyBrightWork portfolio-level Status Reports aggregate status across multiple projects into a single executive-readable document. Trello has no native portfolio reporting feature. We extract the latest Status Report data and write it to a reference Card pinned to the parent Program Board, with a written Status Report handoff document that the customer's admin uses to configure Trello Dashboard views (Premium) or a Power-Up for ongoing reporting.
BrightWork
Task
Trello
Card
1:1BrightWork Tasks map to Trello Cards with name, description, start date, due date, % complete, priority, assigned owner, and predecessor links preserved. Parent-child task hierarchy migrates as Cards with subtasks represented as Card Checklists, with the parent card labeled 'Parent Task' in the checklist name. Priority maps to Trello Card labels; start and due dates map to Custom Fields of type Date where the Standard or Premium plan is in use.
BrightWork
Subtask
Trello
Card Checklist item
1:1BrightWork subtasks are represented as Checklist items on the parent Card. Each Checklist item carries the subtask name and completion status. If the Standard or Premium plan is in use, we add a Custom Field of type Checkbox per subtask for individual assignment tracking. Subtasks with their own subtasks are flattened into a single Checklist level, with indentation preserved in the item name text.
BrightWork
Custom Field
Trello
Custom Field
lossyBrightWork custom fields are SharePoint list columns with per-project type definitions. We export the column schema for each Project Area and map to Trello Custom Field types: text to Text, numbers to Number, dates to Date, choice columns to Dropdown. Person or Group fields (lookup to SharePoint users) map to a Text Custom Field with the display name. Managed Metadata fields map to Text with the term label. If two Projects define the same custom field name with incompatible types, we surface the conflict for customer resolution before import.
BrightWork
RAID Log: Risk
Trello
Card + Label
1:manyBrightWork Risk entries from the RAID log migrate to Cards on the project Board labeled 'Risk'. Each risk becomes one Card with the risk title, description, owner, impact rating, and status as Custom Fields. High-severity risks receive a red Label. We do not maintain the risk register as a separate list; the labeled Cards serve as the risk record within the Trello board.
BrightWork
RAID Log: Issue
Trello
Card + Label
1:manyBrightWork Issue entries migrate to Cards labeled 'Issue' on the project Board. The Card carries issue title, description, owner, status, and resolution date as Custom Fields. Open issues receive an orange Label. Issues are distinguishable from Risks by label and by the 'Issue Status' Custom Field value.
BrightWork
RAID Log: Dependency
Trello
Card + Label
1:manyBrightWork Dependency entries migrate to Cards labeled 'Dependency' on the project Board. Each dependency Card includes the dependent-on project or external party, the dependency type, and the target date as Custom Fields. Dependencies are cross-linked to the related project Card via a Card link (attachment or description URL) since Trello does not support cross-board reference fields natively.
BrightWork
Attachment
Trello
Card Attachment
1:1BrightWork file attachments stored in SharePoint document libraries are extracted as binary files and re-uploaded to the corresponding Card as Trello Card Attachments. We preserve the original file name and folder structure within the Card description or as a structured checklist for context. File size follows Trello's plan limits (10 MB Free, 250 MB Standard and above). Files exceeding the target plan limit are noted in the attachment manifest for the customer to host externally and link.
BrightWork
Time Entry
Trello
Card due date + Custom Field
lossyBrightWork time entries logged against Tasks are mapped to Trello Cards as a Custom Field of type Number ('Hours Logged') and a Date Custom Field ('Last Logged'). Trello does not have native time tracking; customers needing ongoing time tracking use a Time Tracking Power-Up post-migration. We do not migrate historical time entries as a separate object since Trello has no equivalent to host them.
BrightWork
Document Library
Trello
Card Attachment set
lossySharePoint document libraries within a BrightWork Project Area are exported as file sets. We attach each file to the corresponding Card, grouping files by their original SharePoint folder path within the Card description. For large file sets (over 20 files), we create a summary Card labeled 'Documents' with links to each file, since Cards do not support true folder structures. Customers with extensive document libraries are advised to use a Trello-compatible cloud storage Power-Up post-migration.
| BrightWork | Trello | Compatibility | |
|---|---|---|---|
| Project | Board1:1 | Fully supported | |
| Program | Board (parent)1:many | Fully supported | |
| Portfolio Status Report | Card summary + reference documentlossy | Fully supported | |
| Task | Card1:1 | Fully supported | |
| Subtask | Card Checklist item1:1 | Fully supported | |
| Custom Field | Custom Fieldlossy | Fully supported | |
| RAID Log: Risk | Card + Label1:many | Fully supported | |
| RAID Log: Issue | Card + Label1:many | Fully supported | |
| RAID Log: Dependency | Card + Label1:many | Fully supported | |
| Attachment | Card Attachment1:1 | Fully supported | |
| Time Entry | Card due date + Custom Fieldlossy | Fully supported | |
| Document Library | Card Attachment setlossy | Fully supported |
Gotchas + challenges
Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.
BrightWork gotchas
No public REST API for programmatic data access
SharePoint versioning can break list export formats
Custom fields are SharePoint list columns, not a defined schema
Trello gotchas
Billing model uses maximum seat quantity at term midpoint
Custom Field data historically stored in pluginData
API rate limits are token-gated and can block bulk migration
Guest-to-paid seat conversion triggers on multi-board membership
Automation command runs are capped per plan and overage triggers upgrade pressure
Pair-specific challenges
Migration approach
Discovery and SharePoint version detection
We audit every BrightWork Project Area accessible under the provided SharePoint credentials. We identify the SharePoint version (Online/Microsoft 365 vs 2019 on-premise), enumerate all Project Areas and their associated lists (Tasks, RAID, Time Entries, Custom Fields), measure attachment file counts and sizes, and extract the column schema for each list including data types. We also identify the SharePoint document libraries linked to each project. The discovery output is a written data inventory and SharePoint version report that determines the extraction approach for all subsequent steps.
Schema extraction and field mapping design
We export the column definitions for every SharePoint list in scope. Custom fields are extracted per Project Area with their SharePoint data type. We build a unified field map collapsing duplicate custom field names across projects while flagging type conflicts for customer resolution. We design the Trello destination structure: one Board per BrightWork Project, Labels for RAID categories and priorities, Custom Fields configured on each Board for the fields that match Trello's supported types, and Card structures for Tasks. Board-level permissions are designed to mirror the SharePoint site permission structure as closely as the Trello model allows.
Trello board and custom field provisioning
We provision the Boards in the destination Trello workspace using the Trello REST API. Custom Fields are created on each Board before any Card import, with the correct type set per the field mapping. Labels are configured for priority levels and RAID categories (Risk, Issue, Dependency). We set Board background, default list names (To Do, In Progress, Done), and invite the relevant members. If the customer is on the Free Trello plan, we flag that Custom Fields are a Standard/Premium feature before provisioning to avoid scope misalignment.
Data extraction from SharePoint
We extract all list items and attachments from each BrightWork Project Area using the SharePoint list export mechanism appropriate to the detected version. We export Tasks, RAID entries, Time Entries, and custom field values in structured JSON. We download all file attachments from document libraries, preserving folder paths. We run a row-count reconciliation against the inventory produced in Step 1 to confirm all records were extracted before transformation begins.
Transformation and import into Trello
We transform the extracted SharePoint data into the Trello Card schema using the field mapping from Step 2. Tasks become Cards with checklists for subtasks. RAID entries become labeled Cards with Custom Fields for severity, owner, and status. Attachments are uploaded to Cards via the Trello API. We import in dependency order: Board members first (so they appear as valid Card assignees), then Cards with no dependencies, then Cards with checklist items, then Cards with attachments. Each import phase emits a row-count report. We use the Trello API with rate-limit handling and exponential backoff.
Cutover, validation, and automation rebuild handoff
We run a final reconciliation comparing extracted record counts against imported Card counts in Trello. We spot-check 25-50 Cards against the SharePoint source for field-level accuracy. We deliver the written automation inventory (BrightWork workflows and RAID summary) and the Program-to-Board mapping table. We do not rebuild BrightWork workflows as Butler rules inside the migration scope. The customer configures Butler post-migration using the inventory document as a guide. We support a one-week hypercare window for reconciliation issues raised by the project team.
Platform deep dives
BrightWork
Source
Strengths
Weaknesses
Trello
Destination
Strengths
Weaknesses
Complexity grading
Standard Project Management migration. 3 of 8 objects need a mapping; the rest are 1:1.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across BrightWork and Trello.
Object compatibility
3 of 8 objects need a mapping; the rest are 1:1.
Field mapping clarity
Field mapping is derived from defaults — final spec confirmed during the sample migration.
Timeline complexity
8-object category — typical timelines run 2–7 days end-to-end.
API constraints
BrightWork: Not publicly documented.
Data volume sensitivity
BrightWork doesn't expose a bulk API — REST + parallelization used for high-volume runs.
Estimator
Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.
Step 1
Pick a category, then your source and destination platforms.
Category
FAQ
Answers to the questions buyers ask most during BrightWork to Trello migration scoping. Not seeing yours? Book a call.
Walk through your BrightWork to Trello migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave BrightWork
Other ways to arrive at Trello
Same-Project Management migrations
Ready when you are
Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.