Migrate from Birdview to Microsoft Project

Birdview Spaces are top-level workspaces that contain Projects and define permission boundaries. Microsoft Project has no native Space equivalent. We map each Space to a SharePoint site or Microsoft 365 Group that contains the migrated Projects, preserving the organizational hierarchy as a folder structure or Planner bucket tagging scheme. If the customer uses Project for the web (Planner premium), we map Spaces to separate Plans with cross-Plan Roadmap views for executive visibility.

Birdview Projects map directly to Microsoft Project Projects or Planner Plans. Fields map as: Project Name (Title), Status (Status field or custom status column), Start Date and End Date (Start and Finish), Owner (Assigned To or Project Manager custom field), Budget (Cost or Budget custom fields available in Project Plan 3 and above). We preserve the Project-level custom fields by mapping them to Microsoft Project Enterprise Custom Fields.

Birdview Activities are a single object with three subtypes: Task, Issue, and Request, distinguished by an Activity Type property. Microsoft Project has one Task object. We preserve the Activity subtype as a custom text field (ActivityType__c) on each migrated Task so that Issue and Request records retain their origin. Priority and Resolution fields from Issues map to Task Priority and a custom Resolution text field. Request-specific custom form fields map individually as custom fields on Task.

Birdview Portfolios group Projects for executive oversight. Microsoft Project does not have a native Portfolio object; cross-project visibility requires either Project for the web with the Roadmap feature (Planner premium Plan 3 or Plan 5) or manual grouping via SharePoint site organization. We migrate Portfolio membership as a custom Project field (Portfolio__c) that the customer uses to filter in Planner or Power BI. Portfolio hierarchy on Enterprise is mapped as a nested grouping field.

Birdview time entries are linked to Activities and Users with a minimum 0:01 hour enforcement. Microsoft Project does not have a native time-entry object; logged hours appear as Work on Task Assignments. We map Birdview time entries to Task Assignment records, setting the Work field in hours. Zero-value entries cannot exist in Birdview; we flag every record that hits this floor and present two options: accept the 0:01 minimum in Microsoft Project or handle zero-value records as a separate export for the customer's financial system. Time entry approval status is preserved as a custom field.

Birdview Expenses are PSA records tied to Activities and Projects with cost center and approval status. Microsoft Project has no native expense object. We map Expenses to a custom Expense list (SharePoint list or Excel attachment) linked to the Project, or we export them as a structured CSV for import into the customer's financial system. The migration scope covers expense record extraction and format transformation; ongoing expense tracking after migration requires the customer to maintain a separate process or connect to an ERP integration.

Birdview Rate Cards define billing rates per user or role. Microsoft Project has no native rate card object. We export Rate Card definitions as a structured mapping table (User or Role to Hourly Rate) that the customer configures in the Resource Sheet under Resource Costs, or we deliver it as documentation for their finance team to set up in Microsoft Dynamics 365 Project Operations as a separate engagement.

Birdview's four-tier user model maps to Microsoft 365 User accounts and Project-specific role assignments. Full Users map to Project Plan 3 or Plan 5 licenses with Contributor or Admin roles. Collaborators and Executive Viewers map to Project Plan 1 or Planner basic licenses with Viewer permissions. We map the permission scope (what records each role can see in Birdview) to the equivalent SharePoint site permissions or Planner plan roles. Collaborator financial data access requires manual verification in the destination.

Birdview allows unlimited tenant-defined custom fields on Projects and Activities. Microsoft Project Online supports Enterprise Custom Fields (text, number, date, flag, lookup); Project for the web supports custom columns. We enumerate all Birdview custom field definitions during discovery, map each to the nearest Microsoft Project field type, and create the corresponding custom fields in the destination before migration. Fields with unsupported types (multi-select, formula, or checkbox with multiple values) are documented for the customer to handle as manual post-migration configuration.

Birdview Workflows govern task routing and approval chains. Microsoft Project has no native workflow engine; automation rebuilds happen in Power Automate or SharePoint Designer. We do not migrate Workflows as code. We extract every active Birdview Workflow definition — its triggers, conditions, actions, and approvers — and deliver a written configuration inventory with recommended Power Automate equivalents. The customer's admin or a Microsoft partner rebuilds them post-migration. Open approvals at migration time are flagged and resolved before cutover.

Birdview Approvals are tied to expense and time entry workflows. Approval history migrates as a log (record of who approved what and when). Open approvals at migration time must be resolved or re-opened in the destination; we deliver a list of all open approvals with owner and amount. Power Automate Approvals are the standard replacement for approval routing in the Microsoft ecosystem. We document the approval chain from Birdview and map it to a Power Automate template structure.

Birdview Activity assignments link a User (or Role) to an Activity. Microsoft Project Task Assignments link a Resource to a Task. We map Birdview assignments to Task Assignment records, resolving the Birdview User to the Microsoft 365 User in the destination. Role-based assignments are resolved to named Resources in the Resource Sheet at migration time.