Migrate from ITM Platform to Microsoft Project

ITM Portfolios contain Programs and Projects in a strict parent-child hierarchy. Microsoft Project has no native Portfolio object. We extract the full Portfolio tree — the Portfolio record itself, all child Programs, all child Projects, and the containment order — as a structured JSON dataset that the customer's PMO admin uses to manually recreate the portfolio structure in MS Project, Planner Roadmap, or a SharePoint-based portfolio view. The dataset preserves portfolio-level strategic alignment tags and KPI targets as extended properties.

ITM Programs sit between Portfolio and Project in the hierarchy and carry strategic alignment tags. MS Project has no native Program object. For organizations with fewer than 15 programs, we map each Program to a top-level Summary Task within its corresponding project file, with the Program name stored as the Summary Task name and alignment tags preserved as custom fields on that task. For organizations with more than 15 programs, we recommend splitting each Program into a separate MS Project file and using a SharePoint document library or Planner Roadmap to maintain the program-level rollup. The customer selects the preferred strategy during scoping.

ITM Projects map directly to individual MS Project files (.mppx or .xml for Project Online compatibility). We migrate Project name, description, start date, finish date, status, owner, and budget. The ITM Project hierarchy level (Portfolio/Program child) is stored in a custom field itm_parent_type__c and the parent container name is stored in itm_parent_name__c to preserve the containment relationship in the absence of a native Portfolio/Program object. Active and archived projects migrate together unless the customer specifies a cutoff date.

ITM Tasks map to MS Project tasks with name, description, start date, finish date, duration, priority, and status preserved. Parent-child task hierarchy migrates as Summary Tasks (parent) and regular tasks (children) using MS Project's built-in outline structure. Task-level constraints from ITM (Must Start On, Finish No Later Than, As Soon As Possible) map to MS Project task constraint types. Estimated hours from ITM migrate to the MS Project task's Work field using the assignment's default units.

ITM Subtasks nested under Tasks have no direct MS Project equivalent at a second-level hierarchy depth. We flatten Subtasks into the parent MS Project task as a structured note block prefixed with [SUBTASK], preserving the subtask name, assignee, and completion status. For ITM Subtasks that carry their own dates independent of the parent, we create a separate regular task sibling to the parent task and flag it with a custom field itm_subtask_of__c pointing to the original parent task name, preventing date dependency conflicts in the MS Project schedule.

ITM Platform stores unlimited Baselines per project capturing schedule, cost, and revenue snapshots across multiple planning scenarios. MS Project supports a single Baseline per project with up to ten Interim Updates. We extract all ITM Baseline records and package them as a structured JSON dataset (baseline_name, snapshot_date, schedule_data, cost_data, revenue_data) attached to the corresponding MS Project file as a reference document. The primary ITM Baseline is loaded into MS Project as the working Baseline; additional baselines are preserved in the dataset for manual comparison within MS Project or export to Excel for side-by-side scenario analysis.

ITM Milestones are standalone date-driven markers that can belong to Projects or Tasks. We map each Milestone to an MS Project milestone task (duration = 0) with the milestone name and date preserved. If the ITM Milestone belongs to a specific Task, we attach the milestone as a task note on the corresponding MS Project task with a reference to the ITM milestone identifier. ITM milestone priority and custom fields migrate to MS Project custom fields on the milestone task.

ITM Platform custom fields are entity-scoped (Project, Task, Risk, Purchase). MS Project supports up to ten custom fields per object (Text, Flag, Number, Cost, Date, Duration, Outline Code). We map each ITM custom field definition to the closest MS Project custom field type and create the corresponding custom field in each MS Project file before data import. Multi-select or tag-style ITM custom fields map to MS Project Text fields with comma-separated values. Custom fields that exceed the MS Project field type (e.g., ITM stores a URL in a text field but it needs to be a hyperlink) are stored as Text with a flag note.

ITM Platform Risk entities with probability, impact, owner, and mitigation plan have no native MS Project equivalent. We extract all Risk records and package them as a structured JSON dataset (risk_id, name, probability, impact, owner, mitigation, associated_project, associated_task) that the customer's PMO admin imports into a SharePoint list, a Planner plan, or a Dataverse table via Power Platform as a cross-reference lookup. We do not create MS Project tasks for Risks by default because task-level risk flags are not a standard reporting construct; the customer chooses the risk management destination during scoping.

ITM Platform Purchase entities linked to Projects with amount, vendor, status, and custom fields have no native MS Project equivalent. We extract all Purchase records and package them as a structured dataset (purchase_id, project_name, amount, vendor, status, custom_fields) that the customer's admin imports into a SharePoint list or Power Platform table for cross-reference. We do not map Purchases to MS Project task-level cost fields because ITM Purchases are procurement commitments, not resource-based task costs, and conflating the two distorts the project budget view.

ITM Platform Users referenced across Tasks, Risks, and Purchases map to MS Project Resources. We extract all ITM user records (name, email, role) and create MS Project Resources using the user's display name as the Resource Name and email as the Resource Initials or Notes field. The ITM user role maps to the MS Project Resource Group field. Where a task has an ITM assignee that is also a Resource, we create a corresponding Assignment in MS Project with the original estimated hours from ITM mapped to the Work field. Orphaned assignees (ITM users with no corresponding MS Project resource) are flagged in the reconciliation report for admin resolution before project file finalization.

ITM Platform Time Entries with date, hours, user, and description have no native MS Project equivalent. We extract all time entry records and attach them as structured notes on the corresponding MS Project task (prefixed [TIME ENTRY: date | hours | user]). For organizations that need time-entry reporting, we package the full time-entry dataset (task_name, itm_task_id, date, hours, user_email, description) as a separate CSV that the customer's admin imports into a SharePoint list or Power BI report for cross-reference. We do not aggregate time entries into the MS Project task's Work field because ITM time entries represent actual logged hours and MS Project Work represents planned effort — mixing the two obscures both schedule variance and actual cost calculations.