Migrate from Blueprint to monday Work Management

Blueprint Projects are the root container for Scopes and Tasks. We map each Blueprint Project to a monday.com Board as the top-level container. The Project name becomes the Board name. Project-level metadata (description, start date, due date) migrates to Board columns we create as part of the schema design phase. Board privacy settings (public, private, shareable) are configured to approximate Blueprint's role-based project access.

Blueprint Scopes are AI-generated work breakdown units within a Project. We map each Scope to a monday.com Group within the parent Board. The Scope name becomes the Group name. Scopes that contain sub-scopes in Blueprint are flattened into sibling Groups with a naming convention that preserves the hierarchy (e.g., Scope-A / Sub-Scope-B as two groups with shared naming prefix) since monday.com Groups do not support nested sub-groups natively.

Blueprint Tasks are the atomic work units within Scopes. We map each Task to a monday.com Item placed inside the Group that corresponds to the parent Scope. Task fields (status, assignee, due date, priority) map to monday.com column types: Status column, People column, Date column, and either a Label column or a dropdown for priority. Task creation timestamps and last-modified timestamps preserve as ActivityDate for the Item.

Blueprint's role-based access model uses named roles assigned per project. monday.com's permission model operates at workspace level (member, admin) and board level (board owner, board member, subscriber, viewer). We map Blueprint roles to monday.com Teams and assign board-level permissions that approximate the original access scope. If a Blueprint role grants view-only access to a project, we assign subscriber or viewer permission on the corresponding monday.com Board. If the role grants edit access, we assign board member. Role semantics are not equivalent; we document the translation decisions in the permission matrix deliverable.

Blueprint stores Task-to-User assignments as user IDs linked to Task records. We map these to monday.com People column values on the corresponding Items. We resolve the Blueprint user ID to a monday.com User by email match. Any Blueprint user without a matching monday.com User account goes to a reconciliation queue for the customer's admin to provision before record import resumes.

Blueprint supports custom fields on Projects and Tasks. monday.com supports custom columns on Boards. We create monday.com columns with the appropriate column type (Text, Number, Dropdown, Date, Link, Checkbox, Rating, etc.) to approximate each Blueprint custom field. Complex Blueprint field types that have no direct monday.com equivalent (e.g., multi-select arrays stored as structured objects) are documented with a recommended column configuration and stored as JSON in a Text column if the data cannot be decomposed cleanly.

Blueprint attachments are referenced by URL or stored object ID. monday.com supports a Files column type for native uploads and a Link column type for URL references. We map URL-based Blueprint attachments to monday.com Link columns pointing to the original resource. Files that were uploaded to Blueprint and stored on Blueprint's infrastructure are flagged for manual re-upload to monday.com since we cannot extract binary files from an undocumented storage backend. We document the full list of attachment URLs for the customer to review during scoping.

Blueprint automation rules are stored as structured configuration tied to project events (e.g., when Scope status changes, assign Task to User). These do not migrate as code. We inventory every Blueprint automation rule during discovery, document the trigger, conditions, and actions in plain language, and deliver a monday.com Automations rebuild specification (for simple if-then rules) and a monday.com Workflows rebuild specification (for multi-step branching processes) that the customer's admin executes post-migration.

Blueprint preserves task creation date, scope start date, and project initiation timestamps. We map these to monday.com column types: a Created At system column (auto-populated), and Date columns for any explicit start or target dates stored in Blueprint. Task state transitions (e.g., Task moved from in-progress to complete) are not stored as separate activity records in Blueprint, so we cannot recreate a full change history; we preserve the current state at time of migration.

Blueprint Project records contain metadata beyond the project name: description, team size, project owner, budget, and status. We create monday.com Board columns to hold this metadata as Text, Numbers, Date, or Status fields. Budget values stored as numeric fields in Blueprint migrate to monday.com Numbers columns with formatting preserved where possible. Project status maps to a monday.com Status column with values that approximate Blueprint's status model.

Blueprint Scope records contain AI-generated descriptions and acceptance criteria. monday.com Groups have a description field (Long Text) that we use for the Scope description. Acceptance criteria stored as structured sub-fields in Blueprint are mapped to a Text column on each Item within the Group so that criteria are visible on the individual task level.

Blueprint Tasks can have dependencies defined between them (e.g., Task B depends on Task A completing first). monday.com supports a Dependency column type that links Items to other Items. We map Blueprint task dependencies to monday.com dependency links, creating a parent-child relationship that drives Timeline and Gantt views in monday.com. Circular dependencies in Blueprint are flagged and resolved before migration to avoid invalid dependency chains in monday.com.