Migrate from Rukovoditel to Asana

Each Rukovoditel Entity maps to an Asana Project. During schema introspection, we discover all Entities defined in the Database Designer, identify the primary display field (typically the Entity's name field), and create an Asana Project per Entity. Sections within the Asana Project can be used to represent Entity groupings if the customer uses Entity-level filtering or grouping in Rukovoditel.

Individual records within a Rukovoditel Entity map to Asana Tasks. The primary display field from the Entity becomes the Task name. Standard Rukovoditel fields (created_by, date_updated, etc.) map to Asana's built-in task properties (created_by, modified_at) where possible; custom fields preserve as Asana Custom Fields.

Rukovoditel Nested Entities implement one-to-many relationships as separate database tables with a foreign key back to the parent Entity. We extract the child table, resolve the parent reference, and insert each child record as an Asana Subtask nested under its parent Task. The subtask name comes from the child Entity's primary display field. Nested Entities more than one level deep require multi-pass flattening: each nesting level becomes an additional subtask depth.

Rukovoditel's Related Records field type stores M:N associations in a junction table. We extract both sides of the relationship during migration. If the relationship represents a category or classification (e.g., a Task belongs to multiple Teams or Categories), we create Asana Tags with TopicAssignment records. If the relationship is a reference entity (e.g., a Task is linked to multiple Clients), we create a multi-select Custom Field in Asana with the reference values as options. The customer chooses the strategy during scoping.

Rukovoditel User accounts map to Asana Workspace Members by email match. We extract the user table from Rukovoditel (via database read or API), match against the Asana workspace's user list, and assign the Asana User as the task assignee. User Groups in Rukovoditel can be mapped to Asana Teams if the customer wants group-level project access control. Any Rukovoditel user without a matching Asana account goes to a reconciliation queue for provisioning before the migration phase begins.

Rukovoditel User Groups are separate objects used for Entity-level access control. We extract all User Groups and, at the customer's direction, create corresponding Asana Teams. Group membership is preserved as Team membership in Asana. If the customer has many small User Groups (fewer than 3 members), we recommend merging them into fewer Asana Teams to align with Asana's team-based permission model.

Rukovoditel field types (text, number, date, entity reference, related records, users, user groups, MySQL query) map to Asana Custom Field types as follows: text and number to Text and Number Custom Fields; date to Date Custom Fields; entity reference to a Lookup Custom Field or Subtask if the reference is a single record; related records to Tags or multi-select Custom Fields; user references to Assignee or team member fields. Rukovoditel field IDs are numeric and installation-specific — we preserve the field label as the Asana Custom Field name during mapping.

Rukovoditel entity reference fields (fields that point to another Entity record) require lookup resolution during migration. We build a lookup table of source Entity record GIDs to destination Asana Task GIDs before inserting referencing records. This ensures that when a field references another Entity, the correct Asana Task is linked. Circular references (Entity A points to B, B points to A) are detected during schema introspection and resolved iteratively.

Rukovoditel file attachments are stored on the server filesystem with a reference in the database. We export the binary files, preserve their original filename and upload date, and re-upload them to Asana as task attachments via the Asana Attachments API (multipart form upload). Files exceeding Asana's 100 MB limit are flagged for the customer to host externally and link via URL attachment. The record association is preserved by linking each attachment to the correct parent Task GID resolved during the mapping phase.

Rukovoditel's XML Export templates are user-defined configuration artifacts that control which fields appear in XML exports. These have no functional equivalent in Asana and are not migrated. We document the template structure as part of the schema introspection output so the customer's admin understands which Rukovoditel fields were included in exports and can configure equivalent Asana Custom Fields or section groupings post-migration.

Rukovoditel's Export Selected feature produces CSV files per Entity that can be consumed as import sources for Asana. We use the CSV as a primary data extraction path when XML templates are unavailable, parsing the flat record structure and transforming it into Asana task create payloads. The CSV must be enriched with Asana Custom Field GIDs (resolved during schema mapping) before import.

Rukovoditel's Entity and Field-level access control rules (which User Groups can view or edit which Entities and Fields) have no direct Asana equivalent. Asana uses workspace membership and project-level team access for permissions. We document the existing access rule structure as a written inventory for the customer's admin to redesign in Asana's permission model post-migration.