NI Software Licensing Costs in 2026 (LabVIEW, TestStand, VeriStand)

The NI software stack is priced per product, per seat, per year, with separate deployment licences for stations that run tests but do not develop them. No single product looks unreasonable. The total does, because most teams budget the pieces and never add them up.

This post breaks down each product, explains the four line items that quotes routinely omit, and works through what a realistic four-station lab pays annually.

A caveat on numbers

NI does not publish a complete public price list, pricing varies by region and by negotiated agreement, and the subscription transition changed the shape of the bill. Every figure below is an order of magnitude drawn from typical quotes, not a quotation.

Get your own numbers in writing, and get them including deployment. The point of this post is the structure of the bill, which is stable, rather than the exact digits, which are not.

Per-product breakdown

Full detail on the LabVIEW tiers specifically is in LabVIEW pricing.

The four line items quotes leave out

1. Deployment licences

The big one. TestStand and VeriStand require a licence on every station that runs a sequence, separate from the development seat that wrote it.

A team with two TestStand developers and twelve production stations is not paying for two licences. It is paying for two development seats plus twelve deployment licences, and the deployment licences are the larger number.

This scales with your success. Every new test station adds cost forever.

2. Add-on modules that are not optional in practice

LabVIEW Base does not include the Application Builder, so you cannot ship an executable. Vision requires LabVIEW. FPGA requires LabVIEW plus the compilation toolchain. Real-Time requires LabVIEW.

The tier you were quoted is frequently one below the tier you need, and the discovery happens after the purchase order.

3. Hardware driver support tied to the agreement

Driver updates and new hardware support arrive through the active subscription. Let it lapse, and a new instrument or a Windows update becomes a problem you cannot fix without renewing.

4. The version treadmill

A VI saved in a newer LabVIEW cannot be opened in an older one. When one engineer upgrades, everyone upgrades. This makes partial renewal impractical and is a deliberate property of the licensing model.

A worked example

A modest validation lab: three engineers, four test stations, bench characterisation plus a small HIL rig.

Hardware, calibration, and support contracts sit on top and are not in that figure.

Two observations. First, deployment is $12,000 of it, and it grows every time the lab adds a station. Second, three of those six lines exist to do work that is not real-time and not graphical: sequencing instruments and producing reports.

Where the savings actually are

In order of return, based on what tends to be true rather than what sounds dramatic.

1. Audit tiers against actual use

The most common finding is Professional seats doing Full-tier work. Ask each engineer what they used in the last quarter that Full does not include. If the answer is "the Application Builder, twice", that is one Professional seat for the team, not three.

Typical saving: 10 to 25 percent, and it requires no tool change.

2. Audit deployment licences against running stations

Labs accumulate stations. Some have not run a sequence in a year. Deployment licences renew regardless.

Walk the lab with the licence list. Every station that has not run in six months is a candidate.

Typical saving: 5 to 20 percent of the deployment line.

3. Move bench validation off real-time products

The pattern from NI VeriStand alternatives: VeriStand bought for a genuine HIL programme, then used for ordinary bench work because it is installed. Bench work does not need deterministic loops and should not be on a real-time licence.

Typical saving: an entire deployment licence per station moved.

4. Replace the sequencing layer

TestStand's job is running steps in order, handling limits, and logging results. OpenTAP does that for free. So does pytest, for teams comfortable in Python. So does TestFlow, with the sequence generated rather than written.

This is the largest single line after LabVIEW itself, and it is the one with the most viable free alternatives.

5. Replace the reporting layer

DIAdem exists to turn logged data into a document. Python with npTDMS and reportlab does that for free, and TDMS files remain readable without any NI software, so your history is not hostage.

What not to cut

Being fair about it:

• •LabVIEW FPGA. No free equivalent. If you compile to FPGA, keep it.
• •Real-time targets with genuine determinism requirements. See the boundary discussion in LabVIEW FPGA and real-time.
• •Certified or regulated applications where requalification costs more than the licence.
• •The last development seat. Keep one, so you can still open the archive.

How to run the audit

1. 1

   List every licence you hold, with tier and renewal date. Procurement has this, engineering usually does not.

2. 2

   List every station and what it ran in the last six months. Walk the lab.

3. 3

   Cross-reference. Unmatched licences are the immediate saving.

4. 4

   For each remaining station, write the actual requirement: loop rate, determinism, instrument list, whether a model runs.

5. 5

   Sort stations into keep, downgrade, and migrate.

6. 6

   Act before the renewal date. This is the whole game. Subscriptions renew silently and a decision made in month two of a twelve-month term saves nothing until month twelve.

What changes at renewal, and when to start

Subscriptions renew silently. The single most expensive mistake in NI licensing is discovering a saving in month eleven of a twelve-month term.

A workable calendar:

Four months is the minimum lead time if a migration is involved, because the parallel-running period alone is typically four to six weeks.

The question that reframes the whole bill

For each licence, ask: what would break tomorrow if this stopped working?

The answers sort quickly into three groups.

• •Production would stop. Keep it, and stop debating.
• •An engineer would be inconvenienced for a week. Candidate for downgrade or a free alternative.
• •Nobody would notice. This group is always larger than expected and is pure saving.

Doing this exercise per licence, with the engineer who uses it in the room, produces a more accurate picture in an afternoon than any procurement spreadsheet. It also surfaces the licences nobody can attribute to anyone, which are usually the first cut.

Comparing quotes between sites

Large organisations routinely discover that two sites pay materially different prices for the same products. This is normal in quote-based licensing and it is negotiable.

Before a renewal, gather from each site: the product list, the tier, the seat count, the deployment count, and the annual figure. Normalise to cost per seat per product. The spread is often 20 to 40 percent.

That comparison is the strongest position you can walk into a renewal with, because it is a factual internal benchmark rather than an opinion about value. Consolidating onto a single agreement across sites is usually where the largest single saving in the whole exercise comes from, and it requires no technical change at all.

The five-year number, which is the one that matters

Annual figures make subscriptions look small and migrations look expensive. Over the horizon a validation lab actually plans on, the ordering changes. A worked model for a five-engineer team with eight stations:

The third column is worse in year one and better from year two, which is exactly why it never gets approved in a year-one budget conversation and always looks obvious in hindsight. If you present it, present five years.

Two things to model honestly rather than assume. Annual uplift on renewals is real and compounds, so ask what it has been on your account for the last three cycles rather than assuming zero. And migration effort is not a one-off if you keep adding stations, because every new station on the new stack is cheap and every new station on the old one carries a licence.

Negotiating the renewal

The bill is more negotiable than the price list suggests, and the leverage is specificity.

• •Arrive with the station-to-licence mapping. Not the count, the mapping. "These four deployment licences map to stations that have not run since March" is a different conversation from "can we have a discount".
• •Ask for the tier split in writing. Which seats are Professional, which are Full, and what each one is entitled to. Teams routinely find they are paying Professional prices for Full-tier work.
• •Get multi-year and single-year quoted separately. Multi-year locks the uplift, which is worth something, but only if you are confident the estate is not shrinking.
• •Ask what a support-only tier costs for stations running one frozen sequence with nobody developing on them.
• •Time the conversation. Deployment licences are annual and the saving lands only if notice is given before the renewal date. Start the audit a full quarter ahead.
• •Have a credible alternative. Not as a bluff. A team that has actually ported one station and has the numbers to prove it negotiates differently from one that has not.

Common mistakes when auditing the bill

• •Counting seats and not tiers. The tier split is usually the larger finding.
• •Forgetting deployment licences. They are invisible in the budget and they multiply with stations. This is the most-missed line item, every time.
• •Cutting FPGA or real-time first. They have no free equivalent. Cut the bench half, keep the parts that genuinely need NI.
• •Assuming historical data becomes unreadable. TDMS is a documented format with independent readers. Prove it on your three largest files before letting that fear drive a renewal.
• •Starting the audit a month before renewal. A quarter is the minimum for anything to change this cycle.
• •Pricing the migration as an engineering cost only. Include the parallel-run period and one retained licence for the archive. Both are real and both are cheap insurance.
• •Treating the whole stack as one decision. It is five or six separately priced products, and they have different answers. Acquisition, sequencing, real-time, vision, and reporting each get their own verdict.

Related reading

• •LabVIEW pricing, the tier-by-tier detail
• •LabVIEW alternatives, the options if you are re-platforming
• •NI TestStand alternatives, the sequencing line item
• •NI VeriStand alternatives, the real-time line item
• •NI DIAdem alternatives, the reporting line item
• •NI FlexLogger alternatives, the data-logging line item
• •NI Vision alternatives, the inspection add-on
• •LabWindows/CVI alternatives, the C half of the stack
• •OpenTAP vs TestStand, the free sequencer evaluated properly
• •LabVIEW to Python migration, the effort side of the model
• •Free instrument control software, what the zero-cost stack actually covers
• •LabVIEW FPGA and real-time, the part to keep
• •Test sequencer comparison, the replacements for the sequencing line
• •NI SignalExpress alternatives, the discontinued product still in use