Migration snapshot
DecliningPlatform
a AppSheet
Google posted an 'AppSheet 2026 Product Strategy Update' on developer forums (discuss.google.dev) explicitly acknowledging that 'platform quality has not lived up' to expectations and pledging renewed focus on stability — a maintenance-mode signal from the platform owner. No shutdown announced, but the quality admission is rare candor from a platform owner.
Typical timeline
6–10 weeks
Typical cost
$13K–$25K (agency, fixed)
Why teams leave a AppSheet
AppSheet's migration case is unusual: the data is often not in AppSheet at all — it's in Google Sheets, BigQuery, or Cloud SQL. Google's 2026 quality admission, total code lock-in, and field-app ceiling make migration planning prudent now rather than after the next reliability incident.
Google's own quality-concern admission
The 'AppSheet 2026 Product Strategy Update' on discuss.google.dev explicitly acknowledged that platform quality has not met expectations. This is rare candor from a platform owner and signals a maintenance-mode pivot rather than active investment.
Total code lock-in
App definition is tied to Google's proprietary AppSheet runtime; no source-code export exists at any level. Every view, automation, and action rule must be rebuilt from scratch to migrate — the only thing you take with you is the underlying data.
Limited data-export tooling
AppSheet's own 'Export this view to CSV' action has a 2-minute processing limit and requires a signed-in browser session — not suitable for bulk migration. Production data in Google Sheets, BigQuery, or Cloud SQL must be exported from those source systems directly.
Google ecosystem dependency
AppSheet is valuable only inside Google Workspace/GCP. Teams that need Azure/AWS-native tooling, non-Google SAML/OIDC, or regulated data residency outside Google's infrastructure are second-class citizens with no native migration path.
Field-app feature ceiling
AppSheet's mobile offline sync, barcode scanning, and GPS features are fixed constructs. Complex field workflows quickly hit hard limits that require workarounds, accumulating technical debt in a proprietary environment.
What can you actually take with you?
The key insight: most AppSheet data is NOT in AppSheet — it lives in Google Sheets, BigQuery, or Cloud SQL where you can export it directly. App logic (views, automations, actions) has no export path and requires complete reconstruction.
| Asset | Can you export it? | How | Notes |
|---|---|---|---|
| Data | Partial | If backed by Google Sheets, BigQuery, or Cloud SQL — export directly from those source systems. AppSheet's own 'Export this view to CSV' has a 2-minute processing limit and requires a signed-in browser session. | Do not rely on AppSheet's built-in CSV export for bulk migration. Go directly to the underlying data source. Large Sheets with formula columns need a normalisation pass before importing into PostgreSQL. |
| Code | No | App definition runs only in AppSheet's runtime; no source-code export exists. | Full rebuild required. There is no AppSheet tier or plan that provides code export. |
| Design/UI | No | Views, UX elements, and branding are proprietary AppSheet constructs and are not exportable. | Screenshot all views (gallery, table, detail, form, map) to build the UI specification for the rebuild. |
| Logic/Workflows | No | Automation rules, bots, actions, and Security Filters are proprietary AppSheet constructs; must be reverse-engineered from the app editor. | Schedule walkthroughs with business owners to inventory every automation before writing backend code. Bots and Workflow automations are often the least-documented part of AppSheet apps. |
| Users & Auth | Partial | Auth is Google account or SSO provider. User records are accessible from the underlying data source (Sheets/BigQuery) where user-related columns are stored. | Password hashes are N/A — Google manages authentication. A re-invitation workflow is needed for any non-Google auth in the new system. |
| Security Filters | Partial | Security Filter definitions are human-readable in the AppSheet editor (Settings → Security → Filters); each filter can be manually documented. | Each Security Filter MUST become an RLS policy in Supabase. Missing one creates a data-exposure vulnerability. Treat each filter as a security requirement, not an app feature. |
Swipe the table sideways to see the full breakdown.
Where each piece moves in code
AppSheet apps migrate to a Next.js (App Router) + Supabase (PostgreSQL) stack. The Sheets/BigQuery data model is normalised into PostgreSQL tables; AppSheet Security Filters become Supabase RLS policies; automations become Supabase Edge Functions or Next.js API Route Handlers.
a AppSheet
AppSheet table (backed by Google Sheets)
In code
Supabase PostgreSQL table with proper schema and indexes
Run a data-quality audit on the Sheets source first — merged cells, ad-hoc columns, and formula columns need normalisation before import.
a AppSheet
AppSheet table (backed by BigQuery)
In code
Supabase PostgreSQL (operational data) or direct BigQuery API calls from Next.js API routes (analytics data)
Keep BigQuery for analytical queries if the volume justifies it; use Supabase as the operational source of truth.
a AppSheet
AppSheet Views (gallery, table, detail, form)
In code
Next.js page components with data fetching from Supabase
Each view type maps to a distinct Next.js component pattern. Screenshot each view type before closing the AppSheet app.
a AppSheet
AppSheet Slice (filtered view)
In code
Supabase query with WHERE clause + Row-Level Security policy
Slices that filter by user identity become RLS policies; slices that filter by data attribute become WHERE clauses in Drizzle/Prisma queries.
a AppSheet
AppSheet Workflow / Bot automation
In code
Supabase Edge Function or Next.js API Route Handler triggered via webhook
Email and notification bots map to Supabase Edge Functions calling a transactional email service (Resend, SendGrid).
a AppSheet
AppSheet Action (custom action button)
In code
React client component triggering a Server Action
Multi-step actions that modify multiple rows become Server Actions with database transactions.
a AppSheet
AppSheet Security Filter
In code
Supabase Row-Level Security policy (auth.uid() based)
This is the most security-critical migration step. Each Security Filter must have a corresponding RLS policy before go-live.
a AppSheet
AppSheet offline sync
In code
PWA service worker + Supabase offline-capable client or React Query cache
Offline sync is non-trivial to replicate. Scope this requirement explicitly upfront — a PWA with service worker adds 2–3 weeks to the frontend sprint.
The migration roadmap
A standard AppSheet migration runs 6–10 weeks. The extraction phase focuses on the underlying data sources (Sheets/BigQuery) rather than AppSheet itself — this is the key practical differentiator for AppSheet migrations.
Extraction & Audit
Weeks 1–2- Export all data from underlying sources (Google Sheets, BigQuery, Cloud SQL) — bypass AppSheet's 2-minute CSV export
- Document every computed/virtual column in the AppSheet editor (these don't exist in the source data and must become PostgreSQL generated columns or app-layer logic)
- List every Security Filter in the app — these become Supabase RLS policies and are security-critical
- Inventory all Bots and Workflow automations with business owners
- Screenshot or record every View type to build the UI specification
Watch out: AppSheet computed/virtual columns are critical hidden complexity. They don't exist in Google Sheets — they're calculated by AppSheet at runtime. Document every formula column before starting the migration or they will be silently lost.
Foundation & Data Model
Weeks 2–4- Normalise Google Sheets data structure into a proper PostgreSQL schema (fix merged cells, ad-hoc columns, data type inconsistencies)
- Set up Supabase PostgreSQL with tables mirroring the normalised schema
- Implement Row-Level Security policies for every AppSheet Security Filter
- Configure Supabase Auth (Google OAuth or new auth provider) and set up Next.js App Router project
Backend & Automations
Weeks 4–7- Build Supabase Edge Functions or Next.js API Route Handlers for each Bot/Workflow automation
- Implement PostgreSQL generated columns for computed column logic
- Set up email/notification integrations replacing AppSheet notification bots
- Import validated production data into Supabase PostgreSQL
Frontend Build & UAT
Weeks 7–10- Build Next.js page components from the View screenshot inventory
- Implement offline sync if required (PWA service worker + Supabase client caching)
- Verify each RLS policy against the AppSheet Security Filter specification
- Run parallel UAT with AppSheet and Next.js apps; confirm cutover date before next AppSheet billing cycle
Watch out: Verify every RLS policy before go-live. A missed Security Filter in AppSheet becomes a data exposure vulnerability in the new system — treat this as a security audit, not a feature check.
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 (infra costs)
2–4 months part-time
Fits
Simple AppSheet apps backed by Google Sheets with fewer than 10 views, no offline sync, and 1–2 automations. In-house team must be comfortable with Next.js and Supabase RLS.
Risks
Security Filter → RLS translation is the most dangerous DIY step. A missed policy creates a data exposure vulnerability. Get a security review of all RLS policies before go-live, even on a DIY project.
Freelancer
$3K–8K
1–3 months
Fits
Mid-complexity AppSheet apps (10–25 views, standard automations, Sheets-backed data) where the client can handle data extraction from Google Sheets and business-owner automation walkthroughs.
Risks
Freelancers unfamiliar with Supabase RLS may implement access control at the application layer only — functionally equivalent but not secure at the database level. Require demonstrated RLS experience.
Agency (RapidDev)
Done-for-you$13K–$25K fixed
6–10 weeks
Fits
AppSheet apps with complex Security Filters (critical compliance requirement), BigQuery analytics, offline sync requirements, or non-Google auth migration. Fixed price gives the client predictability on a migration with security implications.
Risks
Fixed-price scope requires the full Security Filter inventory and data source mapping before contract sign. Book a free scoping call with RapidDev to define scope and confirm security requirements.
The real risks — and how to defuse them
Computed/virtual column loss
Mitigation: AppSheet computed columns don't exist in the source data — they're calculated at runtime. Document all formula columns in the app editor before starting; convert to PostgreSQL generated columns or application-layer logic before data import.
Security filter parity gap
Mitigation: Missing an AppSheet Security Filter in the RLS migration creates a data-access vulnerability. Treat each Security Filter as a security requirement; conduct an explicit RLS policy review with a security lens before go-live.
Google Sheets data quality
Mitigation: Sheets used as app backends often have formatting inconsistencies, merged cells, empty rows, and ad-hoc columns. Run a data-quality audit and normalisation pass before importing into PostgreSQL — this phase is commonly underestimated.
Offline sync complexity
Mitigation: AppSheet's built-in offline sync is non-trivial to replicate. Scope offline requirements explicitly before scoping begins; a PWA with service worker adds 2–3 weeks to the frontend sprint and may affect the fixed-price quote.
Auth transition for non-Google users
Mitigation: AppSheet uses Google auth. If the new system uses a different auth provider (Supabase Auth, Clerk), plan a user re-invitation flow. Communicate the auth change at least 2 weeks before cutover.
Google BigQuery re-dependency
Mitigation: The new system may still need BigQuery for reporting analytics. Plan Supabase as the primary operational DB; connect BigQuery for analytics via the postgres_fdw extension or a scheduled export rather than keeping BigQuery as the operational source of truth.
Should you actually migrate?
Migrating is a real project. Sometimes staying is the right call — here is the honest split.
Stay if
- Your team lives entirely in Google Workspace and the app is a simple internal form/data-collection tool with fewer than 200 rows and no complex automation.
- AppSheet's native mobile scanning (barcode, QR, image) and GPS features are core to your field workflow and would take 3+ weeks to replicate — the rebuild cost exceeds the platform risk.
- Google's 2026 stability pledge resolves the quality issues within your planning horizon and your use case doesn't require logic beyond AppSheet's formula engine.
- Your data model fits cleanly in Google Sheets and you have no compliance requirements that conflict with Google's infrastructure.
Migrate if
- You've hit AppSheet's action/automation limits and are spending engineering time on workarounds rather than on the app's actual purpose.
- Your data model has grown beyond what Google Sheets can reliably handle — more than 10K rows, multiple concurrent writers, or significant formula complexity.
- You need non-Google auth (SAML/OIDC with a corporate IdP not on Google) or compliance controls (HIPAA, EU data residency outside Google) that AppSheet doesn't expose.
- Google's 2026 quality admission combined with total code lock-in makes you unwilling to invest further in a platform whose trajectory is uncertain.
Our honest verdict
AppSheet is a reasonable Sheets-to-app bridge for simple internal tools. Google's own 2026 quality admission, combined with total code lock-in and a 2-minute data-export limit, makes it a poor foundation for anything customer-facing or business-critical.
Do this today: pre-migration checklist
Whatever path you choose, protect yourself first. Work through this before you touch a line of code.
Export all data from underlying sources (Google Sheets, BigQuery, Cloud SQL) — do not rely on AppSheet's 2-minute CSV export
This is the cleanest data path. AppSheet's built-in export is unsuitable for bulk migration; the source systems have full export capabilities.
Document every AppSheet computed/virtual column and its formula
These columns don't exist in your data sources and will be silently lost if not documented. They become PostgreSQL generated columns or application logic.
List every Security Filter in the app — each becomes an RLS policy in Supabase
Security Filters are access control rules. Missing one in the migration creates a data exposure vulnerability in the new system.
Inventory all Bots and Workflow automations with business owners
Automations are the least-documented part of AppSheet apps. Business owners often know of automation rules that don't appear in the editor inventory.
Screenshot or screen-record every View type to build the UI specification
AppSheet views have no export; screenshots are the only reconstruction method for gallery, detail, form, map, and table views.
Confirm Google Workspace auth policy — who will need re-invitation in the new system
If the new system uses non-Google auth, every user needs a re-invitation. Identify the affected user count before cutover planning.
Check AppSheet plan renewal date; align migration cutover before the next billing cycle
Timing the cutover before renewal avoids paying an additional AppSheet term after the new system is live.
Frequently asked questions
Can I export my AppSheet app code?
No. AppSheet app definitions run only in AppSheet's proprietary runtime; there is no source-code export at any plan tier. Every view, automation, bot, and action rule must be reconstructed from scratch. The only thing you export is the underlying data — and that comes from Google Sheets, BigQuery, or Cloud SQL directly, not from AppSheet itself.
How do I export my AppSheet data?
Go directly to the underlying data source, not AppSheet's built-in export. If backed by Google Sheets, export the sheet as CSV or connect via the Sheets API. If backed by BigQuery or Cloud SQL, use those systems' native export tools. AppSheet's own 'Export this view to CSV' has a 2-minute processing limit and is not suitable for migration-scale exports.
How long does migrating from AppSheet take?
A typical AppSheet migration runs 6–10 weeks. Simple apps (under 10 views, Sheets-backed, no offline sync) are on the lower end. Apps with complex Security Filters, BigQuery analytics, or offline sync requirements run closer to 10 weeks. The data normalisation phase (converting Sheets structure to proper PostgreSQL schema) is the most commonly underestimated step.
What happens to my users after migration?
AppSheet uses Google account authentication. Password hashes are N/A — Google manages authentication. If your new system uses a different auth provider, you'll need to re-invite users. Identify who needs re-invitation (non-Google Workspace users are most affected) and communicate the auth change at least 2 weeks before cutover.
Is AppSheet shutting down?
No shutdown has been announced, but Google's 2026 Product Strategy Update explicitly acknowledged that 'platform quality has not lived up' to expectations — rare candor from a platform owner. The platform is active but the quality admission signals a maintenance-mode pivot. For business-critical apps, migration planning now is prudent rather than reactive.
What replaces AppSheet Security Filters in the new stack?
Each AppSheet Security Filter becomes a Supabase Row-Level Security (RLS) policy. Security Filters are the most critical migration step — a missed filter creates a data-access vulnerability in the new system. Treat the Security Filter inventory as a security audit, not a feature checklist. Review all RLS policies with a security lens before go-live.
Can I keep using Google Sheets as my database after migrating?
Technically yes, but it is not recommended for production apps. Google Sheets has row limits, concurrent-writer issues, formula fragility, and no transactional guarantees. The recommended approach is to migrate operational data to Supabase PostgreSQL and connect BigQuery for analytics if needed — using the postgres_fdw extension or a scheduled export.
How much does it cost to migrate off AppSheet?
A fixed-price agency migration (like RapidDev) runs $13K–$25K for a well-scoped AppSheet app and takes 6–10 weeks. Freelancers typically quote $3K–$8K for simpler apps. DIY with in-house developers is feasible for simple apps ($0–$500 in infra costs) but requires careful attention to Security Filter → RLS translation. Book a free scoping call to size your specific 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.