Database migration done with zero data loss and a tested cutover plan
MS Access → SQL Server or PostgreSQL · on-prem → Azure SQL or AWS RDS · MySQL → PostgreSQL · legacy modernisation. Validated row-by-row, parallel-run before cutover, tested rollback runbook ready. Fixed-price. Code & schema are yours.
- Parallel-run validated — not a "go live and see" cutover
- Row-by-row reconciliation reports · zero silent loss
- Tested rollback runbook — the reversible kind of cutover
- Lowest prices Fixed cost · no monthly SaaS bills · founder-led overhead
- High quality Sandbox-first · weekly demos · reconciled pre-launch
- Fast delivery Quote in 48 hours · live in weeks, not months
- Latest tech Latest APIs · v2 REST native · you own the code
- Xero
- HubSpot
- Salesforce
- Stripe
- Square
- Shopify
- WooCommerce
- Power BI
- Deputy
- ServiceM8
- Simpro
Real benefits, by solving real migration problems.
- Zero Data LossMigrations that leave rows behind · silent FK breaks · orphaned children
- Validated Pre-Cutover"Go live and see" cutovers · 2am rollback panics · weekend write-offs
- App + DB TogetherDatabase moved, application still pointing at the old schema or server
- No Multi-Day DowntimeBig-bang weekend migrations forcing 30+ hours of business offline
- Reversible RollbackNo tested rollback plan when something breaks at hour 18 of cutover
Six database migration capabilities
From the first row-count reconciliation, through the parallel-run weeks where the new database is updated daily from production, to the cutover window with the rollback runbook printed on the wall — built by engineers who treat data loss as a deal-breaker, not a sprint task.
-
Engine-to-Engine Migration
MS Access → SQL Server or PostgreSQL. MySQL/MariaDB → PostgreSQL. SQL Server → Azure SQL Managed Instance. Sybase / Oracle / Firebird → modern relational. Schema mapped, types translated, identity columns preserved.
- Access → SQL Server / PostgreSQL
- MySQL → PostgreSQL · Aurora
- Sybase · Oracle · Firebird
-
On-Prem → Cloud Migration
On-prem SQL Server → Azure SQL Managed Instance / AWS RDS. PostgreSQL → Aurora / Supabase / Neon. Lift-and-shift, re-platform or re-architect — we recommend the path that fits your downtime tolerance and budget.
- SQL Server → Azure SQL · MI
- On-prem Postgres → Aurora · Supabase
- Lift-shift vs re-platform vs re-arch
-
Legacy Database Modernisation
SQL Server 2008/2012/2016 → 2022 or Azure. MySQL 5.x → 8.x. Old MS Access front-end retired, schema rebuilt in a modern engine, application brought along to a current stack — without losing 15 years of business data or reporting.
- Engine + OS upgrade paths
- Access front-end retirement
- Reporting + ETL preserved
-
Data Migration & Validation
ETL pipelines extracting from source, transforming for the target schema, loading with referential integrity preserved. Row-by-row reconciliation reports — every record accounted for. Reruns are idempotent so the cutover migration is the same code as the test runs.
- Idempotent ETL pipelines
- Row-by-row reconciliation
- FK / constraint validation
-
Application Cutover
Connection-string rotation, ORM mapping updates, stored-procedure rewrites where the target engine's dialect differs. Application code changes shipped with the data migration so the app works the moment the DB is live — no surprise refactor at hour 14.
- Connection-string rotation
- ORM / DAL refactor
- T-SQL → PL/pgSQL rewrites
-
Backup, DR & Rollback
Tested rollback runbook before cutover begins. Parallel-run window where old and new run side-by-side. Gradual cutover by tenant / workload where the architecture allows it. Post-cutover backup and DR strategy in place on day one.
- Tested rollback runbook
- Parallel-run cutover window
- Day-one backup & DR
A database migration project, end to end
Three stages. Idempotent scripts so test runs and production cutover use the same code. Rollback runbook tested before cutover begins. Delivered personally by the founder.
-
Week 0
Migration Assessment
15-minute scoping call. We map source engine + version + size, target engine, dependent applications, downtime tolerance, compliance posture and rollback requirements. Fixed-price quote inside 48 hours.
-
Weeks 1–N
Build & Parallel-Run
Migration scripts built idempotently — the same ETL runs against a dev copy, then UAT, then production. Row-by-row reconciliation reports at each run. Parallel-run period where the new DB is loaded from production data daily and tested against the live app.
-
Cutover
Live Cutover & Support
Cutover on a planned window with tested rollback runbook ready. Application connection-string rotation, DNS update, smoke tests. 30 days of post-cutover support included by default — the period when surprises usually surface.
Before you book the scoping call
How much do database migration services cost?
Fixed-price after a 15-minute scoping call and a short discovery session. A focused single-engine migration (MS Access → SQL Server with one app, < 50 tables) takes 4–8 weeks. A mid-size on-prem-to-cloud migration with app refactor takes 8–14 weeks. A multi-database, multi-app, parallel-run-with-tenant-by-tenant cutover takes 4–8 months. You know the price before the first script runs.
How long does a database migration take?
Small (single DB, single app, ≤ 50 tables): 4–8 weeks. Mid (multi-app, ~200 tables, on-prem to cloud, app refactor): 8–14 weeks. Large (multi-tenant SaaS, parallel-run cutover, downtime SLAs): 4–8 months. We build the migration scripts to be runnable in under an hour for the final cutover — long migration windows are a code-quality smell, not a destiny.
How much downtime will we have during cutover?
Depends on your data volume, source engine and downtime tolerance. Typical: 30 min – 2 hours for sub-100 GB databases with a planned weekend window. We design for short windows by doing the bulk of the migration during parallel-run (delta-syncing nightly), then a final small delta + DNS flip at cutover. For zero-downtime cases (multi-tenant SaaS) we do tenant-by-tenant cutovers.
Which source engines can you migrate from?
MS Access (.accdb / .mdb), SQL Server (all versions back to 2008), MySQL / MariaDB, PostgreSQL, Oracle, Sybase, Firebird, IBM DB2, plus flat sources (Excel, CSV, MS Visual FoxPro, dBase). Vendor-locked product databases (Attaché, MYOB AccountRight, SAP B1) handled where vendor APIs or DB-level access exists.
Which target engines do you migrate to?
Microsoft SQL Server (on-prem, Azure SQL DB, Azure SQL Managed Instance), PostgreSQL (Aurora, Supabase, Neon, GCP Cloud SQL, on-prem), MySQL / MariaDB, plus modern alternatives where they fit (SQLite for embedded, DuckDB for analytics, Snowflake / BigQuery for warehousing). We pick the target that fits your team and licensing, not the one we want to bill for.
Cloud or on-prem destination?
Default cloud (Azure SQL Managed Instance, AWS RDS, Aurora) — it ends up cheaper and more reliable once you account for backup, DR, patching and 24/7 on-call. We deploy to your AWS / Azure account; the cloud bill is yours. On-prem still makes sense for some data-sovereignty, latency or cost cases and we build for it when it's the right answer.
Will our application code need to change?
Usually yes — and that's part of the project. Connection strings always change. ORM / DAL mappings may change if column types or stored-procedure dialect differs. T-SQL → PL/pgSQL rewrites are common when migrating SQL Server → PostgreSQL. We do this work in lockstep with the DB migration so the app works the moment the new database is live.
What happens if the cutover goes wrong? Rollback?
Tested rollback runbook before cutover begins — the old database stays alive (read-only) during cutover, DNS / connection-string flip is reversible, application binaries roll back. We've never had to use the runbook on a project where the parallel-run reconciliation passed, but it exists and we rehearse it. Code, schema and data are yours throughout — hosted in your GitHub or Azure DevOps from day one.
Best value · quote in 48 hours · code is yours · zero obligation
