A team moves its reporting engine off a managed tier onto plain rented machines - which duties does that hand back?

## What the managed tier was actually selling A managed tier is usually described as a product, but what you were buying was **work you did not have to do**. That is why the invoice is the wrong place to look when you cost the exit: the line item disappears, and the work reappears somewhere that has no line item at all. The engine itself is not the difference. Run the same engine on a machine you rent and it parses the same queries, produces the same plans and writes the same structures to disk. The difference is entirely in the **duties**. ## The duties that come back | Duty | On the managed tier | After the move | |---|---|---| | Guest operating system patching | performed under a maintenance window | yours, including the reboot that applies it | | Engine minor versions and end of support | offered, scheduled, sometimes forced | yours to track, test and apply | | Standby replica and failover | built in, promotion automatic | yours to build, run and rehearse | | Backups and retention | configured once, taken for you | yours to schedule, store and expire | | Restore | offered as point-in-time restore | yours to perform and, first, to prove | | Capacity and sizing | a size class you select | machines, disks and headroom you plan | | Engine health monitoring | surfaced as service metrics | yours to instrument and alert on | | Being woken up | the provider's staff | your rota | ## The three duties discovered late 1. **A proven restore.** A backup job that runs is not a restore that works. The tier used to prove this by offering point-in-time restore as an action anyone could take. Self-running means somebody must restore onto fresh machines, time it, and compare that measured time against the recovery time objective the business already believes it has. Note the direction here: a standby replica is not a backup. Replication copies a deletion faithfully and protects against losing a failure domain; only a retained backup protects against a mistake. 2. **Failover promotion.** The engine can replicate - that capability is the engine's and it comes with you. What does **not** come with you is the thing the tier was doing around it: detecting that the primary is unhealthy, deciding that it is not a transient blip, promoting the standby, and moving clients onto the new primary. That is a system you now build, and a drill you now run. 3. **Version end of support.** On the tier, an upstream release going out of support usually arrived as a notice and a scheduled window - irritating, but somebody else's calendar. Self-running, nothing arrives. The version quietly ages until a security advisory forces an upgrade you have never rehearsed. ## Where the responsibility line now sits Self-running is not unmanaged. The provider still owns the building, the power, the physical hardware, the hypervisor and the network fabric; it still replaces a failed disk in a host. What moves is the boundary: on a managed tier the provider's duty reached up into the engine, and on a rented machine it stops at the hypervisor. **Everything above that line is yours**, including the parts nobody enumerated because they were never visible: the guest operating system's packages, its kernel updates, the clock, the file system layout, the process supervision, and the access control on the machine itself. ## What the move buys Be explicit about the other side of the trade, because a migration argued only in duties sounds like pure loss: - **Host access while diagnosing.** The thing an incident-shaped team misses most on a managed tier is the ability to look, rather than to open a support case and wait. - **Tuning knobs and extensions the tier disabled.** Managed tiers withhold settings that could destabilise a fleet; self-running returns them, with the risk that motivated withholding them. - **The version you choose**, on your schedule, rather than the versions the tier offers. - **No ceiling set by a size class.** This is usually why you are here in the first place. ## How to answer this in an interview Enumerate the duties rather than gesturing at "more ops work", and make the enumeration concrete: who patches, who is paged, who proves the restore, who promotes the standby. Then say the honest sentence that separates a senior answer from a confident one - the engine is unchanged, so no query gets faster by leaving; what changes is the operating burden and the ceiling. If you are asked what you would do first, say: rehearse a restore onto fresh machines and measure it, because that is the duty that is easiest to believe you already have and hardest to discover you do not.