Migrate from ActionPlanner to Microsoft Project

ActionPlanner Objectives are the top-level strategic containers with title, description, owner, start date, and target date. We map each Objective to a Microsoft Project file (Plan 3 with Project for the web) or as a top-level Summary Task row if consolidating multiple Objectives into a single schedule. The Objective name becomes the Project Summary field or Summary Task Name. Owner maps to the Project Manager field. Target date maps to Project Finish Date.

ActionPlanner KPIs are numeric or percentage-based indicators attached to Objectives with a name, target value, and current value. Microsoft Project supports custom number fields (Number1-20) and cost fields (Cost1-10) on tasks that function as KPI tracking columns. We extract the KPI name as the custom field label and map current and target values into two separate custom fields. If the customer uses Project Online, KPIs can alternatively map to custom columns in the PWA grid view. KPI calculation logic does not transfer; the customer configures baseline or target columns post-migration.

ActionPlanner Initiatives are mid-level breakdowns of Objectives with purpose, deadline, owner, and child Milestones. We map each Initiative to a Microsoft Project Summary Task row that summarizes its child Milestones and Actions. The Initiative name becomes the Summary Task Name; Initiative deadline maps to the Summary Task Finish date. We preserve the parent-objective linkage in a custom text field initiative_parent__c for reconstruction if the outline structure is not preserved during import.

ActionPlanner Milestones are time-bound checkpoints within an Initiative. We map Milestones to Microsoft Project tasks with Duration = 0 and the Milestone flag set to Yes. Title, due date, status, and owner migrate directly. The milestone_links to its parent Initiative are preserved via the summary task outline structure (Milestone indented under its Initiative Summary Task) and reinforced with a custom field milestone_parent_initiative__c.

ActionPlanner Actions are the atomic execution units — individual to-dos with a deadline and assignee. We map Actions to Microsoft Project Tasks with the action title as Task Name, the due date as Task Finish Date, and the assignee to a Resource. Status maps to the % Complete field. We flatten deeply nested action hierarchies (where an Action has child Actions) by creating a flat task list indented under its parent Milestone Summary Task, and we include a custom field action_parent_action__c so the relationship can be manually rebuilt in Project if the outline depth exceeds the customer's preferred structure.

ActionPlanner Roadmaps are the top-level containers holding all Objectives, KPIs, Initiatives, Milestones, and Actions. The TEAM plan is limited to 1 roadmap; higher tiers allow multiple. In Microsoft Project Plan 3, each roadmap maps to a Project file or a Planner Plan. If the customer is consolidating multiple source Roadmaps into a single destination schedule, we flag the plan tier required and recommend confirming Project Plan 3 licensing before migration day. We create one Project per Roadmap during migration.

ActionPlanner assigns owners to Objectives, Initiatives, Milestones, and Actions. We extract owner names and email addresses and map them to Microsoft Project Resources. The resource email becomes the Resource Email field. If the owner has no corresponding Resource in Project, we create the Resource record and flag it in the reconciliation report for the customer's admin to assign to the correct person. Role-based or permission-hierarchy information is flat in the CSV export and does not map to Project's resource role or booking model.

ActionPlanner instances may include custom fields on Initiatives, Milestones, or Actions (text, number, date, or dropdown). Microsoft Project (Desktop and Project Plan 3) supports custom text, number, flag, date, and finish date fields at the task level. We map each custom field to the corresponding Project custom field type, flagging any unsupported field types (for example, ActionPlanner multi-select dropdowns with no Project equivalent) as requiring manual post-migration entry or a Project Desktop VBA macro for bulk population.

ActionPlanner supports collaborative decision logging and discussion threads around plans and actions. The platform does not expose a documented export for conversation history or decision logs. We flag this as a data loss area during scoping and exclude it from the migration payload. The customer's admin documents any critical decisions that need to be preserved externally. Microsoft Project's SharePoint-linked project sites can host a decision log manually post-migration.

ActionPlanner does not expose task dependencies or cross-initiative links in its export format. If the customer's ActionPlanner instance includes informal dependency notes (for example, Action B must follow Action A recorded in the action description field), we extract those strings into a custom text field dependency_notes__c on the relevant tasks. The customer's project manager rebuilds these as Finish-to-Start or Start-to-Start dependencies in Project manually post-migration. We do not auto-generate dependency links from unstructured text without explicit confirmation from the customer.