Single Version Charging Explained.

Migrating a major mainframe product is rarely instant. For a stretch of time the old version and the new version run in parallel, while you validate, cut over by workload, and retire the old one safely. Single Version Charging (SVC) was IBM's provision that you should not pay the Monthly License Charge twice for that overlap. While both versions of an eligible z/OS or z/VSE MLC program ran during the transition, IBM charged on a single version. The cost penalty for migrating carefully was removed, so long as the overlap stayed inside the permitted window.

That last clause was the catch. SVC was bounded by time. The parallel running protection applied during a defined transition period, after which charges for the second version could begin to accrue. In practice that put a clock on migration projects, and a slow or paused migration could drift past the window into double charge.

In 2017 IBM announced that Multi-Version Measurement (MVM) replaced Single Version Charging for eligible z/OS and z/VSE programs. The same announcement folded in the Migration Pricing Option and the IPLA Migration Grace Period. The headline difference for buyers is the removal of the time limit.

Concept comparison, not a contract. Eligibility conditions for MVM still apply and should be confirmed per product.

The practical effect is that a migration no longer races a billing clock. Under MVM, eligible products can run in multiple versions while the sub-capacity measurement is taken without a deadline forcing the cutover. That is a real improvement in buyer leverage, because vendor pressure and internal urgency could previously be justified by the SVC window closing.

Two failure modes survive the change. First, stale assumptions: internal runbooks, older agreements, and even audit findings may still reference SVC and its time limit, leading teams to rush a migration or to accept a double charge that Multi-Version Measurement would have avoided. Second, eligibility: MVM is not automatic for every program. The measurement applies to eligible products under the right terms, and a product or configuration outside those terms does not get the benefit. Assuming coverage without confirming it is how an overlap that should be free turns into a charge at the next reconciliation or audit.

Reason in current terms. Confirm Multi-Version Measurement eligibility per product before planning any version migration, and document it. Use the absence of a time limit deliberately: sequence cutovers around operational risk and renewal timing rather than around a closing window. Validate that your sub-capacity reporting reflects the versions correctly so the measurement lands where it should. And treat any vendor or internal claim that an overlap will start charging soon with skepticism, because under MVM that pressure is usually unfounded. For the broader cost mechanics that interact with version migrations, see MSU consumption optimization and subscription and support.

Related concepts: Monthly License Charge, IPLA one time charge licensing, and sub-capacity vs full capacity. Where these products live: z/OS licensing. Put it to work: IBM cost optimization.