Migrate from Rukovoditel to Jira

Every Rukovoditel Entity is a user-defined database table. There is no standard catalog — we introspect the actual Entity list during discovery and decide per-Entity whether it maps to a Jira Project (if it contains work items with status progression) or to a set of Jira Issue Types within an existing Project (if it represents a record type like a client or product). This decision drives the entire Jira schema design phase and must be agreed with the customer before any data extraction begins.

We parse the Entity's field list from the Rukovoditel database schema and map each to either a Jira native field (Summary, Description, Priority, Assignee, Reporter, Due Date, Labels) or a Jira Custom Field. Field type translation covers text to Jira Text Field, number to Number Field, date to Date Picker, entity reference to Jira Project/Issue Link, user to User Picker, and dropdown options to Jira Select List. Jira Custom Fields require Screen association before import — we add each to the relevant Issue Type Screen during the Jira configuration phase.

Rukovoditel Nested Entities implement one-to-many relationships via a foreign key in a separate table. We extract the parent-child relationship and reconstruct it in Jira as an Epic-Story-Subtask hierarchy. The parent Entity record becomes a Jira Epic (or Story depending on the hierarchy depth), and child records become linked Jira Stories or Subtasks under the Epic. Jira Epic Links are set via the Parent Link field on the child issue.

Rukovoditel Related Records store many-to-many associations in a junction table. Jira supports only a finite set of issue link types: Blocks, Blocked by, Relates to, Duplicates, Clone, and causes a Subtask. We map each Related Record relationship to the closest Jira-compatible link type and document the mapping. If Rukovoditel had a relationship type Jira cannot represent (e.g., a peer-equivalent relationship), we flag it for manual recreation as a Jira Label or Jira Component.

Rukovoditel Users map to Jira Users by email address. We extract the user list from the Rukovoditel Users table and match by email against the Jira destination instance. Users without a Jira match enter a reconciliation queue for the customer's admin to provision before record migration. Group memberships map to Jira Project Roles (Administrators, Developers, Users) tied to the destination project's permission scheme.

Rukovoditel User Groups map to Jira Groups and Project Roles. We extract all Group names and member lists, then create equivalent Jira Groups. Project Roles are assigned per Jira Project, with the migrated User Group members added to the relevant roles. Access control rules on Rukovoditel Entities become Jira permission schemes (Browse Projects, Edit Issues, Assign Issues) scoped per project.

Rukovoditel attachments are binary files on the server filesystem with references in the database. We export the files, map the record association by Rukovoditel Entity ID, and re-upload to Jira via the Jira REST API Attachment endpoint (multipart/form-data POST to /rest/api/3/issue/{issueIdOrKey}/attachments). Jira Cloud has a 10MB per-file attachment limit. Jira Data Center has a configurable limit. We flag any file exceeding the target limit for customer decision before migration.

Rukovoditel XML Export templates use a [field ID] notation to define which Entity fields appear in the export. We parse these templates to understand the customer's intended data structure when XML export is available, which supplements our direct database read as a secondary data source. If no templates are configured, we rely on direct MySQL reads with field ID discovery from information_schema. XML export templates do not migrate to Jira; they serve only as a mapping reference for the migration.

Rukovoditel's built-in CSV/XLSX export for any Entity provides a flat-file view of the Entity's records. We can consume these exports directly as source input, using the flat-file structure as the basis for Jira CSV import mapping. This is a fallback path when database access is unavailable or when the customer prefers to use Rukovoditel's built-in tools. The flat-file structure loses relationship context — nested and related records must be resolved separately via junction table reads.

Rukovoditel Entity-level workflows with branching, conditional rules, and automated actions have no equivalent in Jira's workflow model, where workflows are project-scoped and defined separately from issue data. We do not migrate workflows as code. We document every active Rukovoditel workflow with its Entity scope, trigger conditions, status transitions, and automated actions, mapping each to a recommended Jira Workflow equivalent. The customer's Jira admin rebuilds these in Jira's workflow editor post-migration.