Migrate from Allegra to monday Work Management

Allegra Items are the central record type and map directly to monday.com Items. We preserve item name, description (as Text column), creation date (as Date column), and last-modified timestamp. The item's unique identifier is used as the dedupe key during import. Items are created before any child objects to satisfy lookup dependencies. Sub-items in monday.com are used to represent child tasks if the Allegra instance uses a hierarchical item structure.

Allegra attributes (item-native custom properties) map to monday.com columns of the appropriate type: text attributes become Text columns, date attributes become Date columns, numeric attributes become Numbers columns, and boolean attributes become Checkbox columns. We query GET /v2/lists and the Allegra schema endpoint to discover every attribute definition before mapping. Attribute display names are preserved as column names with spaces and capitalization carried over.

Allegra form fields (which belong to input forms, not items) are a distinct schema object from attributes. We extract form field definitions separately from attribute definitions and map each to a corresponding monday.com column. Form field values stored on items are migrated as column values; if a form field value exists on an item but the field definition was not associated with that item's form, we log it as a non-critical orphaned value for customer review.

Allegra attachments live in the ALLEGRA_HOME filesystem, not in the database. We export the entire attachments directory alongside the database export, preserving directory structure. During monday.com import, each attachment is uploaded via the monday.com GraphQL API file upload mutation and the returned file URL is stored in a File column on the corresponding Item. We handle MIME type detection and file size validation against monday.com's storage limits per plan. A database-only export of Allegra will produce zero attachments in monday.com — we avoid this by running filesystem and database extraction concurrently.

Allegra custom lists (accessible via GET /v2/lists in the REST API) contain named list entries. We retrieve all list definitions and their entry values, then create monday.com Dropdown or Label columns with the list values as options. The Item-to-list-reference attribute on each Allegra Item maps to the monday.com Dropdown column value. If a list entry has no corresponding item value, it is still created as an available option in the monday.com column for future use.

Allegra users and roles are exported from the database. We match users by email address against monday.com User accounts. Any Allegra user without a matching monday.com User is held in a reconciliation queue for the customer's admin to provision before item migration proceeds, because Owner and Assignee columns in monday.com require a valid User reference.

Allegra can import Microsoft Project MPP files and Project Libre files with task recognition. We parse the MPP structure to extract task names, task hierarchy (parent-child), start and finish dates, dependencies (Finish-to-Start, Start-to-Start), resource assignments, and % complete. This data maps to monday.com boards: tasks become Items, sub-tasks become Sub-items, dates map to the Date column, dependencies map to the Dependency column (available on Pro and Enterprise plans), and resources map to the People column. MS Project task hierarchy does not have a direct monday.com equivalent, so the structure is flattened with Sub-items as the closest approximation.

Allegra notes attached to Items are extracted from the database as text entries with author and timestamp. We create monday.com Updates on the corresponding Item using the GraphQL mutation create_update, preserving the note body, author (resolved to a monday.com User by email), and creation timestamp. Rich text formatting in Allegra notes is preserved where possible; unsupported formatting is stripped.

Allegra projects and folders organize Items. We create a monday.com Board for each Allegra project, mapping the project name to the board name. Groups within the board correspond to Allegra folder or category groupings if present. The board's workspace is determined during scoping based on the customer's monday.com workspace structure.

Allegra item status values (if using a status attribute) map to monday.com Status column labels. We preserve the color mapping if Allegra stores status color metadata. If the Allegra instance uses a freeform text attribute for status rather than a named status field, we create a Dropdown column with the observed distinct values rather than a Status column.

Allegra date attributes map to the monday.com Date column. If the Allegra instance stores both a start and end date on the same item (creating a duration), we use the monday.com Timeline column (Pro and Enterprise) rather than two Date columns. The Pro plan minimum is noted during scoping because the Timeline column is not available on Standard.

Allegra tags applied to Items (stored as a multi-value attribute or custom list reference) map to the monday.com Labels column. We extract all distinct tag values from the Allegra attribute, create Label column options in monday.com, and apply the corresponding label values to each Item. Tags without a matching Item are preserved as available label options for future use.