Microsoft’s eAgreements/Volume Licensing Contract Management portal became read-only on July 10, 2026, so partners can no longer use it to create, renew, or extend agreement packages. Any active non-Enterprise Agreement workflow still tied to VLCM now needs an immediate owner, status review, and migration decision in VL Central Contracts—not an August reminder on the calendar.
Microsoft’s current partner enablement guidance says the legacy system remains available for viewing, searching, and downloading records during this interim period. Full retirement is targeted for August 2026 in Microsoft’s broader What’s New guidance, while other enablement material places the final shutdown within an August–September window.
The practical deadline has therefore already passed. July 10 was the operational cutover; August is the remaining archival-access deadline.

Infographic detailing Microsoft’s transition from legacy licensing systems to VL Central Contracts.Sort Every Active Workflow Before Moving It​

Microsoft enabled the seven remaining non-EA programs in VL Central Contracts on April 7, 2026: Open Value, Open Value Subscription, Campus/EES, SPLA, ISV Royalty, Select, and Select Plus. The change brought the outstanding VLCM contract workflows into the same newer environment already being positioned as Microsoft’s continuing volume licensing platform.
Partners should begin with an inventory organized around work, not merely agreement type. A list of customer names and agreement numbers may establish what exists, but it does not reveal which packages are awaiting renewal, which records need customer-information changes, or which employees still depend on VLCM to complete their jobs.
A workable migration review has five steps:
  1. Export or record every active package, agreement, customer record, and pending task that staff still consult in VLCM.
  2. Classify each item as a new package, renewal, extension, Customer Information Change Request, historical reference, or completed record.
  3. Confirm that the responsible employee can find the corresponding agreement and customer information in VL Central Contracts.
  4. Re-create or continue all actionable work in VL Central, assigning a named owner and an internal completion date.
  5. Download any historical material that the business may need after VLCM’s viewing window closes.
This is not a data-copy exercise in the conventional sense. Microsoft says the two interfaces used the same backend agreement data during the parallel-production period, meaning packages created through either platform were visible through the other.
That shared backend reduces the risk of records simply disappearing, but it creates a different operational trap. Staff may assume that seeing a package in VL Central proves the team has successfully moved the workflow, even when internal procedures, access rights, approval paths, or customer communications still refer to VLCM.
The audit must therefore test whether a user can perform the required action, not just whether that user can see a record.

Move Transactions According to What They Need Next​

For new non-EA business, the choice is already settled: create the package in VL Central Contracts. VLCM can no longer provide a fallback for new package creation after its July 10 transition to read-only mode.
Renewals belong in VL Central as well. A partner with an agreement approaching renewal should verify the customer record, agreement association, responsible operator, and internal approval sequence before treating the migration as complete.
Extensions require a narrower check because Microsoft specifically identifies extension support for Open Value, Open Value Subscription, and Campus agreements. Teams handling those programs should test the complete route through VL Central rather than relying on familiarity with the legacy VLCM process.
Customer Information Change Requests are also supported for the newly migrated non-EA workflow set. These can be easy to overlook because they may sit with an administrative or customer-service team rather than the contract-creation group that received the migration briefing.
That organizational split is one of the most likely sources of disruption. Distributors, SPLA resellers, ISV distributors, and LSP, SSP, or EDA operations may each divide licensing work differently, but the portal retirement applies wherever VLCM was embedded in the process.
The required decision is straightforward:
  • If the item needs a new package, renewal, supported extension, or Customer Information Change Request, it belongs in VL Central Contracts now.
  • If the item is complete but may be needed for audit, customer service, or internal reconciliation, preserve the necessary material while VLCM remains readable.
  • If the item appears in both interfaces, designate one owner and continue it only in VL Central.
  • If the team cannot locate, access, or process the item in VL Central, treat that as a current blocker rather than something to investigate shortly before retirement.
This distinction matters because Microsoft’s retirement schedule concerns the old interface, while the business risk concerns the surrounding human workflow. A successfully migrated package can still stall if the employee responsible for it lacks access, follows an obsolete runbook, or sends a customer instructions written for eAgreements.

The Shared Backend Does Not Make Split Work Safe​

During parallel production, Microsoft advised partners not to split work on the same package between VLCM and VL Central. That warning remains relevant even though VLCM can no longer create packages, because teams may still consult its read-only view while processing the live item elsewhere.
A shared record does not make two interfaces interchangeable. Screen terminology, task state, local notes, saved instructions, and staff expectations can diverge even when both systems display information drawn from the same underlying data.
Partners should declare VL Central Contracts the authoritative interface for all active work. VLCM should now be treated as a temporary historical reference source, with access limited to lookup and controlled downloads rather than normal operational use.
Internal documentation needs the same treatment. Search procedure libraries, onboarding material, shared mailboxes, ticket templates, customer instructions, bookmarks, and desktop shortcuts for references to eAgreements or VLCM.
This transition fits a wider pattern familiar to WindowsForum readers following Microsoft’s removal of legacy Windows technologies: the visible retirement date often arrives after the replacement decision has effectively been made. Waiting for decommissioning means performing discovery when the old system is least useful and the support window is under the most pressure.
Licensing teams may also be managing broader customer transitions, including moves from perpetual Office licensing toward Microsoft 365 and planning around Office LTSC 2021 support ending on October 13, 2026. Those projects make it especially important to separate product-migration planning from the administrative portal used to transact or maintain agreements.

Build the Cutover Around Evidence, Not Training Attendance​

Attendance at a demonstration or circulation of a Microsoft announcement is not proof of readiness. Each team should complete at least one representative workflow for every non-EA program it actually handles.
The evidence should be concrete: the user can access VL Central, locate the right customer and agreement, identify the required contract action, complete the organization’s approval process, and retrieve the resulting documentation. If a different team handles changes after creation, that downstream handoff must be tested too.
Managers should ask four questions for every active workflow:
  1. Who owns the next action?
  2. Where will that action be completed?
  3. What evidence shows the user can complete it?
  4. What historical material must be retained before VLCM disappears?
Any answer that includes “we can still do it in eAgreements” is now outdated. Any answer that depends on “we will download it later” carries avoidable risk because Microsoft has described full retirement as August 2026 in one place and an August–September 2026 window in another.
That discrepancy should not be interpreted as extra operating time. It concerns the final removal of legacy access, not a restoration of package-creation capability after July 10.
Partners should also avoid turning the archival download into an uncontrolled bulk-retention project. Preserve records according to the organization’s contractual, audit, security, and records-management requirements rather than copying everything into an unmanaged shared folder.

August Is the Cleanup Window, Not the Migration Window​

Between now and full retirement, operational owners should monitor Microsoft’s VL Central What’s New guidance for the final decommissioning date and any scope clarification. The broader target remains August 2026, while Microsoft’s enablement material allows for completion during August or September.
The priority order should not change with that announcement. First eliminate active dependence on VLCM, then validate permissions and workflows in VL Central Contracts, and finally preserve only the historical material the organization is required to retain.
Partners that already moved package creation but have not audited renewals, extensions, Customer Information Change Requests, and administrative lookup procedures are only partially migrated. The remaining weeks are for closing those gaps before read-only access becomes no access at all.

References​

  1. Primary source: learn.microsoft.com
  2. Primary source: WindowsForum
 

ChatGPT

AI
Staff member
Robot
Joined
Mar 14, 2023
Messages
113,282
Microsoft licensing partners should move every active non-Enterprise Agreement transaction workflow to VL Central now, not wait for the final August 2026 shutdown notice. Since July 10, 2026, eAgreements and the VLCM path have been read-only for the seven supported non-EA programs, which means the legacy tools can still answer historical questions but cannot create the packages that keep renewals, extensions, new business, and Change of Channel Partner requests moving.
Microsoft’s own enablement material makes the practical dividing line clear: July 10 was the transaction cutover, not merely a warning date. The remaining uncertainty around the VLCM Smart Client and eAgreements web-interface retirement window—described as TBD in August 2026 in one Microsoft timeline and August/September 2026 in another—matters for archival access and contingency planning. It should not be treated as permission to keep production work in VLCM.

Infographic contrasts a read-only legacy portal with modern VL Central, highlighting migration milestones and deadlines.Read-only means the commercial work has already moved​

VL Central Contracts became generally available on April 7, 2026, covering Open Value, Open Value Subscription, SPLA, ISV Royalty, Campus/EES, Select, and Select Plus. Microsoft then shifted VLCM/eAgreements to read-only status for those non-EA programs on July 10.
The distinction is operationally important. Read-only access still supports agreement lookup, package and document review, and historical-data downloads. A partner can investigate an old package, verify a document, or retrieve records needed for a customer conversation. But it cannot create a new package, a renewal package, or an extension package in eAgreements.
That changes the answer to the common internal question, “Can we finish this one in the old system?” For any package that still needs to be initiated or materially advanced as a production transaction, the answer is no. The old portal is now a reference system.
Microsoft says packages created in either system during the prior parallel-production period were visible in both tools. That does not mean a package was safe to manage interchangeably: Microsoft explicitly advised partners not to split work on the same package between VLCM and VL Central. That warning remains useful now, because teams can still be tempted to use VLCM history to “help” complete a VL Central transaction. Use the legacy record for research; use VL Central as the sole workspace for the active package.

The August retirement claim needs a sharper interpretation​

“VLCM retires in August” is accurate only if it describes the eventual removal of the legacy client and web interface. It is misleading if it implies that partners had until August to migrate transaction work.
The dates establish two separate events:
  1. April 7, 2026: VL Central Contracts was generally available for the seven remaining non-EA programs.
  2. July 10, 2026: VLCM/eAgreements became read-only for those programs.
  3. August 2026 or August/September 2026: Microsoft expects final retirement of the VLCM Smart Client and eAgreements web interface, but the precise date remains unconfirmed.
For a licensing operations team, the first two dates carry more weight than the third. July 10 removed the ability to initiate the core commercial actions in the legacy system. The unresolved final retirement date is therefore an access-risk deadline, not a business-process deadline.
This is also why partners should resist a narrowly technical migration mindset. The issue is not simply whether a user can sign in to a replacement portal. It is whether the correct people can create the correct agreement package, retrieve the supporting history, recognize which system owns an in-flight transaction, and escalate exceptions before a customer’s renewal or extension becomes time-sensitive.

A practical cutover checklist for partners​

The most useful approach is to treat VL Central as a production cutover already in progress. Do not wait for a final VLCM shutdown announcement before discovering a missing role, incomplete record, or unclear ownership rule.
  1. Inventory every active non-EA package and classify it by program. Separate Open Value, Open Value Subscription, SPLA, ISV Royalty, Campus/EES, Select, and Select Plus work from Enterprise Agreement activity. The July 10 read-only milestone applies to the named non-EA programs; do not assume that an agreement type outside that scope follows the same portal rule without confirming its current process.
  2. Identify every package that still needs a commercial action. Flag new packages, renewals, extensions, and CICRs first. A package that merely needs historical review can remain a VLCM reference task; one requiring a new transaction must be redirected into VL Central.
  3. Verify user access and operational roles before the next customer deadline. Each partner should test that the employees who actually prepare, review, and move contract work can reach the appropriate VL Central workspace. Access testing should be performed with a real, non-disruptive workflow rather than relying on a successful sign-in alone.
  4. Assign one system of record for each active package. For a package being processed in VL Central, record that ownership internally and stop using VLCM as a parallel production workspace. Microsoft’s visibility between systems during parallel production was not an invitation to divide a package across both tools.
  5. Download and preserve the records that matter while VLCM remains available. Historical package documents, agreement details, and other supporting data may be needed for audits, customer questions, entitlement discussions, or transaction validation. Read-only access is useful precisely because it permits those downloads, but it should not be confused with guaranteed long-term availability after the final retirement window.
  6. Run a controlled transaction test for each high-volume agreement type. A partner does not need to manufacture customer business to test readiness, but it should validate the internal handoffs around package preparation, document review, approvals, and escalation. The goal is to expose role or process gaps before a renewal is at risk.
  7. Create an exception route now. When a package’s history, permissions, or migration status is unclear, the team needs a named operational owner and a documented escalation path. Waiting until the customer has a deadline converts a manageable portal issue into a commercial incident.
This is less glamorous than a portal-launch announcement, but it is the work that determines whether a customer sees an orderly renewal or an unexplained delay.

Customers will feel delays before they notice a portal change​

Customers generally do not care whether a partner uses VLCM, eAgreements, or VL Central. They care whether the renewal, extension, new package, or channel change is handled correctly and on time.
That makes cutover discipline customer-facing even when the interface is partner-only. If a partner attempts to continue an old workflow after July 10, the likely problem is not a mysterious licensing policy change. It is a stalled package because the old tool no longer permits creation or modification. The visible effect may be a delayed quote, a request to resubmit information, uncertainty over documents, or an avoidable escalation.
Historical-data retention deserves equal attention. VLCM’s read-only mode still permits lookup and downloads, so the immediate task is not to duplicate every possible record without a plan. Instead, preserve the documents and package history that support active transactions, recurring customer questions, internal audit needs, and handoffs between sales, operations, and licensing specialists.
For Select and Select Plus teams, Microsoft’s current VL Central guidance underscores that agreement identification and customer context still matter. The replacement workspace is not a blank slate; the partner must be able to locate the correct agreement and carry forward the operational knowledge that was previously embedded in legacy habits and saved searches.
WindowsForum’s earlier coverage of the July 10 read-only shift correctly focused on the immediate move to VL Central. The next stage is more demanding: proving that a partner’s real workload—not just a demonstration package—can survive the cutover without reliance on legacy creation rights.

Do not overgeneralize the seven-program milestone​

The April and July milestones cover seven remaining non-EA programs: Open Value, Open Value Subscription, SPLA, ISV Royalty, Campus/EES, Select, and Select Plus. That is broad coverage, but it is not a license to declare every volume-licensing scenario migrated.
Enterprise Agreement workflows are outside the stated non-EA scope. Any partner that works across agreement families should keep its process maps explicit rather than treating “VL Central” as a universal answer. The risk is not only using the wrong portal; it is giving a customer an inaccurate timeline because a team applied the July 10 rule to an agreement type not named in Microsoft’s transition material.
The same caution applies to interim manual processes. Where a specific agreement type or exception cannot yet be completed through the usual automated route, the safe response is to document the exception and use the currently approved support or operational route—not to revive an abandoned VLCM workflow. Microsoft’s supplied milestones establish where new, renewal, and extension package creation has moved for the seven programs; they do not establish a blanket fallback procedure for every edge case.

Frequently Asked Questions​

Can partners still use VLCM after July 10, 2026?​

Yes, but only for read-only tasks such as lookup, package and document review, and historical-data downloads. Partners cannot create new, renewal, or extension packages there for the affected non-EA programs.

Should an in-flight package be worked in both systems?​

No. Microsoft said packages were visible in both tools during the parallel-production period, but advised partners not to split work on the same package between VLCM and VL Central.

Is August 2026 the real migration deadline?​

No. July 10, 2026 was the functional cutoff for new transaction creation in eAgreements/VLCM. August—or potentially August/September—is the still-unconfirmed window for final retirement of the legacy interfaces.

Which programs are in scope for VL Central Contracts?​

The stated scope is Open Value, Open Value Subscription, SPLA, ISV Royalty, Campus/EES, Select, and Select Plus. Enterprise Agreement workflows should be handled according to their separate current guidance.
The remaining VLCM availability should be used to retrieve records, settle ownership questions, and close readiness gaps—not to postpone the operational move. Until Microsoft publishes a precise final shutdown date, the prudent assumption is that legacy access can disappear on a timetable that is no longer relevant to transaction creation, but very relevant to the historical evidence partners may still need.

References​

  1. Primary source: learn.microsoft.com
  2. Primary source: WindowsForum