Migrate your Stackby data
Spreadsheet-database hybrid platform for non-technical teams building custom no-code workflows. Flexible but constrained by performance at scale and a restrictive API.
In its favor
Why people choose Stackby
The signal that keeps Stackby on the shortlist. Sourced from G2, Capterra, and customer scoping calls.
Lowest cost per user among no-code database platforms — the Business tier at $5/user/month gives teams relational database power without Airtable's pricing floor.
No technical training required — users with basic spreadsheet skills can build relational databases, making Stackby accessible to non-technical teams across industries.
25+ column types and multiple views (Grid, Kanban, Calendar, Gallery, Forms) let teams model nearly any workflow without writing code or commissioning developers.
Built-in automations allow teams to automate repetitive tasks without leaving the platform, reducing reliance on external automation tools like Zapier or Make.
Trusted by 75,000+ organizations in 150+ countries across diverse verticals including marketing, legal, real estate, and non-profits, indicating broad applicability.
Performance degrades noticeably with large datasets or multiple simultaneous views, pushing teams toward more scalable alternatives like Airtable or ClickUp.
Limited feature set compared to competitors — users cite missing features and feature limitations as ongoing frustrations that drive them to more comprehensive platforms.
No offline access capability — teams working in low-connectivity environments (field teams, remote sites) find the cloud-only model a dealbreaker.
Cluttered UI for new users makes onboarding difficult; combined with the learning curve of understanding Stackby's spreadsheet-database hybrid model.
Some users report the platform as unreliable, with one reviewer describing it as an unreliable platform that undermines its no-code potential.
Reasons to switch
Why people leave Stackby
The recurring reasons buyers give for replacing Stackby. Presented as facts, not knocks.
Platform scorecard
Strengths, weaknesses, and where Stackby fits
Grades across six dimensions, plus a SWOT-style view of where the platform shines and where it falls short.
SWOT — strengths, weaknesses, and use-case fit
Strengths
Weaknesses
Where it works
Where it struggles
Pricing tiers
Stackby pricing overview
Stackby uses a per-user, per-month pricing model across three self-serve tiers (Free, Business at $5, Pro at $30) with a custom Enterprise tier. Row limits per Stack vary non-linearly between tiers — Enterprise caps at 7,000 rows while Business allows 50,000, requiring careful verification during migration scoping. Attachment storage scales from 20GB on Business to unlimited on Enterprise.
Free
Tier 1 of 4
$0 (forever)
What's included
Need help selecting your Project Management?
Book a free 30 minute consultationPricing is informational. FlitStack AI does not bill on Stackby's schedule — see our quote-based pricing →
What gets migrated
Stackby object support
Object-by-object support for Stackby migrations. Per-pair details surface during scoping.
Stacks
Fully supportedStacks are the top-level organizational container in Stackby. They map directly to a destination workspace or project folder. We migrate all Stacks and preserve their structure during the migration, though access permissions may need reconfiguration.
Tables
Fully supportedTables within a Stack function like database tables or worksheets. Each Table has a defined schema of columns. We migrate Tables as standalone entities, preserving column order and type definitions across the migration.
Rows
Fully supportedRows are the individual records within a Table. We migrate all Rows up to the destination's record limits. We flag rows that will exceed the destination's limits and discuss archiving or splitting strategies before migration.
Columns (Column Types)
Mapping requiredStackby supports 25+ column types (Text, Number, Date/Time, Select, Multi-select, Attachments, Formulas, etc.). We preserve native column types where the destination supports them and map unsupported types to the closest equivalent (e.g., Multi-select to Tags). Custom formula columns are migrated as computed values rather than as live formulas.
Views (Grid, Kanban, Calendar, Gallery)
Mapping requiredViews define how data is visualized. Grid is standard; Kanban, Calendar, and Gallery are converted formats. We reconstruct view configurations in the destination if supported, though some visual layouts may require manual adjustment post-migration.
Forms
Mapping requiredForms in Stackby collect responses and create or update Rows. We migrate form structures including field mappings and validation rules. Response data stored in linked Tables migrates as standard Rows.
Attachments
Mapping requiredFile attachments stored in Tables have plan-specific limits (20GB on Business, unlimited on Enterprise). We migrate attachments to the destination's file storage, respecting any size or quota limits and downloading/uploading binary files via the Stackby API.
Revision History
Mapping requiredStackby preserves edit history — 1 year on Business, 3 years on Enterprise. We migrate the current state of records only; historical revisions are not preserved as they are typically not required for migration scope and would add significant complexity.
Automations
Not in this platformStackby Automations (triggers and actions) are platform-native workflow constructs. They cannot be exported as portable definitions and must be rebuilt in the destination system. We document all active automations during discovery so they can be reconstructed post-migration.
Integrations (API connections)
Not in this platformStackby's external API integrations (Slack, Google Sheets, Make, etc.) are configuration-level connections. These cannot be migrated — they require re-authentication and reconfiguration in the destination platform. We map which integrations are in use to guide post-migration setup.
Workspaces and Organizations
Fully supportedStackby's hierarchical structure (Organization > Workspace > Stack) maps to the destination's workspace or team structure. We migrate the full organizational hierarchy and assign users to their corresponding destination workspace.
User Accounts and Permissions
Mapping requiredUser accounts in Stackby are assigned roles and workspace-level permissions. We map user-to-role assignments and recreate permission sets in the destination, though role naming and granularity vary by platform and may require adjustment.
| Object | Support | Notes |
|---|---|---|
| Stacks | Fully supported | Stacks are the top-level organizational container in Stackby. They map directly to a destination workspace or project folder. We migrate all Stacks and preserve their structure during the migration, though access permissions may need reconfiguration. |
| Tables | Fully supported | Tables within a Stack function like database tables or worksheets. Each Table has a defined schema of columns. We migrate Tables as standalone entities, preserving column order and type definitions across the migration. |
| Rows | Fully supported | Rows are the individual records within a Table. We migrate all Rows up to the destination's record limits. We flag rows that will exceed the destination's limits and discuss archiving or splitting strategies before migration. |
| Columns (Column Types) | Mapping required | Stackby supports 25+ column types (Text, Number, Date/Time, Select, Multi-select, Attachments, Formulas, etc.). We preserve native column types where the destination supports them and map unsupported types to the closest equivalent (e.g., Multi-select to Tags). Custom formula columns are migrated as computed values rather than as live formulas. |
| Views (Grid, Kanban, Calendar, Gallery) | Mapping required | Views define how data is visualized. Grid is standard; Kanban, Calendar, and Gallery are converted formats. We reconstruct view configurations in the destination if supported, though some visual layouts may require manual adjustment post-migration. |
| Forms | Mapping required | Forms in Stackby collect responses and create or update Rows. We migrate form structures including field mappings and validation rules. Response data stored in linked Tables migrates as standard Rows. |
| Attachments | Mapping required | File attachments stored in Tables have plan-specific limits (20GB on Business, unlimited on Enterprise). We migrate attachments to the destination's file storage, respecting any size or quota limits and downloading/uploading binary files via the Stackby API. |
| Revision History | Mapping required | Stackby preserves edit history — 1 year on Business, 3 years on Enterprise. We migrate the current state of records only; historical revisions are not preserved as they are typically not required for migration scope and would add significant complexity. |
| Automations | Not in this platform | Stackby Automations (triggers and actions) are platform-native workflow constructs. They cannot be exported as portable definitions and must be rebuilt in the destination system. We document all active automations during discovery so they can be reconstructed post-migration. |
| Integrations (API connections) | Not in this platform | Stackby's external API integrations (Slack, Google Sheets, Make, etc.) are configuration-level connections. These cannot be migrated — they require re-authentication and reconfiguration in the destination platform. We map which integrations are in use to guide post-migration setup. |
| Workspaces and Organizations | Fully supported | Stackby's hierarchical structure (Organization > Workspace > Stack) maps to the destination's workspace or team structure. We migrate the full organizational hierarchy and assign users to their corresponding destination workspace. |
| User Accounts and Permissions | Mapping required | User accounts in Stackby are assigned roles and workspace-level permissions. We map user-to-role assignments and recreate permission sets in the destination, though role naming and granularity vary by platform and may require adjustment. |
Gotchas
What to watch for in Stackby migrations
Issues we've hit on past Stackby migrations, tagged by severity. FlitStack AI handles every one — surfacing them up front because buyer engineering teams want to know.
API rate limit of 5 req/s per stack blocks bulk migration
Plan-tier row limits can silently truncate data
Automations and integrations do not migrate — only data does
Formula columns become static values at migration time
Attachment storage limits vary by plan and must be verified
| Severity | Issue |
|---|---|
| High | API rate limit of 5 req/s per stack blocks bulk migration |
| High | Plan-tier row limits can silently truncate data |
| Medium | Automations and integrations do not migrate — only data does |
| Medium | Formula columns become static values at migration time |
| Low | Attachment storage limits vary by plan and must be verified |
Leaving Stackby?
Where Stackby customers move next
5 destinations Stackby can migrate to.
How a Stackby migration works
Four steps, Stackby-specific
Connect
API key into Stackby. Scopes limited to read-only on the data we move.
Map
We translate Stackby-specific structures (custom fields, objects, value lists) to the destination's model.
Sample
Test with a 50–200 record subset to validate Stackby quirks before production.
Migrate
Full migration with Stackby rate-limit handling. Rollback available throughout.
FAQ
Stackby migration FAQ
Answers to the questions buyers ask most during Stackby migration scoping. Not seeing yours? Book a call.
Can't find your answer?
Walk through your Stackby migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationOther project management tools we support
Ready when you are
Migrate Stackby.
Without the rebuild.
Free scoping call with a migration engineer. Tell us about your Stackby setup and destination — written quote back within a business day.