Migrate from SMART Project Control to Microsoft Project

SMART Project Control Programs act as top-level grouping containers with cross-project rollup reporting. Microsoft Project has no native Program object; we handle the grouping by either creating a Master Project with subproject files (desktop and Project Plan 5) or using Project Online's portfolio grouping in Project for the Web. Cross-project dependencies between programs are flagged as requiring manual rebuild as either cross-project predecessor links or Power BI dependency views.

Each SMART Project maps to one Microsoft Project file (MPP) or one Project Online project. Core project-level attributes — name, start and finish dates, status, calendar, and schedule mode — migrate 1:1. We flag any project-level custom properties for field-level mapping and verify that the calendar type (standard, 24-hour, night shift) is compatible with Microsoft Project's calendar structure.

The latest approved baseline migrates as a static schedule snapshot in Microsoft Project's Baseline fields. SMART stores multiple baselines per project; we migrate the most recently approved baseline as Microsoft Project's Baseline (BL) and flag remaining baselines as Baseline1 through Baseline10 if the destination license supports saved baselines. Earned value source values (PV, EV, SV) are stored as custom fields for reference since the destination engine will recalculate EV independently.

Activities are the core scheduling unit in SMART Project Control and map to Tasks in Microsoft Project. Dates, duration, and calendar assignments migrate directly. We rebuild predecessor-successor relationships using Microsoft Project's dependency types (FF, FS, SS, SF), mapping SMART's relationship definitions to the equivalent Finish-to-Start default unless the source uses non-standard dependency types that require explicit mapping.

WBS elements define hierarchical accountability in SMART Project Control. Microsoft Project does not have a native WBS object; we map WBS levels to Outline Codes (Project Plan 5 or Project Standard/Professional with enterprise features enabled) or use Summary Task indentation as a structural proxy. Element-level custom properties on WBS nodes migrate as custom outline code values or custom fields depending on the destination license tier. We flag any WBS custom fields that exceed the 10-custom-field ceiling for prioritization decisions.

Labor, material, and equipment Resources from SMART — including role definitions, rates, and unit-of-measure — migrate as named resources in Microsoft Project's resource pool. Resource calendars migrate as individual resource calendars attached to the resource. We verify that unit-of-measure conventions match between source and destination and flag any material resource types that may need conversion to a consumable resource model in Microsoft Project.

CBS levels and cost accounts map to Microsoft Project's cost coding schema. Time-distributed cost data (period buckets from SMART's cost histogram) is converted to activity-level cost assignments using Microsoft Project's Cost field for labor and a separate material resource for material cost where applicable. We flag CBS levels that exceed a three-level depth for restructure recommendations, as Microsoft Project's flat cost structure is best suited to simpler cost coding hierarchies.

Custom activity, project, and resource fields export with their current values and types. Microsoft Project (Project Plan 3 and Plan 5) supports up to 10 custom fields per project across Task, Resource, and Project custom field types. We require explicit prioritization from the customer during scoping to select the 10 fields that carry forward natively; remaining custom fields are preserved in a written field inventory for manual entry or Power BI reference post-migration.

Cumulative S-curves and progress curves export from SMART Project Control as time-phased data rows per project. On import, we convert them to Microsoft Project's Earned Value table format (PV, EV, AC at each data point) or store as time-phased data table rows if the destination version supports it. We validate the S-curve reconstruction against the source by comparing total project cost and milestone alignment before sign-off.

Critical path and float values are preserved when Microsoft Project recalculates the schedule post-import. We document the expected critical path from the SMART source schedule as a reference document and validate that the destination's scheduling engine produces an equivalent critical path within a defined float tolerance (typically one day per activity). Non-critical path relationships that reference activities on the critical path are flagged for review.

Earned value planned value, earned value, schedule variance, and cost variance are often stored as derived metrics in SMART rather than raw fields. We preserve the source-calculated EV values as static custom fields on the Task record so the customer has an audit trail of the source values. Microsoft Project's EV engine will recalculate independently; we document the variance between source and destination EV values as part of the validation report so the project controls team can assess materiality.

Forecasting rules and bottleneck alerting logic are SMART Project Control features with no Microsoft Project equivalent. We deliver a written inventory of every active forecast and alert rule, including its trigger conditions, threshold values, and notification action, so the customer's project controls team can rebuild these as Power BI threshold alerts, SharePoint workflow notifications, or Planner task rules depending on the Microsoft tooling in use.