Migrate from Exepron to Asana

Exepron Projects map directly to Asana Projects. We extract project metadata (name, description, start date, finish date, status, priority flags, and Project Risk Quotient score) via GET /projects. The PRQ score is a numeric value between 0-100 with no native Asana equivalent, so we create a custom number field prq_score__c on the Project. Project-level custom fields migrate to Asana project-level custom fields using the Asana Custom Fields API. Exepron's Project Templates are separate objects; the template structure migrates to Asana project templates if the destination is on Asana Business plan or above, or we document the task structure for manual template creation on lower tiers.

Exepron Activities map to Asana Tasks within a Project. We map Task Name, Duration, Start, Finish, Fixed-Duration flags, and Predecessor links. Predecessor relationships in Exepron (finish-to-start, start-to-start, finish-to-finish, start-to-finish) translate to Asana dependency links using the Asana dependencies API. Custom Activity Statuses and Kanban status groupings migrate as Asana task custom fields of type enum. The Critical Chain buffer concept (project buffer, feeding buffers, resource buffers) cannot be migrated as a scheduling artefact; we document the buffer assignments per project in a written reference sheet for the PM team to implement manually using task milestones or due-date offsets if needed.

Exepron Resources (people, equipment, facilities) map to Asana Users assigned to Tasks. We export Resource Name, Type, and Consumption units. The assignee resolution uses the Resource email address to match against Asana Users. If a Resource has no email (equipment or facility), we create an Asana custom field resource_type__c on the task to preserve the type information. Resource consumption data (hours allocated vs consumed) migrates to Asana custom number fields consumption_hrs__c and allocated_hrs__c on the task. Multiple Resources on a single Activity produce multiple task assignments in Asana with the same task duplicated per assignee.

Exepron Resource Types group Resources for Dynamic Drum scheduling. We export the type hierarchy as a written reference. In Asana, Teams are the nearest structural equivalent—they are used to scope project membership and assignee lists. We map each distinct Resource Type to an Asana Team, provisioning the team before any project migration so that Resources resolved to assignees can be grouped by team membership. This mapping is configuration-only; no data moves.

Exepron Activity Bundles group related Activities under a parent Work Package. Asana Sections within a project serve a similar grouping function—though Asana sections are flat within a project and do not support nested hierarchies. We map each Activity Bundle to an Asana Section, with the section name carrying the bundle name. Activities within the bundle become tasks under that section. If the bundle hierarchy is two or more levels deep, we flatten it to a single section level and note the original nesting in a custom field original_bundle_path__c on each task.

Exepron Custom Fields are per-account extension properties. We export field definitions (name, type, required flag, picklist options) and all populated values. Asana supports custom fields of type text, number, enum (single-select), multi-enum (multi-select), date, and person. We map Exepron text, number, and picklist fields to their Asana equivalents. Enum multi-select fields map to Asana multi-enum. Any Exepron field type with no direct Asana equivalent (for example, a calculated field or a field referencing a related object) is flagged during scoping and mapped to a text field with the calculated value serialized as a string. Custom field values are attached to the migrated tasks using the Asana Custom Fields API in a post-task-insert pass.

Exepron Project Templates contain reusable task networks and Resource assignments. We export the template block structure and task sequence. Template Blocks are exported as a flat task structure that the customer can use to populate a new Asana project template on Business plan or above. We do not auto-create Asana templates because Asana's template API does not support task-level block import; instead, we deliver a structured task tree document showing the source template hierarchy and recommended Asana section/section/task layout for manual template creation.

Exepron Alerts are threshold-based notifications tied to task slippage and Resource overloads. Reason Codes annotate why a slip occurred. Both are exported as metadata and attached to the affected task as an Asana task comment containing the alert text and reason code. If the customer requires a queryable record, we offer an optional Asana custom field alert_reason_code__c that captures the most recent reason code for the task. This is a mapping not a direct object transfer because Asana does not have an alerts object.

BIDSS is Exepron's runtime Business Intelligence Decision Support System. Its dashboards, charts, and heatmaps are generated from live project data at query time—there is no persistent BIDSS configuration object in the Exepron database. We explicitly exclude BIDSS from migration scope. Customers who rely on BIDSS insights receive a written inventory of every chart type, filter, and data source reference they should rebuild in a destination BI tool (Power BI, Tableau, or Asana's native reporting on Business plan) using the migrated project data as the source.

PALS (Project Advanced Learning System) generates learner progress data independently of live projects. It is not a persistent data object with a schema we can query—it is a simulation and knowledge-transfer environment. We do not migrate PALS records. Customers who use PALS for team onboarding or Critical Chain methodology training should treat the PALS data as a training asset to be recreated post-migration using the migrated project portfolio as the practical reference material.

Exepron Custom Roles govern permission scoping within the platform. Asana does not have a Custom Roles model—it uses Team membership and project-level permissions (full access, can view, can edit). We export role definitions and permission sets as a written reference document for the customer's admin to evaluate against Asana's permission model and implement using a combination of Teams, projects, and Asana Enterprise Grid admin controls if the destination is Enterprise. There is no data migration path for role definitions.

Exepron What-If scenarios are separate project clones with modified durations, Resource loads, or start dates tracked as deltas from the base project. Asana does not have a What-If scenario model. We export the base project and each scenario as a separate Asana project, with the scenario project named using a convention like [Base Project Name] - Scenario [N] and a custom field scenario_base_project__c pointing to the base project gid. The delta changes are documented as task modifications (adjusted durations and dates) for the PM team to evaluate manually rather than as a native scenario-delta tracking artefact.