Project Management migration
Field-level mapping, validation, and rollback between BrightWork and monday Work Management. We move data and schema; workflows are rebuilt natively in monday Work Management.
BrightWork
Source
monday Work Management
Destination
Compatibility
9 of 12
objects map 1:1 between BrightWork and monday Work Management.
Complexity
BStandard
Timeline
2-4 weeks
Overview
Moving from BrightWork to monday.com is a structural migration driven by two platform realities: BrightWork has no public REST API and stores all project data inside SharePoint lists, while monday.com exposes a GraphQL API with complexity-based rate limits that we navigate with batch chunking and cursor pagination. BrightWork organizes work as Project Areas within SharePoint subsites, with Programs and Portfolios rolling up for executive reporting; monday.com organizes work as Boards containing Groups of Items within Workspaces. We extract data through authenticated SharePoint list queries, preserve the project-program-portfolio hierarchy by mapping it to nested Boards or linked Group structures, and handle BrightWork's per-project custom fields by surfacing each Project Area's column definitions, collapsing duplicate field names across projects, and translating SharePoint field types to monday.com column types (text, number, date, person, status, label). RAID Logs (Risks, Assumptions, Issues, Dependencies) have no native equivalent in monday.com and migrate as Items on a dedicated Board with status columns for each RAID type. Automations, Workflow Templates, and BrightWork Status Report layouts do not migrate; we deliver a written inventory of these for the customer's admin to rebuild in monday.com's Automations center.
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 monday Work Management, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
BrightWork
Project
monday Work Management
Board
1:1BrightWork Projects map directly to monday.com Boards. The project name becomes the board title, project description migrates to the board description field, and start/end dates map to the board's date range column if configured. We create the board in the customer's target Workspace during migration. Projects with no Tasks are created as empty boards with a note indicating no items were found during extraction.
BrightWork
Program
monday Work Management
Board (linked) or Group
1:manyBrightWork Programs group multiple Projects and roll up to portfolio-level Status Reports. We map Programs to a monday.com Board where each child Project becomes a Group on that board, preserving the program-project hierarchy. If the customer prefers flat boards, we link Program-child Project boards using monday.com's Connect Boards integration or item-level links. The Program-level Status Report summary migrates as an Item on the Program board with summary fields.
BrightWork
Project Area (SharePoint subsite)
monday Work Management
Board or Group
lossyBrightWork Project Areas are SharePoint subsites containing the project's SharePoint lists (Tasks, RAID, Documents). Where the destination has a single Board per project, we flatten the Area structure into the parent Board. If the customer has configured separate boards for Tasks versus Documents in monday.com, we split the Area content accordingly during transform.
BrightWork
Task and Subtask
monday Work Management
Item and Subitem
1:1BrightWork Tasks map 1:1 to monday.com Items. Standard fields migrate: task name to item name, start date to Start Date column, due date to Due Date column, % complete to a numeric column (monday.com's native progress column requires Pro plan), priority to Priority label column, assigned owner to Person column. Parent-child task hierarchy maps to monday.com Subitems on Pro plans. Tasks without a parent become top-level Items.
BrightWork
Custom Fields (SharePoint list columns)
monday Work Management
Columns
lossyBrightWork custom fields are SharePoint list columns defined per Project Area, not globally. We export each Project Area's column definitions, identify field names appearing across multiple projects, detect type conflicts (e.g., same column name defined as text in one project and number in another), and surface conflicts for customer resolution before import. Compatible custom fields translate to monday.com column types: choice lists to Status or Labels, numbers to Numbers, dates to Date columns, person fields to Person columns. Columns with no monday.com equivalent migrate as text.
BrightWork
RAID Log: Risk
monday Work Management
Item (Board with Risk status column)
1:1BrightWork Risks are structured log entries with fields like Risk Title, Description, Probability, Impact, Mitigation, Owner, and Status. We map Risks to Items on a dedicated monday.com Board (typically named Risks) with columns for Impact (Labels), Probability (Numbers or Labels), Mitigation (Text), Owner (Person), and Status (Status). If the customer uses monday.com's optional Risk Management template, we map to its pre-built columns.
BrightWork
RAID Log: Assumption
monday Work Management
Item (Board with Assumption status column)
1:1BrightWork Assumptions are structured log entries tracking the assumption statement, category, owner, validation status, and review date. We map Assumptions to Items on a dedicated monday.com Board with text and status columns. Assumptions do not have a native monday.com equivalent and require a configured board structure.
BrightWork
RAID Log: Issue
monday Work Management
Item (Board with Issue status column)
1:1BrightWork Issues are structured log entries with title, description, priority, status, owner, and due date. We map Issues to Items on a dedicated monday.com Board with columns for Priority (Labels), Status (Status), Owner (Person), and Due Date (Date). Issue priority maps to a Labels column with severity values.
BrightWork
RAID Log: Dependency
monday Work Management
Item (Board with Dependency status column)
1:1BrightWork Dependencies track the dependent item, dependency type (finish-to-start, start-to-start, etc.), target date, and status. We map Dependencies to Items on a dedicated monday.com Board with columns for Dependency Type (Labels), Target Date (Date), Status (Status), and Related Task (Item Link or Text). Complex dependency chains may require manual recreation in monday.com's native dependency column if the Pro plan is licensed.
BrightWork
Portfolio Status Report
monday Work Management
Item or Document
1:1BrightWork aggregates project status into portfolio-level Status Reports with sections for each project's health, risks, and milestones. We extract the report data as structured JSON and write it to monday.com as a summary Item on the Portfolio board with text columns for each section, or as a document attached to the Portfolio board if the customer prefers PDF preservation. We do not migrate the report's visual layout; the customer rebuilds the report format in monday.com's Dashboard or uses the written data as a starting point.
BrightWork
Time Entry
monday Work Management
Time Tracking Column or Item
1:1BrightWork time entries are logged against Tasks with hours, date, user association, and description. monday.com's native time tracking is available on Pro plans and above ($19/seat/mo). We map time entries to monday.com's Time Tracking column on the corresponding Item, or to a separate Time Log board with Items representing each entry if the customer is on Standard. Time entry hours, date, and user association migrate directly; the description maps to a text column.
BrightWork
Attachment (SharePoint document library)
monday Work Management
File or Document
1:1BrightWork stores file attachments in SharePoint document libraries within each Project Area. We extract the binary files, preserving folder structure, and re-upload them to monday.com attached to the corresponding Board or Item via monday.com's file upload API. Files larger than 500 MB are flagged for chunked upload or alternative delivery. The original file name and any folder path context are preserved in the Item's file description.
| BrightWork | monday Work Management | Compatibility | |
|---|---|---|---|
| Project | Board1:1 | Fully supported | |
| Program | Board (linked) or Group1:many | Fully supported | |
| Project Area (SharePoint subsite) | Board or Grouplossy | Fully supported | |
| Task and Subtask | Item and Subitem1:1 | Fully supported | |
| Custom Fields (SharePoint list columns) | Columnslossy | Mapping required | |
| RAID Log: Risk | Item (Board with Risk status column)1:1 | Fully supported | |
| RAID Log: Assumption | Item (Board with Assumption status column)1:1 | Fully supported | |
| RAID Log: Issue | Item (Board with Issue status column)1:1 | Fully supported | |
| RAID Log: Dependency | Item (Board with Dependency status column)1:1 | Fully supported | |
| Portfolio Status Report | Item or Document1:1 | Fully supported | |
| Time Entry | Time Tracking Column or Item1:1 | Fully supported | |
| Attachment (SharePoint document library) | File or Document1:1 | 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
monday Work Management gotchas
Subitems have no bulk export endpoint
API complexity budget constrains query depth
Daily call limits vary sharply across plan tiers
Automation and integration rules do not export via API
Saved views are not exposed via API
Pair-specific challenges
Migration approach
Discovery and SharePoint access scoping
We audit every BrightWork Project Area accessible under the customer's SharePoint credentials. We document the total project count, task count, attachment volume (file count and total storage), custom field definitions per Project Area (column names, data types, and any type conflicts across projects), RAID log entry counts by type (Risk, Assumption, Issue, Dependency), time entry volume, and Program-Portfolio hierarchy. We confirm SharePoint version (on-premise 2019 or Online/Microsoft 365) because it affects field serialization behavior for Managed Metadata and Person fields. The discovery output is a written migration scope with a record count estimate and a SharePoint access checklist for the customer to provision before extraction begins.
Data extraction from SharePoint lists
We authenticate against each Project Area's SharePoint site using the customer's provisioned credentials, query the underlying SharePoint lists for Projects, Tasks, RAID entries, Time Logs, and document library contents, and export the results as structured JSON. We run version-specific field extraction logic based on the detected SharePoint version, converting Managed Metadata fields to text labels, Person fields to display name strings, and lookup fields to referenced item IDs. Attachments are extracted as binary files with their parent list item ID preserved for re-linking during monday.com import. This step runs against a staging environment first to validate connectivity before touching production SharePoint.
Custom field reconciliation and conflict resolution
We process the exported custom field definitions across all Project Areas, building a unified column map. We flag duplicate field names with conflicting data types (e.g., a text column named Priority in Project A and a number column named Priority in Project B) and surface them for customer resolution before monday.com import. We also identify fields with no direct monday.com column type equivalent (e.g., calculated SharePoint columns) and map them to text columns with the computed value preserved. The output is a confirmed column mapping document that the customer approves before we proceed to monday.com schema creation.
monday.com workspace and board structure setup
We create the monday.com workspace, boards, and column structure based on the approved mapping. Each BrightWork Project becomes a Board (or a Group within a Program board if the customer selects the linked board structure). We create RAID boards with Status columns for each type, configure custom columns matching the reconciled SharePoint column map, and set up the time tracking configuration based on the confirmed monday.com plan tier. Boards are created in a customer sandbox account first for validation before the production migration run.
Production migration in dependency order
We run production migration in record-dependency order: Boards created first, then Items (Tasks, RAID entries) with parent-child relationships resolved (Items created before Subitems, RAID Items before Dependency Items linked by ID), then attachments uploaded and linked to Items, then time entries mapped to the Time Tracking column or Time Log board. monday.com GraphQL API rate limits (complexity-based per-minute budgets, 5,000 requests per minute, 2,000 mutations per minute) are managed through batch chunking and exponential backoff. Each phase emits a row-count reconciliation report before the next phase begins.
Cutover, validation, and automation rebuild handoff
We freeze SharePoint writes during cutover, run a final delta migration of any records modified during the migration window, then hand off monday.com as the system of record. We deliver the template and automation inventory document to the customer's admin team, documenting every BrightWork RAID log structure, PMBOK-aligned template phase, and Status Report layout with recommended monday.com Automations equivalents. We support a one-week hypercare window where we resolve any data quality issues raised during user acceptance testing. We do not rebuild automations in monday.com as part of the migration scope; that is a separate engagement or an internal admin task.
Platform deep dives
BrightWork
Source
Strengths
Weaknesses
monday Work Management
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 monday Work Management.
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 monday Work Management migration scoping. Not seeing yours? Book a call.
Walk through your BrightWork to monday Work Management 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 monday Work Management
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.