Methodology

How the numbers are built · pricing reviewed May 2026

OffVendor exists to make one question answerable: if we move off Product A onto Product B, what does it cost, how long does it take, and how do we do it safely? This page explains exactly how every figure on the site is produced, so you can judge it, edit it, and defend it to a finance team.

The honest disclaimer first

Every cost and sizing number shown on this site is illustrative and fully editable. It is a defensible starting point, not a guaranteed vendor price. Binding pricing only ever comes from an authorized distributor or partner against your specific requirements, which is what the quote request (RFQ) is for. Always validate against current vendor list prices and your own quotes before deciding.

The 3-year TCO model

The calculator compares the source and target products over a three-year horizon, the typical window for an infrastructure decision. For each side it computes:

• Annual licensing/subscription = your sized quantity × an indicative cost per unit. The unit is product-appropriate, CPU core, socket, host, TB protected, user, endpoint, vCPU, or token volume, defined per category.
• Support = an optional tier (Community, Standard, or Premium) added on top, because the "free" open-source target often still carries a paid support contract in production.
• One-time migration effort = a project-cost estimate derived from the effort score (below), shown separately so you can see payback timing, not just steady-state savings.

The three-year total is (annual + support) × 3 + migration for each side, and the headline figure is the difference. Where a move legitimately costs more (for example, on-prem → cloud adoption of steady-state workloads), the model says so rather than inventing a saving.

Per-product sizing

A firewall is not sized like a hypervisor, and a hypervisor is not sized like an LLM endpoint. Each category therefore exposes its own inputs and converts them into billable units:

• Virtualization, physical hosts, sockets, and cores per socket → billable cores (the basis most hypervisors now license on).
• Firewalls / ADC, throughput, TLS/SSL inspection, concurrent sessions, and enabled feature subscriptions → an appliance tier recommendation.
• Databases, cores or vCPUs, with edition multipliers.
• Backup & DR / Storage, TB protected or raw/usable capacity.
• Identity / Monitoring / Endpoint security, users, endpoints, or monitored nodes.
• Cloud & AI, vCPUs/instances, or annualized monthly token volume for LLM workloads.

For appliance-style categories the tool recommends a capacity tier rather than pretending to a per-unit price, because that is how those products are actually bought.

Where the unit costs come from

The default per-unit figures are compiled from public vendor list pricing, published price books, partner price lists, and widely reported street pricing, then rounded to indicative values. They were last reviewed in May 2026. They are deliberately conservative and, again, editable in the UI, change any input and the whole model recomputes live so you can model your reality, not ours.

Migration effort & timeline

Each migration pair gets an effort score combining how locked-in the source is with how much work the target's adoption typically takes. That score drives a plain-English effort label (Low / Medium / High) and an indicative project length in weeks, plus the recommended migration tooling for that path. The phased plan, assessment, target design, pilot, production waves, validation, and decommission, is the same disciplined structure regardless of products; only the steps and tools change.

What we deliberately don't do

• We don't present illustrative figures as binding quotes.
• We don't fabricate distributor names, contacts, vendor logos, or product screenshots.
• We aren't affiliated with the vendors compared here; trademarks belong to their owners.
• We don't hide content behind a login, the analysis is public so you can verify it.

Editorial standards

Every guide, buyer's guide, and alternatives ranking on OffVendor is produced by the OffVendor Editorial Team, independent it-migration analysts. We publish under a team byline rather than invented personas: the people who write and review these guides have run production migrations off commercial platforms, and we would rather be judged on the work than on a fabricated résumé.

• How we research. Guides are built from public vendor documentation, published price books and license terms, release notes, and first-hand experience with the migration tooling named in each path (for example ora2pg, ELevate, AWS DMS, or Proxmox's importer). We do not reproduce vendor marketing as fact.
• Review before publish. No migration page ships as a template word-swap. Each published path carries a hand-written guide that a second reviewer checks for technical accuracy and for the risks and caveats a practitioner would actually flag, before it goes live.
• Independence. We are not affiliated with, sponsored by, or endorsed by any vendor compared here. Advertising and partner referrals fund the site but never shape a comparison, a ranking, or a cost estimate. Trademarks belong to their owners.
• Freshness. Each page shows when it was last reviewed. Pricing defaults carry their own review date (currently May 2026), and we revisit guides when a vendor changes licensing, a tool's support status shifts, or a reader flags something stale.
• Corrections. We fix errors openly. Spotted a mistake or an out-of-date figure? Email [email protected] with the page and what's wrong, and we'll correct it.

How this site is funded

OffVendor is supported by advertising and by connecting interested teams with authorized vendors, distributors, and migration partners. That funding model never changes the analysis, the cost comparison is driven entirely by the inputs and the published unit costs above. See About for more.

Spotted a stale number or a sizing assumption you'd model differently? Tell us at [email protected], corrections improve the defaults for everyone.