Migrate from ]project-open[ to Microsoft Project

]project-open[ project_id maps to a new Microsoft Project (.mpp) plan or Project for the web project. We extract project_name, project_status_id (potential/active/closed), start_date, end_date, percent_complete, and any baseline or forecast cost fields. The acs_objects hierarchy preserves parent-child project groupings. If the customer uses Project for the web (Planner consolidation target), we use the Microsoft Graph API to create projects; for Project Desktop, we build a validated .mpp file from the extracted schema.

Tasks are stored by task_id referencing the project tree. We traverse the task tree by querying task and the parent-child relationship fields, then write each task into Microsoft Project with the correct WBS hierarchy, outline level, duration, start/finish dates, and predecessor/successor dependencies. The Microsoft Project predecessor field maps from ]project-open['s task dependency records stored in im_timesheet_task_dependency or equivalent dependency tables. Constraint dates, delay (lag), and task type (fixed duration, fixed work, fixed units) are mapped from the source task_type and constraint configuration.

]project-open[ stores resource assignments via acs_rels and the im_timesheet module. We extract user_id, first_names, last_name, and email from the acs_users table, and map availability and calendar data from im_timesheet_plan entries. Assignments in Microsoft Project require the resource to exist in the resource sheet before assignment records are written. We create Resources from the user list, set Max Units to 100% by default, and optionally import cost rates from any im_cost_center_rates data if the customer requests cost-based resource planning in Microsoft Project.

]project-open[ task assignments (user to task with hours or percentage) live in im_timesheet_task_initial_metric or im_timesheet_tasks. We map these to Microsoft Project Assignment records (Task ID + Resource ID) with the Work field set from the source hours. Assignment-level actual work, remaining work, and actual start/finish dates migrate if source data is available in the timesheet or cost tracking module.

]project-open[ stores working hours and exceptions in im_hours_per_day and im_calendar_exception tables. We reconstruct a Microsoft Project calendar from these records, setting the base calendar working time and exceptions (holidays, non-working days) to preserve the project schedule accuracy. Resource calendars in Microsoft Project are set to the default Standard calendar unless source data provides per-resource exceptions.

]project-open[ dynamic custom attributes per project or task are discovered by querying the attribute storage tables before migration. We create Microsoft Project Enterprise Custom Fields with matching types (Text, Flag, Number, Date, Cost, Duration) in the destination. Outline Text custom fields are used for ]project-open[ category or classification fields. The mapping is limited to 10 custom fields per object type on Project for the web; Project Desktop has no such limit. Customers with more than 10 custom fields per type must prioritise the highest-value fields or use Project Plan 5 with Project Online which has a higher custom field ceiling.

Companies in ]project-open[ (im_companies) store customer and provider records with object_type_id, company_status_id, and contact links. Microsoft Project has no company or account object. We do not migrate companies as records. If the customer requires company context on tasks, we can write company name or ID into a custom text field on the task or project for reference. Full company and contact data should be migrated to a CRM system separately.

Tickets (im_tickets) with ticket_status_id, ticket_type_id, assignees, and conversation threads have no Microsoft Project equivalent. Project management systems do not track support tickets as a core object. We do not migrate tickets. We can export ticket records to a CSV for the customer's review and recommend a helpdesk system (Zendesk, Freshdesk, or ServiceNow) for ticket data. Issue tracking that is purely project-level (blockers, risks) can be written into a Microsoft Project task with a custom flag or note field.

Financial records in ]project-open[ (im_costs with variable_cost_p, invoice amounts, billing status) map to project cost fields in Microsoft Project at best (cost type, total cost, budget). However, invoice generation, billing workflow, accounts payable/receivable, and cost-centre hierarchies have no Microsoft Project equivalent. We do not migrate financial records. We can export them to CSV and map any project-level budget costs to Microsoft Project task or summary cost fields if the source data is structured accordingly.

Timesheet hours logged against projects and users (im_timesheet costing entries) do not map to Microsoft Project native objects. Actual work data in Microsoft Project is assignment-level and is used for earned value analysis, not for billing or financial reporting. We do not migrate timesheet billing records. If the customer needs actual work hours imported, we can write them as actual work on Microsoft Project assignments, but this overwrites any hours already tracked post-migration.