# Migrating AppSheet to Code: The Complete Playbook (2026)

- Tool: No-Code to Code Migrations
- Last updated: July 2026

## TL;DR

AppSheet is declining — Google's own 2026 Product Strategy Update acknowledged that platform quality has not met expectations. Your app code cannot be exported, but your data likely lives in Google Sheets, BigQuery, or Cloud SQL where you can access it directly. A typical migration runs 6–10 weeks at $13K–$25K. If your data model has outgrown Sheets or you need non-Google auth, migration is the right call now.

## Platform status

- Status: declining — 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.
- Migration urgency: medium
- Typical timeline: 6–10 weeks
- Typical cost: $13K–$25K (agency, fixed)

## Why migrate

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 you can export

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 | Exportable | How |
| --- | --- | --- |
| 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. |
| Code | no | App definition runs only in AppSheet's runtime; no source-code export exists. |
| Design/UI | no | Views, UX elements, and branding are proprietary AppSheet constructs and are not exportable. |
| Logic/Workflows | no | Automation rules, bots, actions, and Security Filters are proprietary AppSheet constructs; must be reverse-engineered from the app editor. |
| 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. |
| Security Filters | partial | Security Filter definitions are human-readable in the AppSheet editor (Settings → Security → Filters); each filter can be manually documented. |

## Stack mapping

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.

| Platform concept | Code equivalent |
| --- | --- |
| AppSheet table (backed by Google Sheets) | Supabase PostgreSQL table with proper schema and indexes |
| AppSheet table (backed by BigQuery) | Supabase PostgreSQL (operational data) or direct BigQuery API calls from Next.js API routes (analytics data) |
| AppSheet Views (gallery, table, detail, form) | Next.js page components with data fetching from Supabase |
| AppSheet Slice (filtered view) | Supabase query with WHERE clause + Row-Level Security policy |
| AppSheet Workflow / Bot automation | Supabase Edge Function or Next.js API Route Handler triggered via webhook |
| AppSheet Action (custom action button) | React client component triggering a Server Action |
| AppSheet Security Filter | Supabase Row-Level Security policy (auth.uid() based) |
| AppSheet offline sync | PWA service worker + Supabase offline-capable client or React Query cache |

## 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.

### Phase 1: 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.

### Phase 2: 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

### Phase 3: 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

### Phase 4: 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.

## Cost paths

| Path | Cost | Timeline | Fits |
| --- | --- | --- | --- |
| DIY (with AI tools) | $0–500 (infra costs) | 2–4 months part-time | 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. |
| Freelancer | $3K–8K | 1–3 months | 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. |
| Agency (RapidDev) | $13K–$25K fixed | 6–10 weeks | 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 and mitigations

- **Computed/virtual column loss** — 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** — 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** — 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** — 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** — 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** — 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.

## Stay or go

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.

Go 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.

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.

## Migration checklist

- 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.

---

Source: https://www.rapidevelopers.com/no-code-to-code/how-to-migrate-appsheet-project-to-code
© RapidDev — https://www.rapidevelopers.com/no-code-to-code/how-to-migrate-appsheet-project-to-code