MySQL and Aurora MySQL · Upgrade review
Plan your database upgrade with the risks in view
You have a version change to plan and a team to carry it out. I review the agreed upgrade question, identify assumptions that need testing, and give your team written findings and validation steps before it commits to production changes.
When an upgrade review helps
This review is for software and product teams with an internal owner for the upgrade. You may have a proposed target version, an outline plan or an unresolved question that needs a specialist second opinion.
- You need to establish what must be checked before choosing an upgrade approach.
- Your team wants an independent review of its proposed sequence and assumptions.
- You need to plan application and query testing around the version change.
- Recovery, cutover or the criteria for proceeding are not yet clear.
The review is scoped around your environment and the decision you need to make. Your team retains responsibility for testing, implementation and production approval.
What a review can look at
We select the areas relevant to the agreed question rather than treating this as an exhaustive certification.
-
Versions and dependencies
The exact current and proposed target versions, the database setup, and the application or operational dependencies that need checking. Identify prerequisites and questions about the proposed upgrade path that remain unresolved.
-
Application and query behaviour
The schema, representative queries, configuration and connection behaviour your team needs to validate. Agree what a useful comparison would look like and where the test evidence is missing.
-
Rehearsal and acceptance checks
The proposed test environment, workload and checks for correctness and performance. Make the criteria for proceeding, pausing or investigating further explicit.
-
Cutover and recovery assumptions
The proposed change sequence, ownership, backup and restore evidence, and the recovery options your plan depends on. Identify what your team needs to rehearse before relying on those options.
What you receive
A written review and technical handover, covering:
- The upgrade question, environment and scope reviewed.
- Assumptions, risks and dependencies, with the evidence supporting each finding.
- Prioritised prerequisites and questions to resolve before proceeding.
- Recommended validation steps for your team's rehearsal and application testing.
- Gaps in the proposed cutover and recovery plan, where those areas are in scope.
- Remaining uncertainties and the decisions your technical owner needs to make.
The review supports your team's upgrade plan. It does not certify that an upgrade is safe or replace testing in your environment.
How the review runs
- Describe the current environment, intended version change and question you need answered.
- Agree the scope, evidence, effort limit, deliverables, fixed fee and schedule in writing.
- Review the material and distinguish established findings from assumptions that still need testing.
- Hand over the written review and walk your technical owner through the recommended checks.
Scope, deliverables, effort limit, fee and schedule are agreed in writing before work begins.
Fixed fee, agreed after a short scope review.
What to share first
In your enquiry, describe the platform, exact current version, proposed target if known, and the decision that is holding up your plan. Say who owns the upgrade and what testing or planning your team has already done. If the target is undecided, say so.
A high-level description is enough at this stage. Do not send credentials, customer data, connection strings, database dumps or sensitive logs. We agree how to share any technical evidence needed for the review.
Related technical work
Testing a MySQL backup by restoring it as a replica is a published lab walkthrough of restoring and checking a backup. It illustrates recovery testing in that lab environment; it is not an Aurora upgrade guide or evidence of a customer upgrade outcome.
For a focused question about restore readiness or recovery, see the Availability & Recovery Review.
Not included
- Running the upgrade, changing production or managing the cutover.
- Running your team's rehearsals, application tests or restore exercises.
- Emergency response, on-call cover or ongoing operational ownership.
- Guaranteed compatibility, downtime, recovery time or performance after the upgrade.
Any implementation or further investigation would require a separate, explicitly agreed scope.
Questions
Can I ask about MySQL 5.7, 8.0 or 8.4, or Aurora MySQL v2 to v3?
Yes. Include the exact current version and proposed target in your enquiry. Suitability and scope are confirmed for that environment. The review considers prerequisites and questions about intermediate steps; naming versions here does not establish a direct upgrade path between them.
Do we need a complete upgrade plan already?
No. You do need a concrete question and an internal owner. The review can examine an existing plan or identify the next decisions and evidence needed to develop one.
Will you perform the upgrade or run the tests?
No. Your team runs the rehearsals, makes the changes and approves production work. The standard review delivers written findings, recommended checks and a technical handover.
Can you guarantee that we can roll back?
No. Recovery options are assumptions to examine and test for the proposed approach. The report identifies what remains unproven; it does not promise that reversing a version change will be possible.
What if we cannot provide enough evidence?
The review states the limits of what can be concluded and the evidence still needed. It does not turn missing test results into an assurance that the upgrade will work.
How are scope, price and timing agreed?
A short fit and scope review leads to a written proposal with the question, environment, evidence requirements, effort limit, deliverables, fixed fee and schedule. Work is scheduled after agreement; this is not emergency or on-call cover.
Have an upgrade decision to review?
Describe your current version, proposed target and the question your team needs to resolve. Include who owns implementation and what has already been tested.