Failure PatternDecision layer

The AT Migrator One-Way Cutover Trap: Why Agencies Sell a Migration as a Retainer

Symptom: A client signs a monthly data-ops retainer after go-live, then asks for a field added in Airtable three weeks ago to appear in PostgreSQL, and there is no sync path back or forward. Root cause: AT Migrator is a one-way, one-time migration tool. It does not run as an ongoing sync or managed service, so any retainer priced as recurring data operations has no recurring deliverable behind it.

By InnovaAI ResearchPublished

Data Engineering Tools
How do you recognize it?
  • •A client signs a monthly data-ops retainer after go-live, then asks for a field added in Airtable three weeks ago to appear in PostgreSQL, and there is no sync path back or forward.
  • •The agency's scope document lists 'ongoing Airtable to Postgres sync' but the delivered artifact is a single cutover with a downloadable migration script and no scheduled job.
  • •Post-migration, the client's product team edits a formula in the PostgreSQL view directly, and the next schema comparison against the original Airtable base shows drift the agency cannot reconcile.
  • •Support tickets arrive 48 hours after cutover because the Starter plan's email support window (48h response) does not cover the weekend the client chose for launch.
  • •The agency discovers mid-project that the client's base exceeds the purchased record tier, forcing an upgrade from the $499 Professional plan to the $999 Business plan after the fixed-fee quote was signed.
Why does it happen?
  • •AT Migrator is a one-way, one-time migration tool. It does not run as an ongoing sync or managed service, so any retainer priced as recurring data operations has no recurring deliverable behind it.
  • •The pricing model is one-time by record volume: Starter $199 for 5,000 records, Professional $499 for 25,000 records, Business $999 for 100,000 records. Agencies that quote a flat project fee without first counting records absorb the tier jump themselves.
  • •Formulas, rollups, and lookups are recreated as native SQL views rather than static values. Once the client edits those views, the migration output is no longer a faithful mirror of the Airtable source, and re-running the migration overwrites those edits.
  • •The tool reads Airtable in read-only mode and retains zero data on its own infrastructure, which means the agency, not the vendor, owns every post-cutover data question the client raises.
How do you fix it?
  • •Recount the client's Airtable records before quoting, then map the count to the correct one-time tier ($199, $499, or $999) and price the engagement as a fixed-scope project, not a monthly retainer.
  • •Replace any retainer language in the statement of work with a defined cutover window plus a separate, explicitly priced hypercare period, since AT Migrator itself has no recurring component to bill against.
  • •Run the migration against AT Migrator's published sample bases first (the 48,000+ record CRM and the formula-heavy projects base) to confirm how the client's specific rollups and lookups translate before touching production data.
  • •Freeze the client's Airtable base for the cutover window and document in writing that PostgreSQL views become the system of record at go-live, so later edits are treated as new work rather than migration defects.
  • •Match the support tier to the launch date: if cutover lands on a weekend, buy up to the Business plan's same-day dedicated support rather than relying on the Starter plan's 48-hour email response.
Open the AT Migrator courseAT Migrator decision recordBrowse the Academy

More on AT Migrator

More for Data Engineering Tools