Migrate from Stackby to monday Work Management

Stackby's Stacks map to monday.com Workspace folders with one primary Board per Stack. Each Stack is assigned its own monday.com board, preserving the Stack's name and top-level structure. Multiple related Stacks within an Organization can be grouped into a single monday.com Workspace. We set up the Workspace hierarchy during discovery to match the source Organization > Workspace > Stack lineage.

Stackby Tables map directly to monday.com Boards. Each Table's column schema (column names, types, and order) translates to monday.com column definitions. Tables linked via Stackby's API within the same Stack are evaluated for cross-board connection via monday.com's Connect Boards column type. Tables that are purely relational (lookup-only with no standalone records) may be archived post-migration rather than migrated as empty boards.

Stackby Rows migrate to monday.com Items on the target Board. Each Item receives the column values from the source Row, mapped to the equivalent monday.com column type. Items are inserted in dependency order — Items that are referenced via Connect Boards columns are migrated after the target board Items exist so that the cross-board link resolves correctly. Row status (active, archived) maps to Item archive state in monday.com.

Stackby's 25+ column types map to monday.com column equivalents by type. Text maps to Text Column, Number to Numbers Column, Date to Date Column, Select to Status Column, and Multi-select to Tags Column. We preserve the column display order from the source Table and flag any column type that does not have a direct equivalent so that the customer can confirm the fallback mapping before migration.

Stackby Attachment columns migrate to monday.com File Upload columns. We download each file from Stackby's attachment storage via API and upload to monday.com's file storage. Attachment volume is audited during discovery — Stackby Business caps at 20GB per Stack and Enterprise is unlimited. We flag any Stack where total attachment volume exceeds the destination plan's storage allowance before migration begins.

Stackby's Formula, Rollup, and Count columns compute dynamically and do not have structural equivalents in monday.com. During migration, these columns transfer as their computed values at migration time. If the destination monday.com workspace has the Formula column (beta) enabled, we attempt to reconstruct the formula logic using the original Stackby formula as reference, noting that monday.com's function library is more limited than Stackby's. The customer reviews and approves the formula mapping during schema design.

Stackby's relational Lookup and Link to Another Record columns represent the most complex migration mapping. We evaluate each lookup: if both Tables migrate to monday.com boards in the same Workspace, we use the Connect Boards column type to establish a live cross-board link. If the source lookup spans Stacks that map to separate Workspaces, we flag the limitation and recommend either restructuring the Workspace hierarchy or using a mirror text column with the linked record identifier as a static reference.

Stackby's view configurations (Grid, Kanban, Calendar, Gallery) do not migrate as separate view definitions. We replicate the most critical view for each Table: a Kanban view migrates to a monday.com board's native Kanban view (grouped by the mapped Status column); a Calendar view migrates to a monday.com Calendar view using the mapped Date column. Grid view is the default monday.com board layout and requires no special configuration. We document all non-replicated view configurations as a written inventory for the customer to rebuild in monday.com.

Stackby Forms (response collection forms that create or update Rows) map to monday.com's native Form feature. The form field structure and validation rules migrate as a Form on the equivalent Board. Form submission data stored in linked Tables migrates as standard Rows. The visual layout and branding of the original Stackby Form is not preserved; we document it as a rebuild requirement for the customer.

Stackby's organizational hierarchy (Organization > Workspace > Stack) maps to monday.com's Account > Workspace structure. We migrate each Stackby Workspace as a monday.com Workspace, preserving the workspace name and member assignments. User-to-member mapping is resolved by email match during migration, and any Stackby user without a matching monday.com account is flagged for the customer to provision.

Stackby user roles (Admin, Member, Guest) map to monday.com permission levels (Admin, Member, Guest or Viewer). Workspace-level permission sets migrate to monday.com Workspace access settings. Individual Stack-level permissions are consolidated to Workspace-level during migration since monday.com does not support board-level permission inheritance in the same manner as Stackby's Stack-level access model.

Stackby automations (trigger-action workflows with API connectors to Slack, Make, Google Sheets, and other services) are configuration-bound and cannot be exported as portable definitions. We document every active automation during discovery — its trigger, conditions, and actions — and deliver a written inventory with recommended monday.com Automation equivalents. The customer's team rebuilds automations inside monday.com's recipe builder post-migration. Note: as of January 2026, monday.com is migrating its automation infrastructure to a unified monday workflows system, which affects rebuild scope.