Project Management migration

Migrate from BrightWork to Trello

Field-level mapping, validation, and rollback between BrightWork and Trello. We move data and schema; workflows are rebuilt natively in Trello.

BrightWork logo

BrightWork

Source

Trello

Destination

Trello logo

Compatibility

33%

4 of 12

objects map 1:1 between BrightWork and Trello.

Complexity

BStandard

Timeline

2-3 weeks

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

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.

Field-level fidelity

Every standard and custom field arrives verified.

Schema-aware mapping

AI proposes the map; you confirm before any record moves.

Relationships preserved

Parent–child, lookups, and ownership stay linked.

Full activity history

Calls, emails, meetings — with original timestamps.

Attachments & notes

Documents, uploads, and inline notes move with the record.

Why teams make this switch

Two sides of the same decision

Leaving

BrightWork logo

BrightWork

What's pushing teams away

  • Some customers find BrightWork too tightly coupled to SharePoint—upgrades, permissions management, and site administration become complex and require SharePoint expertise.
  • G2 reviewers note that BrightWork provides only marginal improvements over vanilla SharePoint, leading teams to question the value of the premium over a well-configured SharePoint intranet.
  • Customers report that many financial and advanced reporting features are locked behind higher pricing tiers, making the entry-level plan limiting for mid-sized PMOs.
  • Organizations outgrowing SharePoint-native project management look for platforms with stronger native API support, more modern UX, and built-in resource management.

Choosing

Trello logo

Trello

What's pulling them in

  • Free plan supports unlimited users and 10 boards, giving small teams full access to core Kanban functionality before any paid commitment is required.
  • The drag-and-drop board/card/Label interface requires no training, which reduces adoption friction and onboarding time across distributed teams.
  • Atlassian ecosystem integration with Jira, Confluence, and Bitbucket provides native cross-tool workflows for teams already using Atlassian tools.
  • Butler automation on paid tiers enables rule-based triggers without third-party integrations, covering basic workflow automation needs.
  • Simple visual task management with due dates, checklists, and member assignments keeps individual contributors and small teams organized without complexity.

Object mapping

How BrightWork objects map to Trello

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

maps to

Trello

Board

1:1
Fully supported

BrightWork 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

maps to

Trello

Board (parent)

1:many
Fully supported

BrightWork 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

maps to

Trello

Card summary + reference document

lossy
Fully supported

BrightWork 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

maps to

Trello

Card

1:1
Fully supported

BrightWork 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

maps to

Trello

Card Checklist item

1:1
Fully supported

BrightWork 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

maps to

Trello

Custom Field

lossy
Fully supported

BrightWork 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

maps to

Trello

Card + Label

1:many
Fully supported

BrightWork 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

maps to

Trello

Card + Label

1:many
Fully supported

BrightWork 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

maps to

Trello

Card + Label

1:many
Fully supported

BrightWork 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

maps to

Trello

Card Attachment

1:1
Fully supported

BrightWork 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

maps to

Trello

Card due date + Custom Field

lossy
Fully supported

BrightWork 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

maps to

Trello

Card Attachment set

lossy
Fully supported

SharePoint 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.

Gotchas + challenges

What specifically takes care here

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 logo

BrightWork gotchas

High

No public REST API for programmatic data access

Medium

SharePoint versioning can break list export formats

Medium

Custom fields are SharePoint list columns, not a defined schema

Trello logo

Trello gotchas

High

Billing model uses maximum seat quantity at term midpoint

Medium

Custom Field data historically stored in pluginData

Medium

API rate limits are token-gated and can block bulk migration

Medium

Guest-to-paid seat conversion triggers on multi-board membership

Low

Automation command runs are capped per plan and overage triggers upgrade pressure

Pair-specific challenges

  • Trello lacks portfolio-level reporting and Program hierarchies

    BrightWork's portfolio dashboards aggregate status across multiple projects into a single executive view. Trello has no native portfolio or program management feature. We extract the latest portfolio Status Report data and deliver it as a written reference document with board-level status recommendations. If the customer requires ongoing portfolio reporting in Trello, we configure Trello Dashboard views (Premium plan) or a third-party Power-Up as a post-migration rebuild task outside the migration scope.

  • BrightWork has no REST API; extraction relies on SharePoint list export

    BrightWork does not publish a REST API for programmatic data access. All data extraction runs through SharePoint list export, which behaves differently between SharePoint 2019 on-premise and SharePoint Online/Microsoft 365. Column types such as Managed Metadata, Person or Group, and lookups serialize differently by version. We detect the SharePoint version during scoping and apply version-specific extraction logic. Custom fields are SharePoint list columns with per-project type definitions; type conflicts across Project Areas require customer resolution before import proceeds.

  • Custom field type constraints limit mapping fidelity

    Trello supports five Custom Field types (checkbox, date, dropdown, number, text) and locks the type after creation. BrightWork custom fields use SharePoint column types that include Person or Group lookups and Managed Metadata term sets with no Trello equivalent. We map these to Text fields with the display value. The custom field type cannot be changed after creation in Trello, so any type correction post-migration requires deleting and recreating the field, which removes data from all Cards. We flag every field with a type conflict during scoping and seek written confirmation before proceeding.

  • Butler automations and Power-Up configurations do not migrate

    BrightWork workflows and structured RAID logging are operational artifacts, not data records. We do not migrate them as code or configuration. Butler automations in Trello (triggers, commands, due date rules, card move rules) require manual rebuild in Butler after migration. We deliver a written inventory of every BrightWork workflow and RAID entry that the customer reviews to configure equivalent Butler rules or Power-Ups post-migration.

  • Trello has no native time tracking; historical entries require a workaround

    BrightWork time entries against Tasks have no native Trello equivalent. We map historical hours to a Custom Field of type Number on the Card. Ongoing time tracking requires a Time Tracking Power-Up, which the customer installs and configures separately. Time entry data from BrightWork is migrated as a static record, not as a linked time-tracking object, since Trello does not support that data model.

Migration approach

Six steps for a successful BrightWork to Trello data migration

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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

Context on both ends of the pair

BrightWork logo

BrightWork

Source

Strengths

  • Built natively on SharePoint and Microsoft 365, leveraging existing Office permissions and SharePoint site infrastructure.
  • Portfolio-level dashboards that aggregate status across multiple projects for executive reporting without manual data consolidation.
  • Pre-built project and program templates (including PMBOK-aligned life cycle phases) that accelerate onboarding for new project managers.
  • RAID log management (Risks, Assumptions, Issues, Dependencies) built into the project template with structured tracking fields.
  • Flexible deployment options supporting both on-premise SharePoint and Microsoft 365 cloud environments.

Weaknesses

  • No publicly documented REST API—the primary migration path is SharePoint list export/import, limiting automation and increasing manual effort.
  • No transparent public pricing; prospective customers must contact sales, making budget planning difficult without a discovery call.
  • Very small review corpus on major platforms (2 reviews on G2) makes independent quality assessment challenging.
  • The product adds significant value only within a Microsoft-centric environment, making it a poor fit for organizations with mixed or open-source tooling stacks.
  • SharePoint permissions and site structure add administrative complexity that many customers find disproportionate to the project management features gained.
Trello logo

Trello

Destination

Strengths

  • Generous free tier with unlimited users and 10 boards, the lowest barrier to entry among major project management tools.
  • Intuitive drag-and-drop Kanban interface requires no training or onboarding documentation.
  • Deep Atlassian integration with Jira, Confluence, and Bitbucket for teams already in the ecosystem.
  • Built-in Butler automation covers rule-based triggers without requiring third-party integrations.
  • REST API with comprehensive documentation enables programmatic access to all core objects.

Weaknesses

  • Reporting and analytics are absent, with no built-in velocity tracking, burndown charts, or historical performance metrics.
  • The flat board/list/card data model scales poorly for complex projects requiring hierarchical task structures.
  • Customization is limited compared to platforms like Asana, monday.com, or Jira that offer richer field types and workflow configuration.
  • Advanced views (Timeline, Dashboard) require Premium and are not available on Standard, inflating total cost for teams needing visibility features.
  • Guest user billing rules are confusing and prone to accidental seat overages when guests join multiple boards.

Complexity grading

How hard is this migration?

Standard Project Management migration. 3 of 8 objects need a mapping; the rest are 1:1.

B

Overall complexity

Standard migration

Derived from compatibility, mapping clarity, API constraints, and data volume across BrightWork and Trello.

  • Object compatibility

    B

    3 of 8 objects need a mapping; the rest are 1:1.

  • Field mapping clarity

    C

    Field mapping is derived from defaults — final spec confirmed during the sample migration.

  • Timeline complexity

    B

    8-object category — typical timelines run 2–7 days end-to-end.

  • API constraints

    B

    BrightWork: Not publicly documented.

  • Data volume sensitivity

    B

    BrightWork doesn't expose a bulk API — REST + parallelization used for high-volume runs.

Estimator

Estimate your BrightWork to Trello migration cost

Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.

Step 1

What are you migrating?

Pick a category, then your source and destination platforms.

Category

FAQ

Frequently asked questions about BrightWork to Trello data migrations

Answers to the questions buyers ask most during BrightWork to Trello migration scoping. Not seeing yours? Book a call.

Can't find your answer?

Walk through your BrightWork to Trello migration with a real engineer — 30 minutes, free, written quote within 24 hours.

Book a free 30 minute consultation

Most migrations land between two and three weeks for organizations with fewer than 10 BrightWork Projects and straightforward SharePoint list structures. Migrations with multiple Programs, large RAID logs, SharePoint Managed Metadata fields, or time entry history move to five to eight weeks because of version-specific extraction logic, per-project column schema reconciliation, and the scope of the written automation inventory deliverable. SharePoint version (Online vs 2019 on-premise) is the primary timeline variable.

Adjacent paths

Related migrations to explore

Ready when you are

Move from BrightWork.
Land in Trello, intact.

Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.

Accuracy guarantee Rollback included Quote in 1 business day