Back to all use cases

AssessmentSoftware / Digital Platforms

Deciding whether to pay for Extended Support or to upgrade, with the numbers on one page

SaaS Platform Team

A typical assessment engagement: a team on Amazon RDS and Aurora MySQL 8.0 compares the Extended Support charge with an upgrade plan to MySQL 8.4 LTS, using its own instance count and the live price list.

Overview

A typical engagement starts when a SaaS platform team finds that its RDS for MySQL 8.0 instances moved into paid Extended Support on 1 August 2026, and that its Aurora MySQL clusters will follow on a calendar of their own. The question from finance is whether to keep paying or to upgrade, and nobody has put the two on one page.

Challenge

AWS bills RDS Extended Support per vCPU-hour, with a rate that depends on the version, the Region and the years since standard support ended. It applies to Multi-AZ standbys and read replicas, not only primaries, and Reserved Instance discounts do not reduce it. The charge also rises with the years in Extended Support, so waiting gets dearer. Against that, an upgrade to 8.4 has its own cost: the MySQL Upgrade Checker findings, accounts that still use mysql_native_password, scripts that use removed replication statements, and application testing.

Environment

A fleet of RDS for MySQL instances and Aurora MySQL clusters across several accounts and Regions, with replicas, a mix of 5.7 and 8.0 engine versions, and applications owned by several teams.

Approach

AceMQ engineers lead a read-only assessment with partner MySQL specialists. They inventory every instance, replica and cluster, read AWS's current calendars and price list for the versions in use, and run MySQL Shell's Upgrade Checker Utility against restored copies. They then price the cost of staying, per instance and in total on the day of the review, against the work of upgrading, and name any instance where staying is the better call.

Solution

  1. Inventory of engines, versions, instance classes, replicas and Multi-AZ standbys across accounts and Regions
  2. Extended Support start and end dates per version from the AWS RDS and Aurora calendars, and the pricing years that apply
  3. Cost of staying per instance and in total, from the AWS price list on the day, without assumed discounts
  4. Upgrade Checker Utility run on restored copies, with findings ranked by what would stop the upgrade
  5. Application and driver review for the 8.4 changes, including authentication plugins and removed statements
  6. Upgrade order, rollback design and a decision per instance: upgrade now, upgrade by a stated date, or stay with reasons

Outcome

The engagement delivers one document that sets the cost of staying against the work of upgrading, instance by instance, a ranked list of the changes each application needs, an upgrade order with a tested rollback, and a written decision for every instance. It quotes no savings figure in advance: the numbers come from the customer's fleet and AWS's price list on the day.

Technologies

MySQLAmazon RDSAmazon AuroraMySQL 8.4

Related Reading

Ready for a MySQL Health Check?

AceMQ's senior MySQL engineers have handled this exact type of engagement before. Whether you need architectural guidance, hands-on remediation, or an ongoing managed partnership, we're ready to help.