Migrate from Birdview to monday Work Management

Birdview Spaces are the top-level organizational container and map to monday.com Workspaces as the primary hierarchy. If the source account uses nested Spaces or Portfolio-level groupings, we map those to monday.com Folder structure within Workspace or to Board-level Groups, depending on the depth of the source hierarchy. The customer chooses the organizational strategy during scoping. Workspace name and description migrate as-is.

Birdview Projects map directly to monday.com Boards. Project name, description, status, start date, due date, and owner assignment migrate as Board name, Board description, Board status, and member assignment. Project budget fields from Birdview Enterprise do not have a native monday.com equivalent — we flag these as custom column requirements or document them for a third-party integration (such as a budget tracking Workdoc or a connected financial tool).

Birdview Activities — encompassing Tasks, Issues, and Requests under one umbrella — map to monday.com Items. The Activity type label (Task, Issue, Request) is preserved as a custom Status group or a Select column in monday.com so that the distinction is visible without requiring a separate board. Issue-specific fields (priority, resolution status) map to monday.com Priority column and custom text fields. Request-specific custom form data migrates field-by-field after the form schema is enumerated during discovery.

Birdview Portfolio hierarchy (available on Enterprise) groups Projects for executive oversight. monday.com has no native Portfolio object. We map Portfolios to Folder structure within Workspace (if the account uses the Folder feature) or to Board Groups with a naming convention that preserves the Portfolio name. The customer's monday.com plan tier determines Folder availability; we verify this during scoping. If Portfolio analytics are critical, we document the dashboard rebuild requirement for the admin.

Birdview custom fields are tenant-defined and applied per object. Each custom field definition must be enumerated during discovery before field-level mapping can begin. We map text fields to monday.com Text columns, date fields to Date columns, number fields to Numbers columns, and multi-select fields to Dropdown or Tags columns. Boolean fields map to Checkbox columns. The key constraint is that Birdview custom field schemas are global per object type while monday.com custom columns are board-level; we document any schema differences that affect cross-board reporting after migration.

Birdview Time Entries are linked to Activities and carry billable/non-billable flags, hours, and date. monday.com's native time tracking (available on Pro and above) uses a Time Tracking column on Items. We map time entries to Items representing the source Activities with hours logged in the Time Tracking column. The 0:01-hour minimum enforcement in Birdview is flagged: any record with exactly 0:01 hours that a customer wants zeroed out in monday.com must be handled outside the migration scope since the minimum does not apply in monday.com's time tracking. We provide a list of minimum-floor records for the customer to resolve manually or accept as-is.

Birdview Expenses are tied to Activities and Projects with cost center, amount, date, and approval status. monday.com has no native expense tracking on any tier. We map expense records to a custom Number column (amount) and Select column (approval status) on the corresponding Items, or we export them as a structured Workdoc that the customer's admin reviews and imports manually. The approval workflow status from Birdview Enterprise is documented for the admin to recreate as monday.com Status labels.

Birdview Rate Cards define billing rates per user or role. monday.com has no native rate card or billing rate object. We export rate card definitions as a structured Workdoc with the role, rate, and currency preserved, and we map individual time entries to a custom Number column that can be multiplied by the applicable rate outside monday.com. The customer decides whether to recreate rates as a connected billing integration or maintain them as a reference document.

Birdview user types govern data visibility: Collaborators cannot access financial information and Executives have limited editing. monday.com has Member, Guest, and Admin roles. We map Full Users to Members, Viewers and Collaborators to Guests, and designated Admins to Admin. The visibility restrictions that Birdview enforces at the user-type level do not automatically translate to monday.com permission settings; we document the access scope for each migrated user type so the customer's admin can configure the corresponding permission set in monday.com.

Birdview Approvals are tied to expense and time workflows with a status trail. monday.com has no native approval object. Open approvals at migration time must be resolved or re-opened in monday.com. We export the approval history as a Workdoc with the approver, date, and status for audit purposes, and we document which monday.com Status labels correspond to each Birdview approval stage for the admin to implement as a manual or automation-based workflow post-migration.

Birdview Workflows govern task routing and approval chains. monday.com's Automation Builder uses a different trigger-and-action model. We do not migrate Workflows as code. We deliver a written inventory of every active Birdview Workflow with its trigger conditions, actions, and routing logic, plus a recommended monday.com Automation Builder equivalent. The customer's admin rebuilds these in monday.com post-migration.

Documents and file attachments linked to Activities and Projects migrate as file uploads attached to the corresponding Items in monday.com. We use monday.com's file upload column to store the file reference and the original filename. Large attachments (over 250 MB per file) are flagged for the customer to handle via a connected storage integration (Google Drive, SharePoint) post-migration.