Cloud
Database migrations
Moving data from one database or provider to another: mapping the schema, copying and checking the data, and planning when and how to switch over.
How a migration runs
Map the schema
Work out how the tables, types and relationships in the old system translate to the new one, and what has to change on the way: dates, booleans, text matching, limits.
Change the code
Update the queries and data layer for the new database. Some features change shape; moving to SQLite, for example, means multi-step writes become batches.
Copy and check the data
Repeatable scripts that copy the data, then check the result against the source, as many times as it takes to get a clean run.
Switch over
Decide when to switch, what happens to changes made during the move, and how to switch back if something isn't right.
From our own products
In October 2026 we moved HelloRestaurant and HeySales from a Neon PostgreSQL database to Cloudflare D1, which is SQLite. That meant moving the schema and the data layer for both apps: Prisma in HelloRestaurant, Drizzle in HeySales. Our article on the move covers the rules that caught us out.
The same month, HelloSupermarket's products and prices moved from DynamoDB to D1: a script cleaned the DynamoDB export item by item and wrote the SQL to load it, with a local copy built first for checking.
Read: What changed when we moved two apps from Postgres to Cloudflare D1
Related work
Technologies
Questions
Will the service be down during the move?
We plan the switch so the old and new systems can run side by side until the new one is checked. How long the final switch takes depends on how much data there is and how often it changes.
Which databases have you worked with?
PostgreSQL, SQLite (including Cloudflare D1) and DynamoDB, through Prisma, Drizzle and direct SQL.
Tell us what you're building.
Email us about your project: what it needs to do, who it's for and when you'd like it live.