Migrate from BrightWork to Microsoft Project

BrightWork Projects map directly to Microsoft Project plan files or Project Online project sites. We preserve project name, description, planned start, planned finish, and the Project Manager from the SharePoint Project Area's site permissions. The Project Manager email is recorded in a Project-level custom text field because MS Project does not store a PM as a typed User field at the project level.

BrightWork Programs group multiple Projects and roll up to a portfolio-level Status Report. Microsoft Project has no native Program object. We split the Program into separate MPP files (one per child Project) and create a Program-level master summary document listing all child projects, their statuses, and their owners. The customer uses the master document or a SharePoint site as the Program container post-migration.

BrightWork Tasks map 1:1 to Microsoft Project Tasks with name, start date, finish date, duration, percent complete, priority, and assigned owner preserved. Predecessor links from BrightWork's predecessor field migrate to the predecessor column in MS Project using the standard FS/SS/FF dependency notation. Parent-child task hierarchy (WBS) is preserved by maintaining the outline level from SharePoint.

BrightWork aggregates project status into portfolio-level Status Reports with health indicators, milestone summaries, and issue flags. Microsoft Project does not have a native status report object. We extract each Status Report as a structured JSON summary and write it as a summary task at the top of each child project's MPP file, with health and RAG status in custom fields. A separate written status report register is delivered for the PMO admin to rebuild as a Power BI dashboard or SharePoint page.

BrightWork Risks are structured list items with owner, probability, impact, and mitigation fields. Microsoft Project has no native Risk object. We merge all Risks into the destination Project by creating custom text fields (Risk Owner, Risk Probability, Risk Impact, Mitigation Plan) and populating them on the relevant summary task, or by attaching a Risks.docx export as a document link. The customer chooses strategy during scoping.

BrightWork Issues are structured list items with owner, priority, status, and resolution fields. We merge Issues into the destination Project by creating custom fields (Issue Owner, Issue Priority, Issue Status, Resolution) on the affected task, or by attaching an Issues.docx export. This mirrors the Risk approach for consistency.

BrightWork Assumptions are typically free-text or single-field list entries. We attach Assumptions as formatted Notes on the related task or on a dedicated Summary task for the project. There is no native Assumption object in Microsoft Project.

BrightWork Dependencies track cross-project or external linkages. Internal predecessor links migrate as MS Project predecessor relationships. External dependencies (where the target project is not in the migration scope) migrate as a text custom field External Dependencies listing the target system and project name for manual rebuild in MS Project.

BrightWork custom fields are SharePoint list columns defined per Project Area, which means the same field name may have different data types across projects (for example, Project A defines Priority as a Choice field; Project B defines Priority as a text field). We export the column definitions for each Project Area, identify type conflicts across the migration scope, and surface them for customer resolution before import. Where types align, we create matching MS Project Enterprise custom fields. Where they conflict, we default to text.

BrightWork stores file attachments in SharePoint document libraries within each Project Area. We extract the binary files and produce a document register mapping each file to its parent task (or project) and the SharePoint path. During import, we place files in a shared network location or SharePoint Online library and link them from MS Project via the Hyperlinks field or a document reference custom field. We do not embed binary files directly into MPP files.

BrightWork time entries log hours against Tasks with date and user association. Microsoft Project stores work on task assignments (Assignment Actual Work field) rather than as standalone time entry records. We map each time entry to the corresponding task assignment and set the Actual Work and Actual Start fields. If the destination is Project Online, we also write to TimesheetMyTasks to surface entries in the Project Online timesheet experience.