Migrate from Meegle to Asana

Meegle Workflows (the top-level container defining the visual map structure, nodes, and metadata) map to Asana Projects. Each Meegle Workflow becomes an Asana Project with the Workflow name as Project name and Workflow description preserved in the Project brief. The destination Project is created first so that child Nodes and Tasks can be associated during import. If multiple Meegle Spaces exist, each Space's Workflows map to a set of Asana Projects organized by Team.

Meegle Nodes of type Task map to Asana Tasks within the corresponding Project. Standard Node fields (title, description, assignee, due date, status) migrate directly to Asana Task fields. Node type metadata (milestone, group, or feature) is preserved as a custom field node_type__c on the Asana Task so that the admin can group or filter by original node type after migration.

Meegle milestone nodes map to Asana Tasks with the Start Date and Due Date collapsed into a milestone marker. Asana does not have a native milestone object; milestones are represented as tasks with a milestone checkbox or converted to a milestone field via the Asana API. We set the Asana Task's start_on and due_on to match the Meegle milestone's scheduled dates and flag the task for milestone display in Timeline view.

Meegle Group nodes act as organizational containers within a Workflow and map to Asana Sections within the corresponding Project. Child Nodes under a Meegle Group become Tasks placed inside the Asana Section. If a Meegle Group contains nested Groups, we flatten the hierarchy into top-level Asana Sections and preserve the full group path as a custom field group_path__c for reconstruction if the admin chooses to use subtasks instead.

Meegle's advanced dependencies (finish-to-start, start-to-start, finish-to-finish, start-to-finish) are converted to Asana's predecessor-successor format. Meegle finish-to-start maps directly to Asana predecessor (FS). Start-to-start maps to SS. Finish-to-finish maps to FF. Start-to-finish maps to SF. We reconstruct the full dependency chain as a series of Asana dependencies with the correct predecessor task GID and dependency type. Circular dependencies detected during scoping are flagged and resolved by the customer before migration runs.

Meegle nested node relationships within a parent task map to Asana Subtasks. The nesting depth is preserved; if the destination Project has subtask depth limits, we flag any structures that exceed them. Subtask title, description, assignee, due date, and status migrate directly. Meegle's subtask is a relationship property rather than a distinct object, so we reconstruct it as an explicit Asana Subtask linked to the parent Task.

Meegle custom fields per Workflow or Space map to Asana custom fields. We perform type matching: Meegle text fields map to Asana text, number to number, date to date, formula to formula (Asana Enterprise+), and multi-select to multi-select picklist. Asana custom fields require pre-creation in the destination org before task import. We create local custom fields per Project unless the customer specifies a global field library approach. Dropdown option values from Meegle multi-select fields are mapped to Asana picklist options with exact label matching.

Meegle attachments stored in Meegle's file system (up to 20T on Premium/Enterprise) are extracted by file reference during export. We re-link attachments to the corresponding Asana Task as a URL attachment pointing to the source file location. If the customer has migrated attachments to a shared storage solution (Google Drive, SharePoint, S3), we update the reference URL accordingly. Attachment size and volume are estimated during scoping; Asana's attachment limits per task and project are respected during import.

Meegle Members map to Asana Users by email address match. We extract every distinct Member referenced on Nodes, Tasks, and Workflow-level assignments and match against the Asana destination Workspace's User table. Any Meegle Member without a matching Asana User is held in a reconciliation queue for the customer's admin to provision before record import resumes. Inactive or archived Meegle members are flagged separately for the admin to decide on User status in Asana.

Meegle's Role-based cross-space authorization governs which users can see and edit which nodes. This maps to Asana's Team structure and Project-level Member/Guest/Viewer permissions. We extract the Role assignments per node and Workflow and translate them to Asana Team membership and Project access levels. Complex conditional permissions (field-level visibility, node-specific access) that cannot be expressed in Asana's permission model are documented in a written permission matrix for the admin to configure manually post-migration.

Meegle's multi-view configurations (which fields are shown, sort order, grouping rules) are exported as view metadata. Each Meegle view type maps to an Asana Project View: Table to List, Kanban to Board, Gantt to Timeline or Gantt. Panorama and Tree views, which are unique to Meegle Premium, do not have direct Asana equivalents; we document the field visibility and grouping configuration from these views as a guide for the admin to configure manually in Asana's customization panel.

Meegle Workflow Templates (defining node structure and default fields) do not migrate as live templates in Asana. We extract the template structure and create an Asana Project that mirrors the template as a one-time import. The customer uses this Project as a manual template for future projects. Asana's native Templates feature can import this structure as a reusable template if the customer wishes to use it going forward.

Meegle automations triggered by task status changes or field updates migrate as written configuration, not executable code. We deliver a document cataloging every active Meegle Automation with its trigger condition, field criteria, and action set, mapped to the closest Asana Rule equivalent (e.g., When Status changes to X, assign to Y). The customer's admin rebuilds these in Asana's Rules engine post-migration. Meegle's conditional logic with multi-branch paths cannot always be expressed in Asana's linear Rule model; the inventory document flags these cases with a complexity note.

Meegle's change management module (change requests, approvals, implementation status) is a first-class object in Meegle Standard and above. We map these to Asana Tasks with a custom field change_management__c set to true and additional fields for approval_status, change_type, and priority. Approval workflows are documented as a list for the admin to configure in Asana's approval flow or a third-party integration. Change log entries migrate as comments on the corresponding Asana Task.

Meegle's Member Schedule (tracking team member availability and allocation) maps to the Asana Assignee field on Tasks with Timeline/Gantt view used for visual allocation planning. We export member availability windows and map them to task assignment dates in Asana. Workload management features in Asana Business and Enterprise tiers provide allocation visibility post-migration.