Asana to Airtable migration: 8 projects moved into a cleaner shared operating system

The Problem

One team was in Airtable, everyone else was in Asana. The Asana setup had become a task layer rather than an operations system. Work was moving, but the structure was not keeping up with how the teams actually collaborated.

The delivery model was cross-functional. Projects involved different combinations of writers, external freelancers, graphic designers, account managers, and in-house team members. That meant each project needed more than a simple task list: the team needed ownership, dates, dependencies, forms, approvals, content stages, and delivery status across groups of people who worked interchangeably.

The manual work was coming from the split system. Because Airtable and Asana were both in use, the same information was being filled in more than once. Forms were repeated between systems, updates had to be copied by hand, Slack handoffs needed repair, and people were spending time maintaining tool alignment instead of moving the work forward.

The Initial Request

The engagement started as a migration project: move 8 projects from Asana into Airtable. Each project had its own level of complexity, team mix, and workflow shape. Some were closer to straightforward task migration. Others needed more careful restructuring because of dependencies, repeated forms, cross-team ownership, or project-specific delivery stages.

The goal was not to copy Asana into Airtable. It was to move the work into a structure the team could actually scale.

That distinction mattered. A direct import would have produced another disconnected layer: tasks in Airtable, existing Airtable data somewhere else, and the same manual work returning a few months later. The migration needed to become part of the client's wider operating setup, not a separate base for a separate team.

The Turning Point

Halfway through, the right answer changed. It became clear that simply adding a new base for the Asana team would create a bigger problem. The existing Airtable setup was already fragmented. If the new team moved into a separate base, the client would soon have two systems with overlapping people, projects, statuses, and reporting needs.

The teams were working too closely and interchangeably to justify a split. A separate base would have made reporting harder, duplicated automations, and created another place where the same operational data had to be maintained.

I changed the approach: before bringing the Asana projects across, I consolidated the existing Airtable setup so it could become the shared operating layer for both teams.

The Solution

The existing Airtable base was simplified from 8 tables down to 2 core tables. That consolidation removed unnecessary separation, made the data model easier to understand, and reduced the number of automations needed to keep the workflow moving.

Once the structure was cleaner, the Asana projects could be migrated into the same system instead of creating a parallel setup. That meant the client ended with one shared base for closely connected teams, not a new silo beside the old one.

Before and After

This is the kind of decision that matters in an Asana to Airtable migration. The best answer is not always another base. Sometimes the highest-value work is reducing the structure before adding more to it.

What Changed in the Airtable System

This part of the project mattered as much as the migration itself. The client needed the system to become easier to use for skimmers, managers, and delivery staff — not just technically cleaner under the hood.

• Consolidated data structure: The base moved from 8 tables to 2 core tables, reducing fragmentation and making the workflow easier to maintain.
• One shared system for connected teams: The new team was brought into the same base because the teams worked closely and interchangeably.
• Interfaces instead of raw data work: The team had been working directly from the data layer, so I introduced Airtable Interfaces for focused role-based work.
• Date dependencies and hierarchy: Projects were structured with date dependencies, grouped views, tree-style hierarchy, and clearer delivery relationships.
• Dashboard and visibility: Dashboards gave account managers and delivery leads better visibility without inspecting every task record manually.
• Cleaner forms and fewer repeated updates: Repeated form filling between Asana and Airtable was replaced with cleaner Airtable intake and confirmation forms inside the shared workflow.
• Slack integration fixed: Existing Slack handoffs were repaired so workflow updates could land in the right place instead of depending on manual checking.
• Loom training videos: I recorded Loom walkthroughs so the team could understand the new Airtable setup, interfaces, views, forms, and day-to-day operating flow after handover.

The Migration Work

The Result

The 12-week migration project was completed successfully through Optimize. What started as a move from Asana to Airtable became a wider operating-system improvement: fewer tables, fewer automations, less duplicated admin, fixed Slack handoffs, Loom-based training, and a shared base that could support both the existing Airtable team and the newly migrated team.

The important outcome was not just that Asana projects were moved. The client avoided creating a second Airtable silo and ended with a cleaner system that matched how the teams actually worked together.