How Notion State Migrated 169K Records Across 11 Relational Tables from Caspio to Notion

TL;DR

Customer: Notion State (Notion consulting and implementation agency. Part of Arbr Labs LLC.)

The Move: Caspio to Notion

The Scope: 169,497 records across 11 Caspio tables, spanning ~4 years of data (2022 to 2026). Full relational schema including inter-table relations, rollups, formula fields, file/image attachments, and multi-select properties.

The Roadblock: Caspio and Notion store data in fundamentally different ways. Caspio column types (text, number, date-time, boolean, file, list-string) had to be mapped to Notion property types. Relations between tables required both databases to be fully populated before linking. Formula and rollup columns could not be migrated programmatically and needed manual recreation in Notion.

The Outcome: All 11 tables migrated with full relational integrity. Every inter-table relation preserved. File attachments and images transferred to Notion file properties.

By the Numbers

• Total records migrated: 169,497
• Caspio tables migrated: 11
• Data span: ~4 years (2022 to 2026)

The Challenge: A Relational Database That Needed to Stay Relational

Notion State is a Notion consulting and implementation agency that helps organizations design, build, and manage Notion workspaces for their operations. Their client roster includes companies like HoneyBook, Typeform, airCFO, and XMTP. When one of their projects required migrating an existing Caspio database into Notion, the challenge was not moving rows. It was preserving the relationships between them.

Caspio is a no-code cloud database platform built for structured business applications. It stores data in traditional relational tables with typed columns, foreign keys, and computed fields like formulas and rollups. Notion databases look similar on the surface but work differently under the hood. Notion uses page-based records, relation properties that link between databases, and its own formula and rollup system that cannot be populated via API.

The migration had to bridge three structural gaps:

• Schema translation. Caspio columns (text, number, date-time, boolean, file, list-string) needed to be mapped to the correct Notion property types. Comma-separated list-string fields in Caspio had to become multi-select properties in Notion.
• Relational linking. Caspio tables used foreign keys to link rows across tables. In Notion, relations are page-to-page links that require both sides of the relationship to exist as Notion pages before they can be connected. A row in Table A cannot link to a row in Table B if Table B has not been migrated yet.
• Non-migratable computed fields. Caspio formula and rollup columns produce calculated values that depend on the database engine. Notion's formulas and rollups are defined in the UI and cannot be set through the API. These had to be recreated manually in Notion after the data load.

The ClonePartner Solution: Paginated Export, Schema Mapping, and Two-Pass Relational Linking

ClonePartner built a migration pipeline that pulled data from Caspio's REST API, transformed it to match Notion's property types, and loaded it in a specific order that ensured relational integrity.

• Paginated Caspio export. Data was pulled from Caspio's REST API using page-token cursors in 1,000-row pages, with rate-limit handling on both the Caspio and Notion sides. Each of the 11 tables was exported individually.

• Schema mapping. Every Caspio column type was mapped to its Notion equivalent: text to rich text, numbers to number properties, date-times to date properties, booleans to checkboxes, files to file properties, and list-strings to multi-select properties. The mapping was applied during the transformation step before any data was pushed to Notion.

• Two-pass relational linking. Relations were handled in two passes. In the first pass, all 11 Notion databases were created and populated with their rows. Each new Notion page's ID was recorded back against its source Caspio row in a mapping table. In the second pass, ClonePartner used Caspio's foreign-key values and the Notion ID map to connect related pages across databases. This two-pass approach ensured that both sides of every relationship existed before any link was created.

• File and image attachments. Files and images stored in Caspio were downloaded and uploaded to Notion as file properties on the corresponding page. Each attachment was associated with its correct record through the ID mapping.

• Post-migration formula and rollup recreation. After all data and relations were in place, formula and rollup columns were recreated manually in Notion's UI. These columns could not be migrated programmatically because Notion's formula engine only accepts definitions through the interface, not data through the API.

The Results: 11 Connected Databases, Ready for Notion State's Build

All 169,497 records landed in Notion across 11 databases with full relational integrity. Every foreign-key relationship from Caspio was translated into a Notion relation. Multi-select properties replaced comma-separated list-strings. File attachments sat on their correct pages.

For Notion State, the migration provided a clean data foundation for the Notion workspace build. Rather than spending consulting hours on data entry, data cleaning, or manual CSV imports (which do not support relations), the team could move directly into workspace design, views, filters, and the UI layer their clients depend on.

What Made This Migration Different

For teams planning a migration from a traditional relational database into Notion, two structural realities are worth understanding:

• Relations require a two-pass approach. Notion's relation properties link pages, not rows. Both pages must exist before they can be connected. Any migration that tries to create rows and link them in a single pass will fail on records whose related pages have not been created yet. The two-pass pattern (populate all databases first, then link) is the only reliable approach for relational migrations into Notion.

• Formulas and rollups cannot be migrated. Notion's formula and rollup columns are defined in the UI and computed by Notion's engine. They cannot be set through the API. If the source database relies heavily on computed fields, those definitions need to be recreated manually in Notion after the data load. Treating this as a known post-migration step prevents it from becoming a surprise.