Migrate from Braid to Microsoft Project

Braid Projects map to MS Project plans as the primary container. Project name, description, status, start date, and end date migrate directly. Archived projects migrate with a flag in a custom text field; the customer decides whether to include archived plans in the production .mpp file or maintain them as a reference archive. Braid's client association migrates as a custom text field (client_name__c) because MS Project has no native client object.

Braid Resources map to MS Project Resources. We extract name, email, capacity (hours per day/week), and location tags. Multi-location flags from Braid become custom text fields on the Resource record in MS Project. Billable rate information from Braid (where Resources carry a billing rate) cannot map to a native MS Project field; we document the rate table for the customer's admin to configure in Resource Sheet or export to a separate rate card. Max Units and Peak migrate from Braid capacity settings.

Braid Time Entries for a given Resource on a given Project aggregate into a single MS Project Task. Each distinct work date in Braid becomes a task start or finish date in MS Project. The Braid billable flag does not migrate to a native MS Project field; we flag it in a custom text field or document it separately. If the customer requires billable tracking, MS Project Desktop supports custom cost and billing fields that the admin configures post-migration.

Braid Clients have no direct MS Project equivalent. We preserve Client name, contact name, and contact email as a custom text field on the Project. The customer's admin can expand this to a custom Enterprise Outline Code scoped to the project plan if multi-project client rollup reporting is required. We do not create a separate Client table in MS Project because the desktop and Plan 3 web versions do not support relational entity objects.

Braid schedule assignments and shift patterns map to MS Project Resource Calendars. Braid's soft-booking vs firm-booking distinction is not native to MS Project; we document the original booking type as a custom field on the assignment so the PMO can re-evaluate during scheduling. Resource calendar exceptions (vacation, overtime) migrate as resource calendar entries.

Braid budget-versus-actual figures per project cannot map to native MS Project cost fields without a manual alignment session. MS Project supports task cost, fixed cost, and budget fields, but Braid's revenue recognition and billing cycle data has no equivalent. We extract the raw budget and actual figures as a CSV alongside the migration and document them for the customer's PMO to either enter manually into MS Project Custom Fields or maintain in a linked Excel file alongside the .mpp plan.

Braid custom fields on Projects discovered during the pre-migration pass map to MS Project Custom Fields by type. Text maps to Text, numbers to Numbers, dates to Date, and picklist-like values to Enterprise Outline Codes or custom text. MS Project's field type support is more limited than Braid's; we flag any field types that cannot map directly (for example, Braid multi-select checkbox fields map to semicolon-delimited text in MS Project).

Braid custom fields on Resources map to MS Project Resource Custom Fields. We apply the same type-mapping rules as for Project custom fields. Location tags from Braid migrate as a standard text custom field on the Resource.

Braid multi-location tags migrate as a standard text custom field on the Project or Resource record in MS Project. If the customer uses more than five distinct locations, we recommend an Enterprise Outline Code for location-based filtering rather than a free-text field.

Braid notes and engagement records linked to Projects do not map to a native MS Project object. We extract them as a JSON manifest alongside the migration and recommend either adding them as task-level notes in MS Project or attaching a summary document to the project plan. The customer chooses the approach during scoping.