VLCM Read-Only Since July 10: Move Contracts to VL Central

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.

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
   
   

   Volume Licensing Central documentation | Microsoft Learn

   Learn how to use Volume Licensing Central to manage your relationship and business with Microsoft.

   learn.microsoft.com
2. Primary source: WindowsForum
   
   

   Embrace the Future: Transitioning from Office Licenses to Microsoft 365 | Windows Forum

   Microsoft’s recent push to have businesses ditch their traditional Office licenses in favor of Microsoft 365 isn’t just another product update—it’s a bold...

   windowsforum.com

 

[ChatGPT]

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.

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
   
   

   Select Plus | Microsoft Learn

   Select Plus orders in VLC

   learn.microsoft.com
2. Primary source: WindowsForum
   
   

   VLCM Read-Only Since July 10: Move Contracts to VL Central | Windows Forum

   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...

   windowsforum.com

 

[ChatGPT]

Microsoft’s operative cutover date for non-Enterprise Agreement volume licensing partners is July 24, 2026, not the July 10 date circulated in earlier guidance. By that date, both the eAgreements web interface and VLCM Smart Client become read-only; teams that still need to create, renew, extend, or change agreement contact information must have their work moving through VL Central Contracts before the cutoff.
Microsoft’s July 14 adoption-call recap on Microsoft Learn puts the retirement into a tight sequence: read-only access begins July 24, the Smart Client and eagreements.microsoft.com are decommissioned at the end of July, and the final adoption call follows on August 11. For distributors, SPLA resellers, ISV distributors, and LSP, SSP, and EDA teams, this is no longer a portal-migration project with a vague finish line. It is a short operational window to protect in-flight business and preserve evidence that may be needed after the legacy interfaces disappear.

July 24 ends transactions, not necessarily visibility​

The critical distinction is between read-only and retired. On July 24, VLCM and eAgreements can still be used to view and search historical information, but they can no longer transact new business. Microsoft says historical packages, agreements, and customer data remain visible in VL Central, while VL Central Contracts becomes the only place to create new non-EA business.
That does not make the legacy tools a safe fallback. A package sitting half-finished in eAgreements on July 23 is not simply an archive item: the people responsible for it need to know who owns it, what signing path it needs, which documents have already been produced, and whether the same work can be completed in VL Central before the deadline.
For IT and licensing leaders, the immediate task is to stop treating “historical visibility” as a substitute for records management. A searchable legacy screen is useful during read-only mode. It is not a recovery plan once the Smart Client and web interface are fully decommissioned at the end of July.

---

The cutover checklist starts with an inventory, not a login test​

Every affected partner should run a structured review now, with a named owner for each agreement package. The goal is not merely to confirm that someone can see the Contracts workspace. It is to establish whether each active item has a viable route to signature, submission, support, and later retrieval.

1. Build a list of every non-EA package that is open, pending, or expected to start before July 24. Include new agreements, renewals, extensions, and contact-information-change work. Assign each package to a responsible individual and record its current state, customer organization, relevant licensing program, signing choice, and internal deadline.
2. Classify every item as complete, transferable, or at risk. Completed packages should move into the evidence-retention process. Transferable work should be recreated or continued in VL Central according to the applicable workflow. At-risk work is anything dependent on missing access, unresolved customer data, unclear ownership, an unavailable signer, or a support question that could prevent action before the cutoff.
3. Validate VL Central Contracts access by role and package ownership. Microsoft’s non-EA workflows are now in VL Central for Open Value, Open Value Subscription, Campus/EES, SPLA, ISV Royalty, Select, and Select Plus. Do not accept a generic “I can sign in” confirmation; verify that the person who must create, submit, administer, or review a package can see the relevant customer and can perform the action assigned to their role.
4. Run one controlled package review in VL Central for each program your organization actively handles. The practical path is to enter VL Central, open the Contracts workspace, select the applicable package action, locate the correct customer organization, select the program, and complete the required sections. The exercise should expose missing permissions, ownership gaps, or unanswered process questions while eAgreements remains available for comparison.
5. Make the signing decision before the package is ready to send. Microsoft says DocuSign has been available across all non-EA programs since May 7 alongside Adobe Sign. In Greater China, DocuSign is the only in-tool option, so teams serving that region should confirm the chosen route and signer readiness before an agreement reaches the last step.
6. Retrieve and retain the supporting record for every business-critical package. Keep the agreement documents, package identifiers, customer-contact details, internal approvals, signature status, and any case correspondence in the organization’s approved records repository. The point is to preserve proof independent of a legacy application’s search screen.
7. Open support escalations before July 24, not after. If a package cannot be created, found, assigned, signed, or completed in VL Central, log the issue through the established VL Central support path while there is still time to demonstrate the legacy state and resolve the operational block.

The checklist is deliberately more demanding than a migration announcement because the risk is concentrated in exceptions. The happy path—create a new package in VL Central, complete the required fields, and send it for signature—is already available. The failure cases are a missing administrator, an unrecognized package owner, an inaccessible customer record, or a signer who has not been briefed until the day the old tool stops taking transactions.

Each partner role has a different last-mile problem​

Distributors should focus first on scale and delegation. They may hold the broadest view of customer and reseller activity, making them the natural point to reconcile packages that have unclear ownership or competing internal handoffs. Their July 24 readiness review should identify which team creates packages, which team validates data, which team handles customer contact, and who can make an escalation decision when a package is blocked.
SPLA resellers should treat the transition as a continuity exercise for recurring operational work. Confirm that the people responsible for new agreements, renewals, extensions, and contact changes have VL Central access and understand the new package flow. If an agreement depends on customer action or a specific signer, the reseller should communicate the date plainly: after July 24, the old interface can be searched but cannot create or move the transaction forward.
ISV distributors need a clean record of each program package’s commercial and document state before the legacy tools retire. The meaningful safeguard is not an informal spreadsheet alone, but a retained evidence set that connects the agreement, the responsible customer contact, the current package state, and the next required action. This is particularly important where a later dispute is likely to begin with the question, “What was visible in the former system?”
LSP, SSP, and EDA teams should ensure their operational model is not built around a small number of legacy-tool specialists. VL Central access, package ownership, signing selection, support escalation, and record retrieval should be documented across the team. The system change may be focused on non-EA contracting, but an access gap can become a business-continuity issue when the only knowledgeable operator is unavailable.

---

Preserve evidence before the archive becomes an assumption​

Microsoft’s position is that historical packages, agreements, and customer data remain visible in VL Central. That is useful, but it should be tested for the precise records your organization must retrieve—not presumed based on a general statement about history.
A sensible pre-cutover evidence review has three parts. First, identify the agreements and packages that matter most for compliance, renewal planning, customer disputes, finance reconciliation, and internal audit. Second, retrieve the documents and status evidence needed to explain those records without reconstructing events from memory. Third, document where that material is stored and which team owns future retrieval.
This is also the time to identify a rollback plan, although “rollback” should not mean returning to eAgreements after July 24. The workable rollback is procedural: if a VL Central workflow fails or a record cannot be found, pause the transaction, preserve the package details and screenshots available before retirement, assign an escalation owner, and use VL Central support rather than relying on a legacy transaction path that will no longer exist.
WindowsForum readers tracking the earlier July 10 guidance should update internal notices, staff calendars, and customer communications. The date change buys two additional weeks of transaction capability, but it should not become two additional weeks of delay.

The final days of July need named checkpoints​

From July 20 through July 23, teams should complete access verification, package triage, document retention, signer confirmation, and support escalation. July 24 is the hard boundary for creating or transacting non-EA business in eAgreements and VLCM; from then on, use the legacy tools only as a temporary historical reference while VL Central handles operational work.
The end of July is the retirement boundary for both the VLCM Smart Client and eagreements.microsoft.com. Before that point, confirm that internal records do not depend on a future legacy login and that staff know where to find agreement history in VL Central.
August 11 is the final Microsoft adoption call in this series. It is a useful last forum for unresolved adoption questions, but it arrives after the legacy tools are gone. Organizations should treat it as a venue for refinement, not their first readiness milestone.

Frequently Asked Questions​

Does July 24 mean historical agreements disappear?​

No. Microsoft says VLCM and eAgreements remain available for viewing and searching historical information once read-only begins, and that historical packages, agreements, and customer data remain visible in VL Central. The important date for losing the legacy interfaces entirely is the end of July 2026.

Can a team still use VLCM to finish a new package after July 24?​

No. Microsoft’s revised timeline says the Smart Client and eAgreements web interface become read-only on July 24, meaning they cannot transact new business. New packages, renewals, extensions, and contact-information changes belong in VL Central.

Which signature services are available in VL Central for non-EA programs?​

Adobe Sign and DocuSign are both available for all non-EA programs. Microsoft says DocuSign is the only in-tool choice in Greater China.

Is the August 11 adoption call a reason to delay the move?​

No. The call follows the July 24 read-only transition and the end-of-July decommissioning of the legacy tools. Use it to resolve remaining questions, not to postpone access checks, evidence retention, or active-package triage.
The practical consequence is straightforward: by the close of July, non-EA licensing teams must be able to operate and retrieve what they need through VL Central, without depending on eAgreements or the VLCM Smart Client. The partners that fare best will be the ones that treat July 24 as a package-by-package cutover deadline, rather than a calendar note about a retiring application.

---

References​

1. Primary source: learn.microsoft.com
   
   

   What's New | Microsoft Learn

   This article is the announcement page within the Volume Licensing Central Hub

   learn.microsoft.com
2. Independent coverage: eagreements.microsoft.com
   
   eAgreements - Log-In
3. Primary source: WindowsForum
   
   

   VLCM Read-Only Since July 10: Move Contracts to VL Central | Windows Forum

   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...

   windowsforum.com