In September 2025, Google announced the discontinuation of Tables, its work-tracking and database product launched five years earlier as an Airtable competitor. By December 16, 2025, Tables was gone. Users were given the choice to migrate to Google Sheets, AppSheet, or — implicitly, since Google wouldn't recommend it — a competitor like Airtable.
If you were a Google Tables user, you've already migrated by now. If you have data still locked in a Tables export waiting for a destination, this guide is for you. We'll walk through the three options Google offered, why Airtable is the most natural fit for most former Tables users, and the exact steps to move.
What Happened to Google Tables
Google Tables launched in 2020 out of Google's Area 120 incubator. It was Google's answer to Airtable — a relational database with views, forms, automations, and a more friendly UX than Sheets. In 2021 it graduated from beta to a full Google Cloud product.
It never gained meaningful traction. The reasons cited in coverage at shutdown: Airtable's first-mover advantage was substantial, Tables didn't have a clear differentiation beyond Google Workspace integration, and Google had limited willingness to keep investing in a category where it was clearly behind.
The shutdown announcement came in September 2025. Users had three months to export or migrate. After December 16, 2025, Tables stopped working. Existing data was exportable through the Tables interface or migratable into AppSheet through a Google-provided migration tool.
The Three Migration Paths
Three legitimate options, each with its own trade-offs.
Option 1: Google Sheets
Google's first recommended path. Use Google Sheets, possibly with the newer "Tables" feature inside Sheets that adds structured-data capabilities to traditional cells.
Best for: Users whose Tables use was mostly spreadsheet-like. Tracking lists, simple calculations, light dashboards.
Trade-off: You lose the relational structure. Tables-as-Tables had a database feel; Sheets is fundamentally a spreadsheet, even with the Tables feature. Linked records become VLOOKUPs. Multiple views become tabs or filter views. Automation becomes Apps Script.
Option 2: AppSheet
Google's second recommended path and the one they emphasized for users who needed more than a spreadsheet. AppSheet is Google's no-code app builder, sitting on top of Sheets and other data sources.
Best for: Users who want to turn their data into a mobile-friendly app. Field workers, internal team apps, role-based interfaces.
Trade-off: You shift mental models. AppSheet thinks of your data as the back-end of an app, not a database in its own right. You'll spend significant time configuring views and actions. Pricing adds to your Workspace subscription.
The migration tool from Tables to AppSheet preserved column types and relationships, which made it the path of least resistance for users who wanted to stay in the Google ecosystem.
Option 3: Airtable
The path Google didn't recommend (obviously) but the one many Tables users ended up taking.
Best for: Users who valued Tables specifically as a relational database with multiple views — which describes most Tables use cases.
Trade-off: Less native Google Workspace integration. Different account system (no automatic Google SSO unless you're on Airtable Business+).
Why Airtable Fits Most Former Tables Users
A direct feature comparison of what Tables did and what each alternative does:
| Tables capability | Airtable | Google Sheets | AppSheet |
|---|---|---|---|
| Multiple table types in one base | ✓ Native | Limited (tabs) | ✓ Multiple tables |
| Multiple views per table | ✓ 8 view types | Filter views (limited) | ✓ Multiple views |
| Linked records | ✓ Strong | VLOOKUPs only | ✓ References |
| Forms | ✓ Native | Google Forms | ✓ Native |
| Automations | ✓ Native + Make/Zapier | Apps Script | ✓ Workspace native |
| Kanban / Calendar / Gallery views | ✓ All | No | ✓ Yes |
| Custom interface / app | ✓ Interface Designer | No | ✓ App builder (core feature) |
| Outside-Google integrations | ✓ 3,000+ via Make | Limited | Limited |
| Mobile-first design | Solid but desktop-first | Limited | ✓ Mobile-first |
The honest read: Airtable is the closest equivalent to Tables in feature shape. AppSheet is more app-builder-focused; Sheets is more spreadsheet-focused. If you used Tables as Tables — a structured database with multiple views — Airtable is the most direct successor.
Step-by-Step: Migrating Tables Data to Airtable
If you exported your Tables data before the shutdown (or have it in AppSheet now), here's the migration flow.
Step 1: Inventory What You Have
For each Tables table or AppSheet table, capture:
- The table's purpose (clients, projects, tasks, etc.)
- The columns and their types
- The relationships to other tables (which columns reference which)
- The automations or workflows attached to it
A 30-minute inventory saves hours of guesswork during migration.
Step 2: Design the Airtable Schema
Before importing data, plan the Airtable structure on paper. The translation rule:
- Each Tables table → one Airtable table
- Tables columns that referenced another table → Linked Record fields in Airtable
- Tables view types → corresponding Airtable view types
- Tables filters → Airtable view filters
- Tables automations → Airtable automations or Make scenarios
If your Tables structure had problems (denormalized data, missing relationships), now is the time to fix them. A migration is the right moment to redesign.
For schema design patterns, see our linked records guide.
Step 3: Export from Source
If your data is still in Tables: use Tables' built-in export to CSV (one file per table).
If you've already migrated to AppSheet: export each table from AppSheet as CSV.
If you migrated to Sheets: each sheet is already a single CSV's worth of data.
Step 4: Import to Airtable
For each CSV file:
- In Airtable, open the destination base.
- Click + to add a new table → Import → CSV file.
- Upload the CSV.
- Review the column type detection and adjust as needed (Airtable's auto-detection is good but always worth a check, especially for dates and numbers).
- Run the import.
The import order matters: import "parent" tables first (Clients, Projects), then "child" tables that reference them (Tasks).
Step 5: Recreate Relationships
After import, the relationship columns are text fields with values (e.g., "Acme Corp" repeated across many records). Convert them to linked records:
- Open the child table.
- Click the column header → Change field type → Link to another record.
- Pick the parent table.
- Airtable will attempt to match text values to records in the parent table by primary field — usually it succeeds.
Repeat for every relationship column.
Step 6: Add Views, Forms, Automations
Once the relational structure is in place, add the views, forms, and automations the system needs. This is also when you can take advantage of Airtable features Tables didn't have — Interface Designer, multiple view types, more sophisticated automations.
For more on view design, see our custom views guide. For automation patterns, our Airtable automation guide covers the basics.
Step 7: Test and Cut Over
Before fully switching:
- Test the migrated system with real users
- Verify automations fire correctly
- Spot-check data accuracy against the original
- Document the schema for the team
Total migration time for a typical Tables base: 4-8 hours of focused work, plus team training time.
What You'll Gain
The honest list of upgrades Tables users experience after moving to Airtable:
- Multiple view types — Kanban, Calendar, Gallery, Gantt, Timeline (Tables had fewer)
- Interface Designer for custom front-ends
- A much larger integration ecosystem via Make and Zapier
- Stronger linked records, lookups, and rollups
- A maturing AI feature set (Cobuilder, AI fields)
- Active product development — Tables stopped getting updates well before the shutdown announcement
What You'll Lose
Equally honest:
- Workspace-native authentication (unless on Airtable Business+ with SAML SSO)
- Tight Google Workspace integration — you can still connect Airtable to Drive, Docs, Calendar via Make/Zapier, but it's not as automatic as AppSheet's native links
- A free tier as generous as Tables had (Airtable's free tier is still useful but more limited)
For most teams, the trade is favorable.
A Note on AppSheet
If you followed Google's recommendation and went to AppSheet, you're not stuck. AppSheet can also be migrated to Airtable. The data is exportable, the schema is portable. The process is the same as the Tables-to-Airtable flow above, just starting from your AppSheet export instead.
Many former Tables users went to AppSheet first because Google made it easy, then found themselves wanting more flexibility and migrated to Airtable in a second move. That second migration is straightforward.
Where to Go Next
For the foundational concepts you'll need to use Airtable effectively, our linked records guide, formulas cheat sheet, and Airtable automation guide cover the three skills that matter most.
For the broader spreadsheet-to-Airtable migration pattern (which overlaps significantly with the Tables migration), see our how to replace spreadsheets with Airtable guide.
