Migration planning is full of acronyms. Here's what the ones used on this site actually mean — in the context of deciding whether and how to move off a product. For how we turn these into numbers, see the Methodology.
- Vendor lock-in
- The cost and difficulty of leaving a product — proprietary formats, licensing tied to hardware, integrations, or skills — that lets a vendor raise prices with little risk of you switching. Reducing it is the whole point of having an exit plan.
- TCO (Total Cost of Ownership)
- The full 3-year cost of running a product: licensing or subscription, support, and the one-time migration effort to adopt it — not just the sticker price. OffVendor compares TCO between the source and target products.
- Migration path
- A specific 'Product A → Product B' move (for example VMware → Proxmox). Each path has its own cost model, effort estimate, tooling, and step-by-step runbook.
- Source / Target
- The product you are moving off (source) and the product you are moving to (target). The calculator models both sides over three years.
- Sizing unit
- The billable quantity a product is priced on — CPU core, socket, host, TB protected, user, endpoint, vCPU, or token volume. Picking the right unit is what makes a cost comparison fair.
- Billable cores
- For per-core licensing (common in virtualization and databases), the number of physical cores that actually count toward the license after any vendor minimums or core-factor rules are applied.
- Support tier
- An optional paid support contract (Community, Standard, or Premium) layered on top of licensing. Matters most for open-source targets, where the software is free but production support usually is not.
- Migration effort
- An estimate of the one-time work to move a path, expressed as a Low / Medium / High label and an indicative number of weeks. Driven by how locked-in the source is and how involved the target's adoption tends to be.
- Cutover
- The moment you switch production traffic from the source to the target — typically a final data sync, a write freeze on the source, a DNS or load-balancer change, then validation, with the source kept as fallback.
- Rollback
- The pre-planned path back to the source if cutover validation fails. A migration isn't production-ready until the rollback has been rehearsed.
- RPO (Recovery Point Objective)
- The maximum acceptable amount of data loss, measured in time — e.g. 'no more than 15 minutes of data.' It sets how often you must replicate or back up.
- RTO (Recovery Time Objective)
- The maximum acceptable time to restore service after an outage. RPO and RTO together define your resilience target and shape the migration's DR design.
- CDC (Change Data Capture)
- A replication technique that streams ongoing changes from a source database to a target after an initial bulk load, so the two stay in sync until cutover with minimal downtime. Used by tools like AWS DMS and Azure DMS.
- V2V / P2V
- Virtual-to-virtual and physical-to-virtual conversion — moving a workload's disk and configuration from one hypervisor (or bare metal) to another, a core step in virtualization and repatriation migrations.
- Landing zone
- A pre-built, governed foundation in a target cloud — accounts/subscriptions, networking, identity, and guardrails — stood up before any workload is migrated.
- Egress
- The fee cloud providers charge to move data out of their network. Large cross-cloud or cloud → on-prem transfers can incur significant egress, which must be modeled in the migration's business case.
- Repatriation
- Moving workloads from a public cloud back to on-prem or a private cloud — increasingly common when steady-state demand turns out cheaper on owned hardware than on metered cloud.
- Cloud adoption
- Moving on-prem workloads into a public cloud to gain elasticity and managed services, trading capital expense for operating expense. The reverse of repatriation.
- Open-weight model
- A large language model whose weights are publicly available (e.g. Llama, Mistral, DeepSeek), so it can be self-hosted on your own inference stack instead of called through a proprietary per-token API.
- Gateway (LLM/API)
- An OpenAI-compatible proxy in front of one or more models, so applications can switch providers — or fall back instantly — by changing a base URL rather than rewriting code.
- Bridging (messaging)
- Running a temporary replication link between an old and new message broker (e.g. Kafka MirrorMaker 2) so producers and consumers can move across without losing messages.
- RFQ (Request for Quote)
- A structured summary of your requirements — products, sizing, support needs — that you send to an authorized distributor or partner to obtain binding pricing. OffVendor's quote wizard generates one for you.
- Reseller / Distributor / Partner
- The authorized channel that actually sells you a product and provides a binding quote. OffVendor helps you assemble the requirements to take to one; it does not sell licenses itself.
- Illustrative pricing
- Indicative figures compiled from public list prices and street pricing, shown as editable defaults so you can model your own scenario. They are starting points, never guaranteed quotes — see the Methodology page.