Migrate your ActiveCollab data

Projects are the top-level container in ActiveCollab and carry metadata like category, status, budget, and owner assignment. All tiers support unlimited projects, and we migrate project metadata, settings, and role-permission overrides intact via the Projects API endpoints.

Tasks support subtasks, due dates, assignees, labels, recurring scheduling, and automated dependency updates. We preserve task order within lists and pipeline stages. Moving a task disconnects it from the source project — we flag this decision point with the customer before migration.

Subtasks are hierarchically nested under Tasks and carry their own assignees and completion status. We preserve the parent-child relationship and render it faithfully in the destination system.

Discussions are threaded comment threads attached to Projects or Tasks. They carry author, timestamp, and content. We map Discussion threads to the equivalent conversation object in the target PM platform.

Notes are free-form text records that live at the Project level and can be pinned. We migrate Note content and Project association. Target systems that do not have a Project-level Note concept will have Notes mapped to a generic Text field on the Project.

ActiveCollab supports billable and non-billable time entries with Stopwatch capture, manual entry, and timesheet views. We map Time Entry records — including job type, billable flag, and linked task — to the destination's time tracking object. Personal and team timesheet rollups are reconstructed from entry-level records.

Expense records belong to Projects and include amount, category, date, and receipt attachment reference. We migrate expense entries and reconstruct the Expense Report rollup from line-item records in the destination system.

Invoicing is a Pro+ tier feature gated behind a paid upgrade. Where it is enabled, we migrate Invoice records, line items, tax codes, and payment status. Many destination PM platforms do not have a native invoicing object, so we map Invoice data to the closest equivalent (e.g., a billing custom object or a linked financial record). The Pro+ gating means not all ActiveCollab workspaces have this data.

ActiveCollab distinguishes between Members (paid seats) and Clients (free collaborators). We migrate both roles with their name, email, avatar, timezone, and active/archived status. We map role-based permissions to the destination's equivalent role model.

Labels are tag strings applied to Tasks and Projects for filtering. We preserve the full label vocabulary and reapply label assignments to migrated tasks. Some destination platforms require pre-creating labels before import; we handle this during the field-mapping phase.

Project Templates bundle a named set of Tasks, subtasks, and Discussions. We migrate the template structure as a new Project in the destination, with a naming convention indicating its template origin. The destination's template feature is used where available.

ActiveCollab supports finish-to-start task dependencies with automated downstream date updates. We preserve the dependency graph in migration, but destination platforms handle dependency logic differently — some have no native dependency model. We reconstruct dependencies as explicit predecessor links or custom fields where the target lacks native support.

Recurring tasks use a recurrence rule defined at creation time. We migrate the recurrence rule and the generated task instances as discrete tasks. Recurrence-rule editing in the destination is not always supported, so we flag this limitation during scoping.

Files are uploaded to ActiveCollab via a single /upload-files API endpoint and referenced by UUID elsewhere. We download attachments to our staging storage and re-upload them to the destination during migration, preserving filename, MIME type, and linked record. Storage quotas vary by tier (10GB Plus, 100–125GB Pro); we verify destination storage limits before migrating large file sets.

ActiveCollab automations are triggered-action rules (e.g., 'when task assigned, notify user X'). We capture automation configurations as structured records. The destination platform's automation engine rarely has a direct 1:1 rule mapping, so we document each automation as a migration requirement for manual rebuild or reimplementation.