Making an undocumented Airtable system portable

Airtable is extremely good at helping organisations build operational systems quickly. It is much less good at explaining what has been built once the original creator has moved on, the base has grown across several years or the organisation begins considering migration.

The records are only half the system

A spreadsheet export preserves values. It does not preserve the data model that makes those values useful: the field definitions, formulas, linked-record relationships, select options, configuration choices and dependencies built into the base.

Before an Airtable system can be documented, reviewed or migrated, someone needs to establish what is actually there.

• Which tables exist and how they relate to each other
• What each field does and which field types are in use
• Which formulas, options and configuration settings shape the data
• Where linked records create dependencies between tables
• Which parts of the structure are still operationally relevant

Manually copying this information into a spreadsheet is slow, inconsistent and immediately starts becoming outdated. Screenshots work well for documenting individual automations, but they do not provide a reusable view of the whole data model.

Reading the base through Airtable’s metadata API

I built an Airtable schema exporter that inspects the underlying structure of a base through Airtable’s metadata API. Instead of transcribing the Studio interface, it retrieves the technical definitions directly from the platform.

The exporter captures:

• Tables and their internal identifiers
• Fields, types and descriptions
• Formula definitions
• Select choices and other field configuration options
• Linked-record relationships between tables
• Relevant field settings and identifiers needed for further technical work

Where Airtable returns internal field identifiers, the tool resolves them into readable names where possible. The result is documentation that can be understood without continually referring back to the live base.

Two outputs for two kinds of work

The exporter produces complementary formats rather than trying to make one file serve every audience.

It can also generate a Mermaid entity-relationship diagram. On a large or untidy base, the diagram is a starting point rather than a finished architecture document, but it gives technical and non-technical reviewers an immediate view of how the tables connect.

Built as a repeatable utility, not a one-off script

The exporter was packaged as a reusable application rather than left as project-specific code. Exports are timestamped and repeatable, allowing the structure to be captured again later and compared across different stages of a project.

That matters because discovery documentation should not become another static artefact that drifts away from the system it describes. The tool can be rerun before a review, after a clean-up exercise or immediately before migration work begins.

Turning discovery into a technical process

The exporter changes Airtable discovery from a manual transcription exercise into a repeatable technical process. It creates a portable record of the system’s structure that can support:

• Documentation and handover
• Architecture reviews and data-model normalisation
• Migration planning and implementation discovery
• Backup validation and technical due diligence
• Identifying obsolete fields, hidden dependencies and accumulated complexity

What has this organisation actually built, and which parts of it need to survive?

That is a more useful starting point than choosing a replacement CRM first and attempting to force an undocumented operational system into it afterwards.

What this demonstrates