Pre-upgrade checks
Upgrade prechecks run against a clone of your data: deprecated syntax, incompatible character sets, orphaned objects, and anything the new version rejects — found before cutover, not during it.
← All services
Fixed price · Fixed scope
Zero-Downtime Database Upgrade
Version upgrades get postponed until AWS forces the issue and the bill arrives. We do them properly: rehearse on a clone, cut over with Blue/Green in seconds, and keep a rollback ready the whole way.
- Starts
- Within a week
- Scope
- Fixed, in writing
- Rollback plan
- On every change
Three production RDS MySQL databases upgraded from 8.0 to 8.4 LTS for a US healthcare platform ahead of the Extended Support deadline, with a rollback runbook for each.
This is for you if
- You are paying — or about to pay — RDS Extended Support fees
- Your database version is approaching end of standard support
- A previous upgrade attempt failed and nobody wants to try again
- You cannot take the multi-hour maintenance window a plain upgrade needs
What we do
What the $3,000 covers
Application compatibility
We review your ORM and query patterns against the new version's behaviour changes, and flag what your team needs to test.
Full rehearsal
The entire upgrade runs end to end on a restored snapshot first. The cutover you approve is the second time we have done it, not the first.
Blue/Green cutover
A green environment at the new version runs in sync with production, then swaps in seconds. Typical switchover is under a minute of writes paused, not a maintenance window.
Rollback and watch
The old version stays available for an agreed period. We monitor query performance, errors and replication for 48 hours after cutover.
What you get
- Upgraded database on a supported version, with Extended Support charges ended
- Written runbook: every step, every command, every rollback trigger
- Precheck report of what we found and fixed before cutover
- Post-upgrade performance comparison against the old version
- 48 hours of monitoring after cutover, included
Not included
- Rewriting application queries that the new version rejects (we identify them; your team or ours fixes them, quoted separately)
- Engine changes, such as MySQL to PostgreSQL
- Self-managed databases on EC2, which we quote case by case
Anything outside this list is quoted before we start it, never invoiced afterwards.
Timeline
How it runs, start to finish
Day 1 — assess
Clone your database, run prechecks, and report what blocks the upgrade. If something serious turns up, you hear it on day 1.
Days 2–3 — rehearse
The full upgrade on the clone, timed and documented. The runbook is written from what actually happened, not from the AWS docs.
Day 4 — cutover
Blue/Green switchover in a window you pick, with your team on the call and rollback ready.
Days 5–7 — watch
Query performance, error rates and replication monitored. The old environment stays until you are comfortable.
Questions we always get
What does 'zero downtime' actually mean?
Writes pause for the length of the Blue/Green switchover, typically under a minute. Reads continue. It is not literally zero, and we would rather say so than surprise you.
What if the cutover goes wrong?
We roll back to the blue environment, which is still running and still current. That is the point of the pattern, and the rollback is rehearsed too.
We have five databases. Is it $15,000?
No. The first database carries the discovery work; additional databases in the same account are discounted. Tell us how many and we will price the set.
Start your Database Upgrade
Book a 20-minute call. Bring your AWS account, your compliance dashboard or your database version, and we will tell you what we would do and what it costs — on the call, not in a proposal two weeks later.
See the case studies behind this work →