awork import
Purpose
Anyone coming from awork should bring their history along — not retype it. This module takes the data over once and is built so that an interrupted run can simply be repeated. In a migration that is the normal case, not the exception.
Scope
- Six areas, individually selectable: match users, clients (awork „companies"), projects, tasks
including subtasks, checklists, dependencies and comments, time entries and file attachments.
- Dry run is the default. Writing happens only when explicitly requested.
- Repeatable without duplicates: every imported record remembers its awork id; a second run
updates instead of creating.
- Target brand selectable — mandatory when several brands exist.
- Report at the end listing what was skipped and why.
Interplay
Imported data lands where it belongs: clients in customer management, projects and tasks in projects and work items, times in time tracking, attachments in the document store. Comments become entries in the shared conversation.
Limits
- Users are never created. awork users are matched to existing employees by e-mail address;
without a match the record is skipped and noted in the report. An import must not invent personal accounts — whoever is meant to work in the target system is created there deliberately.
- Order is part of the matter: master data before transactional data. Tasks need their project,
projects their assignment. Each area additionally checks its own preconditions and reports a problem otherwise.
- The import is a setup tool, not an ongoing synchronisation: it fetches a stock of data, it does
not keep two systems aligned.