Versioned migrations
Schema changes committed alongside the code that needs them, reviewed in pull requests, and applied in order by a tool that records each run against the environment.
Networking & Data
Database DevOps & Data Migrations
Schema changes reviewed and shipped through the pipeline, with a rollback path that has been tested.
The work
What this actually does
Database changes are the part of delivery that most teams still run by hand, usually late at night, usually with someone watching a terminal. We bring migrations into the same pipeline as application code: versioned, reviewed, ordered, and applied by automation that records what ran and when. The result is that a schema change is a normal pull request rather than an event.
Zero-downtime is a design constraint, not a tool. We use expand-contract patterns so old and new code can run against the same schema during a rollout: add the column, backfill in batches, dual-write where needed, then remove the old field once nothing reads it. Long locks are found and avoided before they take a production table offline.
If any of these sound familiar
- Migrations run by hand at midnight with no dry run
- A deploy locks a large table and the site stops responding
- Nobody knows whether the migration on staging matches production
- Rollback means restoring a backup and losing an hour of data
Scope
What's included
Every engagement on this page covers the following, sized to your setup rather than delivered as a fixed package. If something here is not relevant to you, it comes off the scope and off the price.
Zero-downtime changes
Expand-contract sequencing for column and table changes, batched backfills and online index builds, so a release does not require a maintenance window or an apology.
Pre-merge validation
Migration scripts run against a disposable copy of production-shaped data in the pipeline, where a long lock or a destructive statement fails the build rather than the business.
Replication and failover
Primary and replica topology designed for the read load you actually have, with failover rehearsed, health checks that understand database lag, and a documented promotion procedure.
Read scaling
Read replicas, connection pooling and query review used to take pressure off the primary, which is usually cheaper and less disruptive than a larger instance.
Backup and recovery
Point-in-time recovery, restore rehearsals and a defined recovery point objective, because a migration plan without a tested restore is only half a plan.
What changes
What teams typically see
0Manual migrations at midnight
1 PRReview per schema change
30 secRead replica lag target
Handover
What you keep
Everything produced during the engagement is yours: the repositories, the accounts, the documentation. There is no proprietary layer and nothing to unlicense if you take the work in-house.
- Migration framework wired into the deploy pipeline
- Expand-contract plan for each schema change
- Lock and performance review of migration scripts
- Replication topology and tested failover runbook
- Restore rehearsal results and recovery targets
Tooling
Tools we use here
A starting point, not a requirement. We work in whatever you already run wherever it does the job.
PostgreSQL
MongoDB
Terraform
Kubernetes
Redis
GitLab
AWS
How it runs
From first call to handover
The same four steps on every engagement. You see each one before it starts and can stop at any of them.
- 01
Review the schema and history
We look at current migration tools, how changes reach production and which past changes caused incidents, before recommending anything new.
- 02
Choose the migration tool
Flyway, Liquibase, Alembic, Rails migrations or your framework's own tooling, picked for how it handles ordering, locking and rollback in your stack.
- 03
Make changes safe
Each migration is reviewed for lock duration and reversibility, tested against realistic data volumes, and split into steps that can run while the application is live.
- 04
Rehearse failover and restore
We promote a replica, restore a point-in-time backup and time both, so the recovery targets in your documentation are ones you have actually measured.
Questions
Asked before we start
Can we adopt this without downtime on a large database?
Yes, but the change has to be sequenced rather than applied in one step. Expand-contract, batched backfills and online index builds add elapsed time, often days for very large tables, while keeping the application available throughout.
Do schema changes still need a change advisory board?
That is a policy question rather than a technical one. A reviewed pull request, a tested migration and recorded evidence often satisfy the same requirement more cheaply. Where a formal approval is genuinely needed, the pipeline can pause for it.
What about our ORM's automatic migrations?
They are convenient and fine for development, but auto-generated migrations often produce locks or destructive statements that surprise you in production. We usually keep the ORM and add review, lock checks and a staged rollout around the changes it generates.
How do you handle data migrations, not just schema?
Backfills are written as resumable jobs that run in small batches with throttling, so they can pause under load and restart without repeating work. We monitor replica lag while they run and stop them automatically if it climbs.
Networking & Data
Often needed alongside this
Reliability & Performance
Backup, HA & Disaster Recovery
Tested recovery procedures with documented RTO and RPO — because an untested backup is not a backup.
- Multi-AZ, multi-region and failover design
- Automated backups with restore rehearsals
- Database HA, replication and migration safety
Infrastructure & Cloud
Infrastructure as Code
Your entire cloud estate described in version control — reviewable, reproducible and rebuildable from scratch.
- Terraform, OpenTofu, Pulumi & CloudFormation
- Remote state, workspaces and modular reusability
- Drift detection and policy-checked pull requests
Platform & Containers
Kubernetes & Containers
Production-grade clusters with sane defaults, safe rollouts and an operator experience your team will actually enjoy.
- EKS, AKS, GKE and self-managed clusters
- Helm, Kustomize and GitOps-driven deployments
- Node autoscaling, resource tuning and cost control
Worth a conversation about Database DevOps & Data Migrations?
Bring the specific problem. We will tell you honestly whether this is the service that fixes it, and what it would take.