Migrate from Stackby to Trello

Stackby's Organization (top-level hierarchy above Workspaces and Stacks) maps to a Trello Workspace. We extract the organization name and description and create a corresponding Trello Workspace during migration. If the customer has multiple Stackby Organizations, we map each to a separate Trello Workspace and coordinate with the customer on naming alignment. Workspace-level member assignments migrate as Trello Workspace members with their original role permissions preserved as close to Trello's Admin, Member, and Observer roles as the source permissions allow.

Each Stackby Stack maps to a Trello Board. Stack names and descriptions migrate as Board name and description. Stack-level permissions map to Board visibility settings (Private, Workspace, or Public). We preserve the Stack's creation date and last-modified date as Board metadata where Trello's API supports it. If a customer has more than 10 Stacks, we discuss grouping them by project or department to avoid an unmanageable number of Trello Boards.

Stackby Tables map to Trello Lists. Each Table within a Stack becomes one or more Lists within the corresponding Board. If a Stackby Table has a Kanban column (a Select or Multi-select column configured as the Kanban grouping field), we map that column's distinct values directly to List names — preserving the existing Kanban view structure. For non-Kanban Tables (Grid, Calendar, Gallery), we create a single List named after the Table and store all Rows as Cards within it, with the original column data embedded as card fields. Tables with more than 100 rows per List may be split into multiple Lists by a chronological or alphabetical grouping key to stay within Trello's practical card-per-List limit.

Stackby Rows migrate to Trello Cards. The Row name or primary text field becomes the Card title. All other column values (text, number, date, select, multi-select, checkbox) become Card fields. Stackby's attachment column values map to Card attachments. Card description is populated from the most text-heavy column in the source Table, or left blank if no equivalent exists. Card due dates migrate from Stackby Date columns. Checklist items migrate from Stackby Checkbox columns with each checkbox becoming a Checklist item in Trello. We migrate row creation and modification timestamps as Card metadata where supported.

Stackby Text columns map to Trello Card description or a Custom Field (Text type) via the Custom Fields Power-Up. Stackby Number columns map to Trello Custom Field (Number type). The original column name is preserved as the field label. We recommend using the Custom Fields Power-Up for structured data (currency amounts, IDs, reference numbers) and Card description for long-form text because Trello's native card view shows Custom Fields inline without requiring a Power-Up install. Number fields migrate with full numeric precision; we do not round or truncate unless the customer specifies.

Stackby Select columns map to Trello Labels (colored labels with text names). Multi-select columns map to multiple Trello Labels applied to the same Card — each distinct selected value becomes a separate Label. Alternatively, for fields requiring structured data retention (rather than visual categorization), we map to Custom Fields (Dropdown type) which preserves the exact selected value as a typed field. We align with the customer during scoping on whether Select columns should use Labels or Dropdown Custom Fields, as this affects how Trello filtering and board automation will work post-migration.

Stackby Date columns map to Trello Card due dates if there is exactly one Date column per Table and the customer confirms it represents a task deadline. Additional Date columns map to Custom Fields (Date type) via the Custom Fields Power-Up. Trello supports only one native due date per Card, so any Table with more than one Date column requires Custom Fields for the overflow. Time component from Stackby Date/Time columns migrates as a Text Custom Field appended to the Date Custom Field because Trello's native date Custom Field does not support time.

Stackby file attachments migrate as Card attachments in Trello. We download files from Stackby's attachment storage via the Stackby API and upload them to the corresponding Card. Attachment names and file types are preserved. The 5 req/s Stackby API rate limit applies to attachment downloads as well as row data, which can extend the attachment migration phase significantly for libraries with hundreds of files. We audit total attachment volume during discovery and scope the timeline accordingly. Trello's per-file size limit (10MB on Free, 250MB on Standard and Business Class) may require splitting large files; we flag any attachment exceeding this limit before migration begins.

Stackby Checkbox columns map to Trello Checklist items. Each distinct Checkbox column becomes a Checklist on the Card. The checklist name comes from the column header. If the checkbox was checked at migration time, the checklist item is marked complete. We preserve the checked/unchecked state as it existed at the moment of migration; subsequent changes in Stackby do not transfer unless a delta migration is run during cutover.

Formula columns in Stackby compute values dynamically based on other column data. We capture the computed value at migration time and write it as a static Custom Field in Trello. The formula logic itself cannot migrate — Trello has no formula engine. We flag every Formula column during discovery so the customer knows exactly which fields will become static values. If the destination supports a third-party formula Power-Up, we document the original formula expression so the customer's admin can recreate it manually.

Stackby Rating columns (star ratings, numeric scales) map to Trello Custom Fields using either a Dropdown (with the rating scale as options) or a Text field (with the numeric rating as a static value). We recommend Dropdown for scales with fewer than 10 values because Trello's filtering works better with Dropdown Custom Fields. For larger scales or fractional ratings, we use a Text field to avoid creating an unwieldy dropdown list.

Stackby Link to Other Record columns establish relational lookups between Tables. Trello has no native relational model, so these links cannot be preserved as typed lookups. We handle cross-Table relationships in one of three ways, chosen during scoping: (1) embed the linked record name as a text field on the Card, (2) use the Card link Power-Up or Butler to create a cross-board card reference, or (3) document the lookup relationship in the migration handoff so the customer can restructure it using Trello Board connectors or a Power-Up. We flag every Lookup column during discovery so the customer understands the denormalization required.

Stackby automations (trigger-action rules with conditions and schedules) do not migrate. We document every active automation during discovery — including trigger type, conditions, and actions — and deliver a written inventory with recommended Trello Butler equivalents. The customer or a Trello partner rebuilds automations in Butler post-migration. Butler's capabilities (card triggers, due date triggers, Power-Up triggers) are more limited than Stackby's automation engine, so we note any automations that may not have a direct Butler equivalent.

Stackby's external integrations (Slack notifications, Google Sheets sync, Twilio SMS, Make/Zapier webhooks, API connections) do not migrate. Authentication tokens, OAuth credentials, and webhook URLs are platform-bound and cannot be transferred. We document every active integration during discovery and provide a reconfiguration checklist. The customer's team re-establishes these connections in Trello, which has its own ecosystem of Power-Up integrations that may partially replace the original Stackby integrations.