Project Management migration
Field-level mapping, validation, and rollback between Comidor and Jira. We move data and schema; workflows are rebuilt natively in Jira.
Comidor
Source
Jira
Destination
Compatibility
6 of 13
objects map 1:1 between Comidor and Jira.
Complexity
BStandard
Timeline
2-3 weeks
Overview
Moving from Comidor to Jira is a migration with a constrained export path. Comidor provides no documented REST API, no developer portal, and no published rate limits, which forces us to rely on CSV exports from the Comidor UI and manually extracted workflow definitions. Jira receives data through its REST API and bulk import endpoints, which we use for issue creation and file attachments. Comidor Issues map to Jira Issues with a configurable workflow scheme that we design based on the source status matrix. Custom User Fields, which are globally scoped in Comidor, must be extracted as field definitions before record data so that orphaned references are avoided. Knowledge Base articles, which have no Jira Software Cloud equivalent, are flagged for Confluence placement if the customer holds that license, or for project-level documentation rebuild otherwise. BPMN 2.0 workflows, App Designer applications, Process Scheduling, and Leia chatbot configurations do not migrate as executable code; we deliver a written inventory of these configurations for your admin to rebuild in Jira.
Every standard and custom field arrives verified.
AI proposes the map; you confirm before any record moves.
Parent–child, lookups, and ownership stay linked.
Calls, emails, meetings — with original timestamps.
Documents, uploads, and inline notes move with the record.
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a Comidor object lands in Jira, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
Comidor
Issue
Jira
Issue
1:1Comidor Issues map directly to Jira Issues (Epics, Stories, Tasks, Subtasks, or Bugs depending on the mapping rule we agree on during scoping). Each Comidor status value maps to a Jira status via a status-mapping table that accounts for status name collisions across different Comidor workflow configurations. The Jira workflow scheme and issue type screen scheme are configured in the destination org before any issue records are created so that incoming records land in the correct state on the correct screen.
Comidor
Files and Documents
Jira
Attachments
1:1Comidor file attachments (binary files and associated metadata) are extracted as separate files with a reference to their parent Issue. During Jira import, each file is uploaded via the Jira REST API and attached to the resolved parent Issue. Jira enforces a 32 MB per-file attachment limit for Cloud instances; we flag any Comidor file exceeding this threshold for the customer's admin to review before migration.
Comidor
Contact
Jira
User (as Reporter or Assignee on Issue)
1:1Comidor Contact records (standard fields plus any attached Custom User Fields) map to Jira User accounts resolved by email address match. Comidor Contact is a person record; in Jira, the person record is a User, and the Issue holds the person as Reporter, Assignee, or a custom User-type field. We resolve the User reference at migration time and flag any Comidor Contact whose email has no matching Jira User.
Comidor
Account
Jira
Component or Project
lossyComidor Account records (organizational entities) map to Jira Components within a Project, or to separate Jira Projects if the Comidor Accounts represent distinct organizational boundaries. The customer chooses the strategy during scoping. Comidor's many-to-many Contact-to-Account relationship is preserved as the Component-to-User membership or as a multi-select custom field depending on the chosen strategy.
Comidor
Custom User Field
Jira
Custom Field
lossyComidor globally scoped Custom User Fields must be extracted as field definitions before any record data. We map Comidor field data types (text, number, date, select, multi-select) to equivalent Jira custom field types (Text Field, Number Field, Date Picker, Single Select, Multi Select). Global Comidor fields that are referenced in multiple Issues are pre-created as Jira project-level custom fields before the first issue record is imported. Any Comidor field whose type cannot be represented in Jira (for example, a complex conditional lookup) is flagged for manual remediation.
Comidor
Knowledge Base
Jira
Confluence Page or Project documentation
lossyComidor Knowledge Base articles have no native equivalent in Jira Software Cloud. We export articles as structured text records with category assignments. If the customer holds a Confluence license, we deliver a migration package (CSV with article content and hierarchy) that maps to Confluence Pages in a designated Space. If Confluence is not available, articles are flagged as requiring rebuild as project-level documentation inside Jira or as an external Confluence instance.
Comidor
App
Jira
Project configuration
lossyComidor Apps created in App Designer are custom-built no-code or low-code applications. We export app configurations as structured definition packages. These packages cannot be imported into Jira as functional applications because Comidor App Designer has no Jira equivalent. We deliver the exported definition as a written configuration inventory so the customer's admin understands what each app did and can rebuild equivalent functionality using Jira's project configuration, issue types, and screens.
Comidor
Workflow
Jira
Workflow
lossyComidor BPMN 2.0 workflow definitions are extracted as portable configuration packages. These define process sequences, conditions, and automated task assignments in BPMN format, which Jira does not natively consume. We deliver the full workflow definition as a written inventory document that includes the BPMN diagram reference, each task's assignee rule, conditional branching logic, and a recommendation for the equivalent Jira Workflow to be built by the customer's admin. Jira Workflows use a different model (status transitions with conditions, validators, and post-functions) and must be rebuilt.
Comidor
User Form
Jira
Issue type Screen
lossyComidor User Forms are data-entry interfaces that embed Custom User Fields. We export form definitions as structured schemas listing each field, its type, and its show/hide conditional logic. Jira issue type screens perform a similar role, associating a screen (field layout) with each issue type within a project. We map the form field order to the Jira screen field layout, flagging any conditional logic that requires a Jira behaviour or an add-on to replicate.
Comidor
Discussion Board
Jira
Issue Comment
1:1Comidor discussion board posts map to Jira Issue Comments on the parent Issue. Thread structure is flattened because Jira comments do not support nested reply chains. We preserve the author, timestamp, and full comment body. Any @mentions in Comidor are mapped to Jira account mentions if the target user exists in Jira; unresolved mentions are flagged for the customer's admin to re-tag post-migration.
Comidor
User
Jira
User
1:1Comidor User accounts (defining permissions, roles, and organizational placement) map to Jira User records resolved by email address. We extract all distinct Comidor Users and cross-reference them against the destination Jira site's user list. Any Comidor User without a corresponding Jira account is placed in a provisioning queue for the customer's admin to create before record migration begins.
Comidor
Team
Jira
Group or Project Role
lossyComidor Teams are groups of Users used in workflow assignments and process routing. We map Teams to Jira Groups or Project Roles depending on whether the team's function is project-level or cross-project. Jira Groups grant permissions and are used in notification schemes; Project Roles scope access within a single project. The mapping choice is made during scoping based on how Comidor Teams are used in workflow definitions.
Comidor
Process Scheduling
Jira
None
1:1Process Scheduling in Comidor defines automated recurring execution of Workflows or Issue creation. This is an execution configuration rather than a data record. We do not migrate Process Scheduling as there is no equivalent in Jira Software Cloud. The recurring Issue-creation patterns are documented in the Workflow inventory as a note for the admin: Jira's automation rules or a third-party scheduling app must be evaluated as the replacement mechanism for recurring issue generation.
| Comidor | Jira | Compatibility | |
|---|---|---|---|
| Issue | Issue1:1 | Fully supported | |
| Files and Documents | Attachments1:1 | Mapping required | |
| Contact | User (as Reporter or Assignee on Issue)1:1 | Fully supported | |
| Account | Component or Projectlossy | Fully supported | |
| Custom User Field | Custom Fieldlossy | Fully supported | |
| Knowledge Base | Confluence Page or Project documentationlossy | Mapping required | |
| App | Project configurationlossy | Fully supported | |
| Workflow | Workflowlossy | Fully supported | |
| User Form | Issue type Screenlossy | Fully supported | |
| Discussion Board | Issue Comment1:1 | Fully supported | |
| User | User1:1 | Fully supported | |
| Team | Group or Project Rolelossy | Fully supported | |
| Process Scheduling | None1:1 | Not supported |
Gotchas + challenges
Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.
Comidor gotchas
No public REST API or documented export endpoints
Per-user tiered licensing gates module access
Custom User Fields are globally scoped and cross-referenced
Knowledge Base content tied to Leia chatbot must be manually reconnected
Jira gotchas
Unsupported workflow validators silently skipped during migration
Custom fields converted to flat text labels when migrating to non-Jira platforms
Historical status-change timestamps lost when exporting without a Marketplace plugin
Attachment import failures from oversized files and JQL reference corruption
Points-based API rate limits enforced on Jira Cloud apps from March 2026
Pair-specific challenges
Migration approach
Manual data extraction from Comidor
Because Comidor has no public API, we begin with a structured manual extraction session guided by a FlitStack AI extraction checklist. We export Issues, Contacts, Accounts, Files, Custom User Field definitions, Knowledge Base articles, and User account lists as CSV or structured data directly from the Comidor UI. Workflow definitions (BPMN 2.0 XML) and App Designer package exports are extracted separately as configuration packages. We flag any data that cannot be extracted from the UI at this stage so that the scope is complete before schema design begins.
Comidor instance audit and Jira project design
We audit the extracted Comidor data to determine Issue volume, file sizes, Custom User Field count, Knowledge Base article count, and active workflow count. We then design the Jira destination: Projects (one per Comidor workspace or one per Comidor App), Issue type hierarchy (Epic/Story/Task/Subtask based on the Comidor Issue type and parent-child relationships), workflow scheme with status mappings derived from the Comidor workflow configurations, and custom field creation for each Comidor Custom User Field with type conversion. The Jira schema design is delivered as a written document for the customer to review and approve.
User provisioning and Owner reconciliation
We extract every distinct Comidor User referenced as an Issue assignee, form owner, or workflow participant and match them by email against the destination Jira site's user list. Comidor Users without a corresponding Jira account are placed in a provisioning queue. Jira Groups and Project Roles are created to match Comidor Teams based on the mapping decided in scoping. Owner reconciliation must be complete before Issue records can be imported because Jira requires a valid Assignee and Reporter reference on every Issue.
Test migration into Jira Sandbox
We run a full test migration into a Jira Sandbox (a separate Jira Cloud site or a Jira Data Center staging environment) using a representative sample of Comidor data. The customer's project manager or admin reviews the migrated Issues, verifies that status mappings are correct, spot-checks custom field values, confirms file attachments are present, and validates Knowledge Base article formatting if Confluence placement is planned. Any mapping corrections, custom field type adjustments, or status translation errors are resolved in this phase before production migration begins.
Production migration in dependency order
We run production migration in record-dependency order: Jira Users and Groups (validated from step 3), Custom User Fields (created before Issues so field IDs are available), Issues with Assignee and Reporter resolved, Files attached to their parent Issues via the Jira bulk attachment endpoint, Knowledge Base articles packaged for Confluence placement or flagged for manual rebuild, and App/Workflow configuration inventories delivered as written documents. Jira's Bulk API 2.0 is used for large Issue batches with exponential backoff on rate-limit responses.
Cutover, validation, and configuration handoff
We freeze Comidor writes during the cutover window, run a final delta migration of any records modified during the migration period, then designate Jira as the system of record. We deliver the Workflow inventory document (BPMN reference, task assignments, conditional logic, recommended Jira equivalent) and the App configuration package to the customer's admin team for rebuild. We do not rebuild Comidor workflows as Jira workflows or Comidor apps as Jira configurations inside the migration scope; that work requires a separate Jira admin engagement. FlitStack AI supports a three-day post-cutover validation window where we resolve import errors and file attachment failures raised during the first business days of Jira-only operation.
Platform deep dives
Comidor
Source
Strengths
Weaknesses
Jira
Destination
Strengths
Weaknesses
Complexity grading
Standard Project Management migration. 3 of 8 objects need a mapping; the rest are 1:1.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across Comidor and Jira.
Object compatibility
3 of 8 objects need a mapping; the rest are 1:1.
Field mapping clarity
Field mapping is derived from defaults — final spec confirmed during the sample migration.
Timeline complexity
8-object category — typical timelines run 2–7 days end-to-end.
API constraints
Comidor: Not publicly documented.
Data volume sensitivity
Comidor doesn't expose a bulk API — REST + parallelization used for high-volume runs.
Estimator
Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.
Step 1
Pick a category, then your source and destination platforms.
Category
FAQ
Answers to the questions buyers ask most during Comidor to Jira migration scoping. Not seeing yours? Book a call.
Walk through your Comidor to Jira migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave Comidor
Other ways to arrive at Jira
Same-Project Management migrations
Ready when you are
Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.