How the model works, and why it says what it says.

Engineer time is a line item, not a footnote

A managed database on a hyperscaler costs more than a server with PostgreSQL on it because someone else patches it, backs it up and answers the page at three in the morning. Move it to a plain server and that work does not disappear; it moves to your team. The calculator prices it at a baseline of 4 hours a month, 0.5 hours per server, and 1, 6 or 16 hours per service depending on how hard it is to run, at $75 an hour loaded. Once a database or a queue is yours, the total never drops below 40 hours: something stateful needs an owner. Above 10 primary servers (standbys do not count) an on-call rotation is assumed, and a stipend of $1,500 a month is added for it.

Those are defaults, not facts about your team. If the work folds into people you already pay, set the rate to what an hour of their time really displaces. If you would hire, turn on the new-hire switch and the rate carries recruiting and overhead. The verdict is honest about small bills for exactly this reason: under a few thousand dollars a month, the engineer time usually outweighs the hardware saving, and the calculator says so.

Whole servers, with a standby

Every instance type in your export becomes the cheapest server at the destination with at least the same cores and memory. Hours are averaged over the period and rounded up to whole machines: a fleet that ran 3.2 servers on average becomes 4, and any fleet of two or more gets one standby so a single failure does not take it down. Databases that ran with a synchronous standby become a pair. Clouds that bill by core-hour and GB-hour rather than by instance type, such as Google Cloud and Oracle Cloud, are packed onto servers at 70% utilisation, with the planner weighing the engineer time per host so it does not pick a swarm of tiny machines.

Storage is priced per gigabyte from the usage lines; outbound traffic is set against the allowance each server includes at the destination, pooled across the fleet, and only the excess is charged. Spot and burstable instances are priced at the full destination price, because there is no spot market to move them to.

The three grades

Every service is graded by how hard it is to leave. Easy means a drop-in exists: object storage with an S3 API, a load balancer, DNS, a container registry. Moderate means the same software exists as open source but you run it: PostgreSQL instead of RDS, Valkey instead of ElastiCache, Prometheus instead of CloudWatch. Hard means there is no equivalent: a proprietary database API, a managed AI service, a workflow engine. Hard services carry the most engineer time and the most migration days, and the report lets you keep any of them where they are, at today’s price, so the rest of the plan stays honest.

The one-off cost of the move follows the same grades: 1, 5 or 15 engineer days per service, plus one day per 5 servers for the servers themselves, at the same hourly rate. The migration plan orders the work into waves so the cheap wins land first.

Where the ratios come from

Servers, storage and traffic are priced from your usage. Everything else is priced by a ratio: what the replacement typically costs as a share of today’s line. Each ratio has a written derivation on the model page, usually a worked comparison of the cloud’s list price against a destination server that does the same job. A ratio is a rule of thumb, and the report marks every figure that rests on one with a tilde. The share of your destination figure that comes from usage rather than ratios is printed on the verdict card, so you can see how much is firm.

What is deliberately left out

Tax, support plans, Marketplace software and credits are set aside before the comparison, because they are the same on either side or not a property of the infrastructure at all. Reserved-instance and savings-plan commitments you still have to pay are not in the steady-state number; neither are setup fees for dedicated servers, the cost of a second region, or the time your own product team spends on a migration rather than on the product. The caveats section of every report lists what applies to your file.

How to read the range

The report gives a single figure and a likely range. The range moves the ratio-priced services by half in either direction, the engineer time between half and double, and the exchange rate by a tenth. If the whole range is on one side of zero the answer is robust; if it straddles zero, the decision depends on assumptions you should go and check, starting with the hourly rate and the hours per service.

When the answer is “stay”

It often is, and the calculator will say so rather than soften it. The usual reasons: a bill too small for the fixed engineer time, a stack built around hard services, or a team that cannot own a database. The useful next question is then not “whether” but “which part”: storage and egress nearly always pay off on their own, and the first wave of the plan prices exactly that.

Four worked examples walk through real file layouts end to end, one per cloud, and every rule above is on the model page with its sources. The destinations are Hetzner, OVHcloud, Scaleway, DigitalOcean, Vultr, Akamai (Linode), Exoscale, UpCloud, Hetzner (US); their list prices are linked and dated on every report.