Migration snapshot
ActivePlatform
a Budibase
Repositioned around 'agents, apps and automations' in 2025–2026; GPL v3 core actively developed (github.com/budibase/budibase). Paid features (Business ~$50/creator + $5/app-user) are under Business Source License (BSL) — not open source. Self-hosted deployments phone home to the Budibase Account Portal for license activation (docs.budibase.com/docs/self-hosted-licensing).
Typical timeline
6–10 weeks
Typical cost
$13K–$25K (agency, fixed)
Why teams leave a Budibase
Budibase is genuinely good for small internal ops teams. The migration decision is usually triggered by one of three specific friction points: BSL license constraints, CouchDB data portability, or user scale.
BSL license friction
Paid features (audit logs, custom SSO policies) are under Business Source License — not freely distributable. Self-hosted deployments require a license key and an outbound 443 call to Budibase's Account Portal for activation. You cannot self-host independently of Budibase's servers on paid tiers.
Cloud→self-host backup restriction
Community threads note that cloud→self-host backup requires a paid plan (github.com/Budibase/budibase/discussions/9112 — anecdotal, GitHub). Free-tier data in the internal CouchDB may not be trivially extractable without upgrading temporarily.
Internal DB is CouchDB, not SQL
Budibase's internal database is CouchDB, not PostgreSQL. Migrating to Postgres requires a data transformation step — JSON document→relational table schema design — not a simple dump. Budget 1–2 weeks if your app uses the internal DB heavily.
Connector proliferation cost
If your app uses Budibase's built-in external connectors (Postgres, MySQL, Airtable, REST) as pass-throughs, your data is already external and the migration cost is primarily UI/logic rebuild. Assess connector usage before scoping.
Feature gating escalation
Free self-host supports up to 20 users. Beyond that, SSO and RBAC cost approximately $50/creator + $5/app-user monthly. At 25+ users, compare this to a custom Next.js stack cost.
What can you actually take with you?
External data is already yours and migrates trivially. The internal CouchDB database needs schema transformation. App UI and automation logic have no eject path.
| Asset | Can you export it? | How | Notes |
|---|---|---|---|
| Data (external connectors) | Yes | External data sources (Postgres, MySQL, REST APIs) are inherently portable — data lives in systems you own; Budibase is a pass-through layer only | No Budibase-specific work needed for external connector data |
| Data (internal DB) | Partial | Budibase internal DB is CouchDB; export/backup exists but cloud→self-host backup requires a paid plan (anecdotal, GitHub discussion #9112); CSV export available from the table UI | CouchDB JSON documents must be transformed to relational tables — schema design work required |
| Code | No | Apps are Budibase-proprietary configuration; no source-code eject | GPL v3 core is open source but your app definitions are not emitted as portable code |
| Design/UI | No | Component layout is Budibase-proprietary; no HTML or React export | Screenshot every screen for use as a parity specification during rebuild |
| Logic/Workflows | No | Automation workflows (triggers + actions) are Budibase-specific and must be rebuilt | Document every automation step manually before starting migration — this is often the most underestimated phase |
| Users & Auth | Partial | User list may be exportable via admin panel; SSO config (SAML/OIDC) is managed by your identity provider and is provider-side portable | Password hash export is not documented; built-in email/password users need forced reset |
Swipe the table sideways to see the full breakdown.
Where each piece moves in code
The target stack is Next.js (App Router) + Supabase/PostgreSQL — eliminating the CouchDB/BSL dependency and the license-key self-host model.
a Budibase
Budibase internal DB (CouchDB)
In code
Supabase PostgreSQL
Transform CouchDB JSON documents to relational tables during schema design phase — budget 1–2 weeks
a Budibase
Budibase external connectors (Postgres/MySQL/REST)
In code
Direct Supabase query via Drizzle or Prisma
Data already lives in your systems; this is a configuration swap, not a data migration
a Budibase
Budibase drag-drop UI (tables, forms, cards)
In code
shadcn/ui + Radix UI React components in Next.js
Rebuild screen by screen using screenshots as the parity spec
a Budibase
Budibase automations (scheduled, webhook, row-save triggers)
In code
Supabase Edge Functions or Next.js Route Handlers
Map every trigger type and action chain before writing replacement code
a Budibase
Budibase RBAC (roles per app)
In code
Supabase RLS policies + role column on user table
Document all role/permission sets per app before migration
a Budibase
Budibase app preview URLs
In code
Next.js pages with server-side auth guard in middleware
Auth guard replaces Budibase's built-in role-gating on app access
a Budibase
Budibase self-host (Docker + CouchDB + MinIO + Redis)
In code
Vercel + Supabase cloud, or self-hosted Next.js + Postgres
Eliminates the BSL license-key dependency and multi-service Docker ops overhead
The migration roadmap
Plan 6–10 weeks. The critical early step is separating external-connector data (trivial) from internal CouchDB data (requires schema design) to scope the migration accurately.
Audit & Extraction
Week 1- Audit which data lives in Budibase internal DB (CouchDB) vs external connectors — external data migrates trivially
- Export CouchDB data via Budibase backup (paid) or direct CouchDB API before changing any plan
- Document every automation: trigger type, conditions, actions, and schedule
- List all user roles and permission sets per app
- Screenshot every screen for parity testing
Watch out: Cloud→self-host CouchDB backup may require temporarily upgrading to a paid plan — verify this with Budibase support before canceling
Foundation & Schema Design
Week 1–3- Scaffold Next.js (App Router) + Supabase project
- Design relational Postgres schema from CouchDB JSON document structure
- Confirm all external data sources (Postgres, MySQL) are accessible directly outside Budibase
- Set up Supabase RLS policies mirroring Budibase role structure
Watch out: CouchDB → Postgres schema design is the most underestimated step; allocate 1–2 full weeks for data-modeling if internal DB is used heavily
Data Migration (CouchDB → Postgres)
Week 2–4- Transform CouchDB JSON documents to relational rows using the new schema
- Validate row counts and data integrity after transformation
- Write and run migration scripts; keep a rollback snapshot
UI & Automation Rebuild
Week 3–8- Rebuild screens with shadcn/ui components, screen by screen
- Implement each Budibase automation as a Supabase Edge Function or Route Handler
- Implement auth guard middleware for role-based route protection
- Build user management and password reset flows
Watch out: Automation rebuild is typically the most underestimated phase — complex branching automations require a dedicated discovery sprint
Parallel Run & Cutover
Week 8–10- Run Budibase and new app in parallel; validate data writes in both systems
- Force password reset for built-in email/password users
- Update SSO provider redirect URLs if applicable
- Decommission Budibase subscription after all teams confirm parity
Three ways to migrate — honestly
Every path has a real trade-off. Here is what each costs, how long it takes, and where it bites.
DIY (with AI tools)
$0–500 + your time
3–5 months part-time
Fits
Developers comfortable with Next.js and Supabase who have simple apps (3–5 screens, external-connector data only, minimal automations)
Risks
CouchDB → Postgres schema transformation is genuinely complex; skipping the schema design phase causes data loss or corruption; automation rebuild is easy to underestimate
Freelancer
$4K–10K
6–10 weeks
Fits
Apps with moderate complexity over external connectors and straightforward automation needs; freelancer must understand CouchDB-to-Postgres transformation and Supabase RLS
Risks
CouchDB expertise is less common than Postgres; vet explicitly; no fixed-price guarantee on scope changes
Agency (RapidDev)
Done-for-you$13K–25K fixed price
6–10 weeks
Fits
Internal apps with significant internal-DB usage, complex automations, SSO requirements, or teams that need a guaranteed cutover with zero data loss
Risks
Highest upfront investment; worth modeling BSL tier costs at 12-month projected user count before booking a free scoping call at rapidevelopers.com
The real risks — and how to defuse them
Internal DB data loss
Mitigation: CouchDB export tooling is less mature than Postgres pg_dump. Validate the backup before starting migration — export, restore to a local CouchDB instance, and confirm record counts before writing a single migration script.
BSL license ambiguity
Mitigation: Budibase's BSL prohibits circumventing feature gating — don't fork the BSL-licensed code and unlock paid features. The GPL v3 core is freely usable; the BSL paid features are not.
Automation gap
Mitigation: Budibase automations with complex branching can be time-consuming to replicate as code. Allocate a dedicated discovery sprint to map every trigger, condition branch, and action before writing replacement Edge Functions.
User auth disruption
Mitigation: Users on built-in email/password need a forced password reset on the new platform. SSO (SAML/OIDC) config needs to be recreated at the identity provider. Audit user auth types before cutover.
CouchDB → Postgres schema complexity
Mitigation: CouchDB stores documents as JSON; relational tables have different structure constraints. Schema design is the most frequently underestimated phase — do it before writing migration scripts, not during.
Should you actually migrate?
Migrating is a real project. Sometimes staying is the right call — here is the honest split.
Stay if
- Your team is 20 users or fewer and free self-host covers your RBAC needs without hitting BSL-gated features
- Apps are primarily CRUD over external Postgres/MySQL you already own — Budibase's drag-drop saves real engineering time for internal ops without CouchDB complexity
- You're already self-hosted and BSL constraints don't affect your usage — no advanced SSO or audit log requirements
Migrate if
- You need advanced SSO, audit logs, or user caps that push you into BSL-gated tiers with license-key dependency
- Your internal DB (CouchDB) holds critical data and cloud backup restrictions block your disaster recovery strategy
- You need a customer-facing application — Budibase is explicitly designed for internal tools and has no customer-facing aesthetic
Our honest verdict
Budibase is a practical choice for small internal ops teams with external DBs. Migration becomes rational when BSL feature gating, user scale, or CouchDB data-portability friction outweighs the drag-drop convenience. The self-host path does not escape the license dependency — only a full code migration does.
Do this today: pre-migration checklist
Whatever path you choose, protect yourself first. Work through this before you touch a line of code.
Audit which data lives in Budibase internal DB (CouchDB) vs external connectors
External connector data migrates trivially; CouchDB data requires schema transformation — knowing which you have determines the entire migration scope
Export CouchDB data via Budibase backup or direct CouchDB API before changing any plan
Cloud→self-host CouchDB backup may require a paid plan; export now while you have access, before initiating any plan change
Document every automation: trigger type, conditions, actions, and schedule
Budibase automations have no portable format; this documentation is your rebuild specification
List all user roles and permission sets per app
Supabase RLS policies must mirror Budibase's role structure exactly to avoid access gaps
Confirm your external data sources (Postgres, MySQL) are accessible directly outside Budibase
Confirms migration is unblocked — occasionally connection strings assume Budibase-network routing
Verify your BSL tier before attempting export — cloud→self-host backup may require a temporary upgrade
Prevents data loss during the extraction phase; a temporary plan upgrade is cheaper than losing internal-DB data
Frequently asked questions
Can I export my Budibase app as source code?
No. Budibase apps are stored as proprietary configuration — there is no source-code eject. The GPL v3 core is open source, but your app definitions are not emitted as portable code. You export data (CSV, CouchDB backup), not app logic or UI.
What happens to my data when I leave Budibase?
Data in external connectors (Postgres, MySQL, REST APIs) is already in systems you own — nothing to do. Data in Budibase's internal database (CouchDB) needs a backup export; note that cloud→self-host backup reportedly requires a paid plan (GitHub discussion #9112). CSV export is available from any table view on any plan.
How long does a Budibase migration take?
Typically 6–10 weeks. The largest variable is how much data lives in the internal CouchDB vs external connectors. External-connector-only apps are faster (4–6 weeks); apps with significant internal-DB usage and complex automations take longer due to the CouchDB → Postgres schema transformation step.
What happens to my users and passwords?
Users on built-in email/password auth will need a forced password reset on the new platform — password hash export is not documented. If you use SSO (SAML/OIDC), the config is managed by your identity provider and is portable; recreate the IdP connection on the new platform.
Is Budibase's self-host truly free?
The GPL v3 Community Edition core is free with no user cap. However, paid features (audit logs, custom SSO, advanced RBAC) are under Business Source License (BSL) and require a license key with an outbound call to Budibase's Account Portal. You cannot activate BSL features on a fully air-gapped self-host.
Can I just self-host Budibase instead of migrating to code?
Self-hosting keeps you on the BSL treadmill — license-key dependency persists and your app definitions remain Budibase-proprietary. Self-hosting solves the cloud cost question but not the lock-in question. If eliminating the license dependency is your goal, only a full code migration achieves that.
What is the hardest part of a Budibase migration?
Two things: the CouchDB → Postgres schema transformation (requires relational data modeling from JSON documents) and the automation rebuild (Budibase automations have no portable format and complex branching takes time). External-connector data and the UI rebuild are straightforward by comparison.
How much does a Budibase migration cost, and can RapidDev help?
DIY with AI tools: $0–500 plus 3–5 months part-time (works for simple apps over external connectors). Freelancer: $4K–10K over 6–10 weeks. Fixed-price agency: $13K–25K over 6–10 weeks. RapidDev specializes in internal-tool migrations with guaranteed parity — book a free scoping call at rapidevelopers.com to get a fixed-price estimate for your Budibase app.
We migrate no-code apps to production code
- Fixed price — $13K–$25K (agency, fixed)
- No data loss, no downtime
- You own 100% of the code
30-min call. Quote within 48 hours.