Migrate from web2Project to Trello

web2Project Projects map to Trello Boards. Each project's name, description, color tag (if set), owner, start_date, and end_date transfer as Board metadata and description. Projects assigned to a web2Project Company map to a Board background color or a custom field on the first list. We create one Board per web2Project project; multi-department projects are not split because Trello has no native department grouping above board level without Workspace-level organization.

web2Project Tasks map to Trello Cards on the appropriate Board. Task name becomes card title; task description (txt_description) migrates as card description. web2Project task priority (1-5) maps to a Trello label (Critical, High, Medium, Low) on the destination board. Start and due dates from web2Project become Card due dates. web2Project task_status (completed, active, on-hold) maps to a Trello list: we map Completed to Done or Archive, Active to a configured workflow list, and On-hold to a Hold list defined during scoping.

web2Project parent-child task relationships migrate as either Trello Checklist items on the parent Card (preferred for simple hierarchies under 50 subtasks) or as Power-Up child Cards linked via Card Relations Power-Up (preferred for complex hierarchies where subtasks need assignees and due dates independently). The customer chooses the subtask strategy during scoping based on the destination Power-Up availability.

web2Project Finish-to-Start, Start-to-Start, and Finish-to-Finish task dependencies have no native Trello equivalent. We map them to the Card Relations Power-Up (if licensed on the destination) or document them as Butler automation rules that set card blocking and unblocking. The dependency graph is extracted from web2Project's task_dependencies table and reconstructed as a list of (predecessor_id, successor_id, type) tuples migrated as blocking labels or card relations.

web2Project Users map to Trello Workspace Members. We match by email address as the dedupe key. web2Project user active/inactive status maps to Trello member deactivated status. web2Project role assignments (project_manager, developer, viewer) map to Trello board roles (Admin, Member, Normal, Observer) defined per-board during migration.

web2Project Companies are organizational entities separate from departments. Since Trello has no native company object, we map web2Project Company name to a Board background color (if fewer than 10 companies) or to a Company custom field on Cards across the relevant boards. The customer selects the strategy during scoping.

web2Project Departments map to Trello Labels on boards where department members are active. Department name becomes label name, and department color maps to label color. If the web2Project instance has more than 10 departments, excess departments are mapped to card custom fields to stay within Trello's label limit.

web2Project v2.4+ custom fields (text, number, date, dropdown, checkbox) map directly to Trello Custom Fields using the Power-Up. Custom field type mapping: web2Project checkbox becomes Trello checkbox custom field; date becomes Trello date custom field; dropdown becomes Trello dropdown custom field with options preserved. If the destination is Trello Free, Custom Fields Power-Up is available; Standard and Premium include custom fields natively.

web2Project pre-v2.4 custom fields use a different schema — the field store and retrieval methods, optionlist table structure, and type metadata differ from the v2.4 OOP model. We detect the source version during database inspection and apply a pre-v2.4 field extractor that queries the legacy cf_" table format and re-serializes values into the v2.4 format before mapping to Trello Custom Fields.

web2Project calendar events migrate as Trello Cards with the event start datetime as the card due date and the event title as card name. The event description migrates as card description. Calendar event recurrence patterns are not migratable to native Trello recurrence and are documented in the written inventory for Butler rule rebuild.

web2Project forums attached to projects are represented in Trello as card comments on the relevant board. Forum categories become comment threads on the first card of the relevant project board. Thread title and post order are preserved; individual post content migrates as sequential comments. Full-text search across forum content is not available in Trello without a search Power-Up.

web2Project file attachments at the project and task level are migrated as Trello Card attachments. We extract the file URL or file_id from web2Project's file module and generate a Trello attachment reference. Actual file transfer (moving binary files from the web2Project-hosted file directory to Trello's Atlassian-hosted attachment storage) requires a separate file transfer step coordinated alongside the migration; we include this in the statement of work and price it based on total file size and count.

web2Project budget fields are explicitly documentation-only and not used in any calculation or reporting. We migrate budget values as Trello Custom Fields (number type) with a naming convention that includes Budget in the field label, making it clear to the team that the values are informational. Any actual budget tracking, alerts, or calculation must be re-implemented in Trello via a Power-Up (e.g., Function Point or Plutio) post-migration.

web2Project Gantt chart visualization is driven by task start_date, end_date, duration, and dependencies. We migrate the underlying data fields — task start, end, duration, percent_complete, and predecessor links — as Trello Card due dates, checklist completion percentages, and Card Relations (for predecessors). The Gantt chart render itself does not migrate; teams requiring a Gantt view use the Trello Timeline Power-Up or Cards for Jira.

web2Project user activity logs (rebuilt to be timezone-aware in v2.4) are extracted and exported as a structured CSV audit report. Trello has no native activity log history beyond its built-in card Activity tab. We preserve the full activity log in a written inventory document delivered alongside the migration, including timestamps, user, action type, and affected record ID. Pre-v2.4 logs are normalized from server local time to UTC before export.