Migrate from zeno.pm to monday Work Management

Each zeno.pm Project maps to a Monday.com Board when the project has independent scope, or to an Item within a Programme Board when the migration strategy consolidates multiple projects into a single parent board. We preserve project name, description, status (Draft/Active/On Hold/Closed), owner, start date, and end date as typed columns. zeno.pm stores dates as project-level properties rather than independent date objects, so we extract each date field individually and map it to a Monday Date column. Custom project fields from zeno.pm's form-builder require schema extraction from vendor support before mapping to Monday column types.

Each zeno.pm Program maps to a Monday.com Board with groups representing its child Projects, or to a Group within a Programme Board if multiple programs share a single board. We preserve the program-to-project parent-child relationship by creating the Program Board before importing any child Project items, then resolving the parent reference during item creation. Program-level financial roll-ups and status aggregate child project data at import time rather than dynamically.

Each zeno.pm Portfolio maps to a Monday.com Workspace containing Boards for its child Programs and Projects. We create the Workspace first, then create Programme Boards inside it with Project items or sub-boards as children. Portfolio-level KPIs and roll-up metrics migrate as read-only number columns or Summary Dashboard widgets rather than live-linked roll-ups, since Monday's native cross-board aggregation requires third-party BI tools or Enterprise-tier Portfolio features.

zeno.pm Risks are structured records attached to a Project with fields for title, likelihood, impact, status, owner, and mitigation notes. We map these as Items within the Project's Board (or as subitems if the board structure uses subitems for detail records). Likelihood and impact map to Status columns or number columns; risk owner maps to a Person column. The complete risk register migrates as a structured set of items so that monday.com's filtering and timeline views can operate on risk data alongside project tasks.

zeno.pm Issues share a similar schema to Risks with title, priority, status, owner, and description fields. We map them identically: Items within the Project Board or subitems. Priority maps to a Status column with values (Critical/High/Medium/Low) or a Priority column type if available on the customer's Monday plan. Issue and Risk records are separated into distinct Groups within the board so that teams can filter by record type without relying on a type tag.

zeno.pm stores project budget, actuals, and forecast data as project-level properties. We map these to Monday Number columns (configured as currency if the plan supports it) or create a connected spreadsheet via monday.com's integrations if the financial model requires multi-row line-item detail that does not fit a single item. The customer chooses the financial mapping strategy during discovery based on the complexity of the source financial model.

zeno.pm tracks team member assignments to projects and programs with role, allocation percentage, and availability data. We map resource names to Person columns on Project items, with allocation percentage stored as a Number column. If monday.com's Workload View is available on the customer's plan, we create a separate resource capacity board and use the Workload integration to surface allocation. Pure resource capacity and utilisation data that does not attach to a specific task is held as a resource roster board rather than individual item columns.

zeno.pm stores milestone dates and schedule data as project-level date properties rather than as independent schedule objects. We extract each milestone date individually and map it to a Monday Date column on the relevant item. If a project has multiple milestone dates (kick-off, review, delivery), we create separate Date columns for each. Dependencies between milestones map to Monday's Dependency column if available on the plan; otherwise they are documented as manual dependency notes in a Text column.

zeno.pm custom fields defined via its form-builder on Projects, Programs, and Portfolios have no public API documentation. We extract the complete field schema during discovery by requesting it from zeno.pm support, then map each field to the nearest Monday column type (Text, Number, Date, Status, Person, Checkbox, Dropdown). Conditional visibility rules and picklist dependencies do not migrate; these are documented in the handoff notes for the customer's admin to recreate within Monday's column configuration.

zeno.pm embeds AI features that generate or enrich project data such as summaries or risk flags. We identify records with AI-generated content during profiling, preserve the output as-is in a Text column, and flag it in the handoff notes as content that should be reviewed for accuracy post-migration since it may reference zeno.pm-specific context that does not transfer to Monday.

Documents, images, and files attached to Projects, Programs, or Risks in zeno.pm cannot be retrieved via a public API. We inventory all attachment references (file name, linked record, upload date) and present the customer with a manual re-upload checklist organised by project during the handoff. File names and link context are preserved in the checklist so that the attachment structure can be recreated in Monday without losing record association.

zeno.pm's pre-configured reporting suite consists of server-rendered report templates and dashboard configurations that are not exposed via a documented API. We migrate all underlying data — financials, risks, issues, timelines, milestones — so that equivalent reports can be rebuilt in Monday. We document the complete list of active zeno.pm reports and their data sources during discovery to guide the rebuild effort, which falls to the customer or a consultant as a manual post-migration step.