Migrate from actiTIME to Microsoft Project

actiTIME Customers map directly to Microsoft Project plans. In Project for the web, each Customer becomes a Project object with the customer name as the project name. In Project Online, the Customer maps to a Project Site. We preserve the actiTIME Customer description as the project description field. Archived customers are migrated as inactive projects. Note that Microsoft Project does not support a true parent-level above Project (unlike actiTIME's Customer), so organizations using actiTIME Customers to group unrelated business units will need to document the grouping logic in the migration handoff for manual restructuring in Microsoft Project.

actiTIME Projects map to the top-level container within a Microsoft Project plan. The actiTIME project name, status (active/archived), deadline, and estimated hours transfer to the Microsoft Project project summary task or project-level fields. If the destination is Project Online, we map to the Project Detail Page fields. Estimated hours become a custom field (Estimated Hours) rather than a native scheduling field since Microsoft Project calculates schedule from start/duration dependencies, not from hour estimates.

actiTIME Tasks require transformation into a Microsoft Project WBS. The actiTIME parent-child project-task hierarchy maps to Summary Task and sub-task structure, but actiTIME stores no duration, start date, or dependency data natively — these must be inferred or calculated. We derive task duration from actiTIME deadline minus estimated start (defaulting to project start date if no individual start is recorded). Dependencies between tasks are not present in actiTIME and must be inserted manually or inferred from task sequence order; we document the inferred dependency graph in the migration report and the customer's PMO rebuilds critical path dependencies post-migration. Custom workflow statuses from actiTIME map to custom task-level fields since Microsoft Project does not have a native workflow status concept.

actiTIME time-track entries (logged hours per user per task per date) consolidate into Microsoft Project actual work on the corresponding task. Multiple entries for the same task across dates and users merge into a single actual work value. A key constraint: Microsoft Project tracks either % complete OR actual hours, not both simultaneously — if the customer's actiTIME instance uses both, we use actual hours as the primary mapping and document % complete gaps. For completed tasks with logged hours but no completion date, we infer % complete from the time-track total versus the actiTIME task estimate. Time-track comments migrate to task notes as a text block per task.

actiTIME Users map to Project resources. We export the full user roster including inactive users (for historical assignment context) and map to Microsoft Project resources with the user's display name and email. Active/inactive status maps to Resource Standard Rate Active flag. actiTIME time-zone group assignments have no Microsoft Project equivalent — we document timezone information as a custom resource field. Note that Microsoft Project for the web uses the Microsoft 365 user directory as its resource pool, so any actiTIME user without a Microsoft 365 license must be provisioned before or during migration.

actiTIME custom fields per task migrate to Microsoft Project custom fields where the destination field type supports the mapping. Text custom fields map to Text custom fields; numeric fields map to Number custom fields; date fields map to Date custom fields. Multi-select custom fields (checkbox groups) do not have a native Microsoft Project equivalent and are documented as text lists in a Notes-style custom field. Custom fields on Customers and Projects map to project-level custom fields. We pre-create all destination custom fields during the schema design phase before data migration begins.

actiTIME Types of Work categorise time-track entries (e.g., Development, Meeting, Research). Microsoft Project has no native type-of-work taxonomy. We map Types of Work to a task-level custom field (Type of Work) with the applicable values as a picklist. Each time-track entry's type-of-work value is aggregated into a comma-separated list on the task's custom field since a single actiTIME task may have multiple Types of Work logged across entries.

actiTIME custom workflow statuses are feature-gated by the taskWorkflow flag in the instance /info endpoint. Where enabled, workflow stages are exported as a list and mapped to a task-level custom field (Workflow Stage) with the applicable status values as a picklist. Since Microsoft Project does not have a native workflow state machine, task workflow progression must be managed manually post-migration or rebuilt in Power Automate as a separate automation project.

actiTIME leave-time records (where leavetimeRegistration is enabled in the source instance) have no Microsoft Project equivalent. Microsoft Project does not track leave, PTO, or absence. We export the leave-time records as a separate CSV inventory during migration and document this data for the customer's HR system administrator to import into their absence management tool (Microsoft Dynamics 365 HR, BambooHR, or equivalent) separately from the project migration.

actiTIME Time Zone Groups group users by timezone for reporting across distributed teams. This concept is not native to Microsoft Project. We export the TZG roster and user assignments, then map the primary timezone to a resource-level custom field (Time Zone) on each Project resource. This preserves the information for reporting and workload analysis even though Microsoft Project does not use timezone data in its scheduling engine.