A team replatforms a self-managed database onto a managed service in six weeks and the project lands on time. Eighteen months later they are running an unplanned major-version upgrade over a weekend because the provider's standard support for their engine version ends. What did the replatform actually trade away, and when does that bill arrive?

What is gained, quantified

The measurable win is operational toil, and it is real. Patching, backup verification, replica provisioning and failover drills for one self-managed relational cluster consume somewhere around two to five engineer-days a month in a team that does them properly, and considerably more in the quarter after an incident. A managed service absorbs that work and replaces a set of runbooks with an API call. For a six-week project this is the best return per unit of effort in the whole disposition menu, which is why replatforming is usually the right first move.

What is paid: the upgrade calendar changes owner

The bill is not money, it is control of the clock. Self-managed, the team could stay on an old engine version indefinitely. That deferral was never free — it was accruing as an unbudgeted obligation — but it was theirs to schedule, and teams routinely deferred it past three or four planning cycles. Managed database services publish an end-of-standard-support date per major engine version, typically on the order of three to five years from that version's release as of 2025, and after it the provider either charges an extended-support premium or performs the upgrade for you inside a maintenance window you did not choose.

Replatforming converts an indefinitely deferrable obligation into a dated one. That is mostly good, because the obligation existed either way and now it is visible. It is bad on exactly one axis: the date is set by someone whose incentives are not your release calendar.

When the bill arrives

Not at cutover. It arrives at the first major-version boundary, which for a typical estate is somewhere between 18 months and three years after the replatform, and it lands on whichever team inherited the system by then. The symptoms are familiar: a version upgrade that requires an application change nobody scoped, a stored procedure or extension that the next major version dropped, and a rollback path that exists only as a restore from a snapshot.

How to keep the option to reverse

1. Keep the write path inside engine-standard SQL. Provider-only extensions in the write path are the difference between an upgrade and a rewrite.
2. Rehearse on a clone at full data volume, because the upgrade's duration scales with table count and index size and the rehearsal is the only honest estimate you will get.
3. Keep a logical replication route out, tested once a year. It is the difference between "we could move providers" as a belief and as a fact.
4. Put the vendor's published support dates in the same calendar as your own roadmap, so the upgrade competes for capacity a quarter in advance rather than arriving as an incident.

When this is the wrong answer

When the version is contractually pinned, stay self-managed. A certified configuration in a regulated setting, or a vendor application supported only on a named engine release, makes the upgrade calendar a compliance event whose date you must own. Paying for extended support on a managed service to freeze a version is possible and expensive, and at that point the managed service is delivering backups and failover only.

Common weak answers

• "Read the SLA before signing." The SLA covers availability. The support-lifecycle page is a different document and is the one that sets your deadline.
• "Pin the version and negotiate an exception." Exceptions are priced as extended support and renew annually at a premium. It buys a year and moves the same decision.
• "Managed means no operations." It means different operations. The team still owns schema changes, connection budgets, query performance and the upgrade's application impact.