# What moving off Retool involves > What we learned moving three operations systems from Retool to custom code: the data model, screens, workflows and cut-over, and the signs it is time to move. - Author: Pranav Mahaveer, Founder, SBD - Published: 2026-10-29 - Updated: 2026-10-29 - Canonical: https://smallbaydigital.com/blog/moving-off-retool/ - Contact: hello@smallbaydigital.com Retool is one of the fastest ways to put an operations tool in front of a team. We have built on it for years and still recommend it. We have also moved three systems off it in 2026: a building materials order system, a marketplace price tracker and a factory operations tool. None of the moves happened because Retool failed. Each system had grown into something the business depended on, and the way it was built no longer fitted. > **The short answer.** Moving off Retool is mostly a data and logic problem, not a screens problem. If the data already lives in a database you own, the move is a rebuild of screens and workflows plus a careful cut-over. If the data lives in Retool's own database and the rules live in dozens of queries, the first and largest job is pulling both out into a schema and code you can test. ## The signs it was time In each case the trigger was a pile of small problems: - **Logic nobody could review.** Business rules lived across many queries and JavaScript transformers. Changing a price rule meant finding every place it was repeated. - **Workflows that had quietly stopped.** In the order system, the workflow that turned website enquiries into records had been switched off and, when it did run, filled every quantity with 100 and placeholder prices, with nothing set up to alert anyone. - **Secrets in the wrong place.** In two of the three systems, API keys or a proxy password were written into queries or scripts in plain text. - **A spreadsheet still in the middle.** The price tracker read its product master from a Google Sheet, so the master record was a file anyone could edit. - **Outside users and more staff.** As more people needed access, per-user cost and permission rules both became harder. If three of those sound familiar, it is worth costing a move. If one does, fix that one thing in Retool. ## Part 1: the data model This is where most of the time goes, and it decides how hard everything after it will be. We start by listing every table, column and relationship the Retool app uses, including the ones only a query knows about. Then we write a Postgres schema on Supabase that says out loud what was implicit: keys, foreign keys, required fields, allowed values. The order system's schema is written as one SQL file that creates every table and turns on row level security on first connection, so the database refuses access by default rather than by convention. Two habits make the rest of the move safe: - **Copy, do not cut.** A one-way sync copies the Retool database into Supabase on demand, so the new system can be built and tested against real shapes of data while the old one keeps running. - **Seed a demo database.** Both the order system and the price tracker run locally with an embedded Postgres and realistic sample data when no database is configured. Engineers and reviewers do not need production data to work on them. ## Part 2: the screens Screens are the visible part and the easiest to estimate, because Retool has already shown what the team needs. We rebuild them as a React app, page for page at first, then fix what the team has worked around for months: bulk edits, imports with a preview step, a command palette, split views for people who live in the tool all day. The rule we hold to is parity before improvement. Every task the team did in Retool must be possible on day one in the new system, written as a checklist and ticked off with the people who do it. ## Part 3: the workflows Retool workflows become scheduled jobs and API routes. In the price tracker, eight Retool workflows became a queue: runs split into batches, each batch locked while it is processed, retried on failure, and recorded in a run history the team can see. Breach reports that someone used to assemble are generated from the results. Each job gets the same treatment: idempotent writes so a retry never duplicates a record, an alert when a job fails or goes quiet, and secrets moved into the host's environment settings, rotated as part of the move. ## Part 4: the cut-over We keep the old system read-only rather than deleting it, run the final data sync, switch users over in one step, and watch the first full working days closely. An audit log on every table, with a restore button, means a mistake in week one can be reversed from the log. ## What it does not cost It does not cost the data, if the data is in a database you own. It does not cost the team's habits, if parity comes first. And it does not have to be all at once: the order system kept its accounting integration and WhatsApp messages working throughout, because those were rebuilt and tested against the copied data before the switch. ## When to stay on Retool Stay if a small team uses the tool, the logic is simple, nobody outside the company logs in, and the per-user bill is comfortably below what an engineer would cost to maintain code. Keep your data in a database you own, keep secrets out of queries, and alert on every workflow. Then a move, if it ever comes, is mostly a rebuild of screens. Read more: [Retool or custom code for your internal tool?](/compare/retool-vs-custom-code/), the [marketplace price tracker](/portfolio/marketplace-price-tracker/) and the [building materials order system](/portfolio/building-materials-order-system/).