Migrate from 24SevenOffice to Asana

24SevenOffice Projects map directly to Asana Projects. We migrate project name, description, status (active/archived), start and due dates, owner, budget, and milestones. Asana's project privacy settings (public/private) default to the source project's visibility flag. Projects are extracted first so that their GIDs are available as parent references for Task imports. 24SevenOffice's PMI-standard alignment does not require special mapping to Asana's simpler project model.

24SevenOffice Tasks and Subtasks migrate to Asana Tasks and Subtasks with parent-child hierarchy preserved through the subtasks relationship. We map title, description, status, assignee (via owner lookup), due date, estimated hours, and custom task fields. 24SevenOffice task hierarchy depth migrates as nested subtasks; if hierarchy depth exceeds Asana's subtask nesting model, we flatten to a maximum of three levels and flag the remainder for the customer to restructure. Custom fields on tasks are mapped individually against Asana's supported types (text, number, dropdown).

24SevenOffice Time Entries (with project, user, date, duration, billable flag, and description) do not have a native Asana equivalent. We split each Time Entry into: (a) a custom number field on the linked Task capturing hours (duration converted to hours), and (b) a text custom field storing the date and description. Billable flag is stored as a custom dropdown field with values Billable / Non-Billable / No Charge. For customers with billing workflows tied to time entries, we recommend a separate time-tracking integration (Harvest, Toggl) post-migration rather than recreating a full time-entry data model in Asana.

24SevenOffice User accounts (name, email, role, module permissions) map to Asana Workspace Members. We resolve users by email match and set Asana workspace membership and default workspace. If a 24SevenOffice user has been deactivated, we import them as an Asana Member with the inactive flag set. Role names differ significantly between the two platforms, so we flag the role mapping for the customer's admin to assign appropriate Asana permissions (Member, Admin, Guest) post-import.

24SevenOffice CRM Contacts have no Asana equivalent. Asana does not have a native Contact or Account object. We flag Contacts as out-of-scope for this migration and deliver a written data extract (CSV) of all Contact records including name, email, phone, address, lifecycle stage, and owner for the customer's admin to import into a dedicated CRM or address management tool. We do not convert Contacts to Asana Tasks as a workaround because that breaks the data model.

24SevenOffice Company/Organization records have no Asana equivalent. Asana is not a CRM. We deliver a written data extract of all Company records for import into a dedicated CRM platform. If the customer uses Asana's portfolio or workspace structure to represent organizational groupings, we document a tagging convention using Asana Topics as a lightweight alternative during scoping.

24SevenOffice Deals and Pipelines have no Asana equivalent. Asana does not have an Opportunity, Pipeline, or Deal object. We deliver a written data extract of all Deals including deal name, value, stage, owner, and associated Company for the customer's admin to migrate to a dedicated CRM. Asana Sections can be used to represent deal stages as a lightweight workaround, but this is documented as an optional configuration rather than a direct object mapping.

24SevenOffice Invoices (with line items, tax codes, payment status, and country-specific schema) cannot migrate to Asana. Asana has no invoice object. The country-specific tax code mapping (Norwegian, Swedish, UK editions) is preserved in a written extract for the customer's finance team to re-enter in a dedicated accounting tool. We flag which records are affected by the country edition during discovery so that the finance team can plan re-entry accordingly.

File attachments on 24SevenOffice Projects and Tasks are referenced by URL in the API. We download each attachment to temporary storage, validate file size (Asana API does not support attachments larger than 100 MB; these are flagged and skipped with a written record for the customer's admin), then upload to Asana's file service linked to the target Project or Task. Original filename and created-by metadata are preserved. Attachments on Invoices and Deals are included in the out-of-scope data extract.

24SevenOffice Tags (flat key-value labels on Contacts, Companies, and Deals) migrate to Asana Tags, which are workspace-level and can be applied to any task. We extract all tags from in-scope objects, map them to Asana's tag schema, and apply them during import. Tags from out-of-scope CRM objects (Contacts, Companies) are delivered in the written data extract.

24SevenOffice custom fields on Projects and Tasks require explicit type mapping to Asana's supported custom field types: text (Asana text), number (Asana number with decimal places), dropdown (Asana enum with up to 50 options), and date (Asana date). Asana's 20-field per-project ceiling is checked during discovery; if the source schema exceeds 20 custom fields on any project, we prioritize the most-used fields and document the remainder for manual recreation. Custom fields on out-of-scope objects (CRM, accounting) are not migrated.

24SevenOffice notification rules and automation triggers do not migrate to Asana Rules. We do not migrate automations as code. We deliver a written inventory of every active 24SevenOffice automation including its trigger, conditions, and actions, with a recommended Asana Rules equivalent for the customer's admin to rebuild. Asana Rules use record-triggered and scheduled variants that differ structurally from 24SevenOffice's property-change triggers.