Microsoft made the remaining Non-EA programs available in VL Central Contracts on April 7, 2026. The practical consequence is straightforward: new work belongs in VL Central Contracts, while eAgreements is limited to retrieving and checking historical records until its full retirement.
Do this today
- Create every new, renewal, and extension package in VL Central Contracts.
- Stop parallel edits and designate one system of record for every in-flight package.
- Download the legacy agreements, signature records, and package evidence your organization may still need.
- Monitor Microsoft’s VL Central Latest News for the final retirement date.
Microsoft’s VL Central guidance says packages created during the parallel-production period were visible in both platforms, but partners were advised not to work on the same package in both tools. That warning should now be treated as an operational control. Assign one owner to each in-flight transaction, record where it is being handled, and do not attempt to maintain competing versions.
A safe immediate procedure for a Non-EA team is:
- Create all New, Renewal, and Extension packages in VL Central Contracts.
- Use eAgreements only to search, view, and download existing packages.
- Review all open work and identify which system contains the authoritative package.
- Stop parallel editing or duplicate package creation.
- Download legacy evidence needed by licensing, finance, legal, audit, and customer-facing teams.
- Track access, signature, or package problems through an internal escalation log.
- Watch Microsoft’s VL Central Latest News for the confirmed retirement date.
These are the actions that matter now. Teams do not need to wait for the legacy portal to disappear before changing their procedures.
Why July 10—not the retirement month—is the date that changes the workflow
Microsoft currently describes an August–September 2026 retirement timeframe for eAgreements/VLCM. The exact final date remains important because it determines how long organizations can retrieve legacy material from the old system. It does not change the July 10 restriction on creating Non-EA packages.
That distinction should drive the migration plan. A licensing operation waiting for the final retirement date is waiting for a date that primarily governs access to a legacy repository. The ability to begin New, Renewal, or Extension packages has already moved to VL Central Contracts.
The in-scope programs are:
- Open Value
- Open Value Subscription
- SPLA
- Campus/EES
- ISV Royalty
- Select
- Select Plus
Microsoft’s April announcement made those remaining programs available in VL Central Contracts. The affected organizations include distributors, SPLA resellers, ISV distributors, and LSP/SSP teams.
The read-only limitation is narrow but decisive. Existing packages can still be searched, viewed, and downloaded in eAgreements. New packages cannot be created there, including packages for renewals and extensions. That makes the remaining legacy-access period useful for records retrieval, not as permission to continue an old operating model.
WindowsForum user discussions about Microsoft’s recent legacy removals repeatedly point to the same practical problem: teams often focus on the final disappearance of a product or service and overlook the earlier date on which it stops performing an essential task. The eAgreements transition is a direct example. July 10 changes what licensing teams can do; the later retirement removes the remaining historical access.
Build an archive before read-only access ends
WindowsForum recommends using the read-only period to build a controlled archive of the legacy evidence your organization expects to need. This is an operational recommendation, not a Microsoft-prescribed export or retention requirement.
The objective is not to capture every screen indiscriminately. Preserve the material that licensing, finance, legal, audit, records, or customer-success teams may later need to establish what was submitted, signed, amended, completed, or left unresolved.
A practical internal checklist can include:
- Download executed agreements, package documents, signature evidence, and amendments for active and recently completed customer relationships.
- Preserve relevant records for open renewals, extensions, drafts, or signature-stage packages that may be questioned after retirement.
- Create an internal index containing available package identifiers, customer names, program names, agreement numbers, package status, and relevant dates.
- Store documents in a restricted organizational repository rather than in an individual employee’s downloads folder or mailbox.
- Use consistent customer- and program-based naming so another employee can locate the evidence without relying on the original package creator.
- Record that the material came from eAgreements/VLCM and note the retrieval date.
- Have a second reviewer spot-check a sample for completeness, legibility, and correct customer association.
- Maintain an exception register for packages that cannot be found, downloaded, or matched to the correct customer.
- Identify the business owner responsible for deciding whether each exception needs escalation.
Prioritize records according to business risk. Active customer relationships, unresolved signatures, near-term renewals, amendments, and packages likely to be needed for reconciliation deserve attention before low-value historical material.
The archive should also preserve context. A document without a package identifier, customer association, status, or retrieval date may be difficult to use later. A lightweight index often adds more value than a large unstructured folder of downloaded files.
This recommendation reflects an issue WindowsForum users have encountered across Microsoft transitions: “still accessible” is easily mistaken for “permanently available.” Microsoft’s 2025 legacy cleanup, as discussed by WindowsForum readers, included both quiet removals and formally scheduled retirements. The useful lesson for licensing teams is not that every transition is identical; it is that local records and named ownership reduce dependence on a closing service.
Archive work must not create a second package workflow. Downloading a legacy record is appropriate. Editing an old copy and treating it as a substitute for work in VL Central Contracts is not. Keep evidence retrieval separate from package processing.
Reconcile every in-flight package
The highest-risk work is often neither fully historical nor clearly new. Packages opened during a transition can be duplicated, abandoned, or handled differently by separate teams unless someone reconciles them.
WindowsForum recommends creating a short in-flight register containing:
- Customer name
- Licensing program
- Package identifier, where available
- Current package status
- Assigned owner
- System of record
- Next required action
- Signature status
- Business deadline
- Known access or validation issue
Use this register to make one explicit decision for each item: identify where the authoritative package resides and stop work on any duplicate. Do not assume that visibility in both platforms authorizes edits in both.
Parallel work can create more than clerical inconvenience. Separate versions may contain different customer information, dates, selections, or signature progress. The customer may receive competing instructions, while internal teams lose confidence about which package represents the intended transaction. Microsoft’s warning against working on the same package in both tools is therefore one of the most important controls in the transition.
A daily review may be appropriate during the first weeks after the July 10 change, particularly for organizations with high transaction volume or several regional teams. Smaller organizations can use a less frequent review, but every open package should still have one named owner and one recorded next step.
If a package appears stalled, investigate that package before creating another one. Confirm its identifier, state, customer association, documents, signature progress, and last successful action. A duplicate should not be the default response to uncertainty.
Assign responsibilities by function
Portal access alone does not prove that an organization is ready. A package can still stall because no one owns its creation, approval, signature follow-up, evidence retention, or escalation.
WindowsForum recommends a role-based division of work. These role assignments are an internal operating model, not a Microsoft-mandated staffing structure.
Package creators should begin all new Non-EA business in VL Central Contracts. They should remove or clearly mark obsolete bookmarks, job aids, templates, and training material that still tell employees to begin package creation in eAgreements.
Licensing operations leads and submitters should review every in-flight package, identify its system of record, and prevent parallel work. They should also confirm that staff understand the difference between retrieving an old record and attempting to process a new transaction.
Portal or licensing administrators should verify working access before a live customer deadline. A successful sign-in is not enough: the user should be able to reach the area needed for the assigned work and should know whom to contact internally if the expected capability is missing.
Do not assume that historical access, customer associations, or role assignments have transferred correctly merely because a user can enter VL Central. Verify access against actual responsibilities and test it before an urgent renewal or extension is due.
Customer-facing account teams should update customers when an active transaction will use a different contract or signature experience. This is especially important when a renewal was initially discussed using legacy terminology or when a customer has saved an old link.
Records, finance, and legal teams should decide which evidence warrants preservation and where it belongs. Package creators should not be the only custodians of executed or business-critical records.
Service-desk or operations coordinators can own the exception log, gather evidence, and track internal escalation deadlines. This avoids vague reports such as “VL Central is not working” and replaces them with a record of the affected user, customer, program, package, attempted action, and business impact.
This division makes failures easier to diagnose. If a transaction stops, the organization can distinguish among an access problem, missing customer information, signature delay, package-state issue, documentation gap, or internal ownership failure.
WindowsForum’s coverage of Microsoft’s broader 2025 tool changes reached a similar conclusion: replacing a legacy service is not finished when administrators recognize the new product name. Readiness depends on updated procedures, tested access, assigned ownership, and a known path for exceptions.
Use an internal escalation runbook
Because eAgreements can no longer create the affected package types, “start again in the old tool” is not a valid fallback. WindowsForum recommends maintaining an internal escalation runbook for access, package, and signature problems.
This runbook is an organizational contingency measure. It should not be presented as Microsoft’s required escalation sequence unless your organization has confirmed the applicable Microsoft documentation and support terms.
For a blocked package, collect:
- The affected user and organization
- The customer and licensing program
- The package identifier, if one exists
- The current package state
- The intended action
- The last successful action
- The date and time of the problem
- Relevant error text or screenshots
- The customer or renewal deadline
- Whether another version of the package exists
- The internal owner and next review time
For an access problem, record what the user can reach as well as what is missing. “User can sign in but cannot perform the assigned contract task” is more useful than “portal access failed.” Check internal account, role, and customer-association information before escalating externally.
For a signature delay, first verify the package’s actual state and preserve its evidence. Confirm whether the customer received the expected request and whether the package is waiting for customer action, internal action, or system resolution. Do not create a duplicate solely because the signature appears delayed.
The internal runbook should specify:
- Who performs the first review.
- Who verifies the user’s organizational access and assigned responsibilities.
- Who decides whether a duplicate or abandoned package exists.
- Who gathers evidence for an external support request.
- Who communicates with the customer.
- Who tracks the issue until closure.
- Who updates the in-flight and exception registers.
Microsoft has indicated that Change of Channel Partner functionality is upcoming. That does not establish a general workaround for blocked Non-EA package creation, access, or signatures. Treat channel-change requirements as their own scenario and do not build a contingency plan around functionality that is not yet part of the verified procedure.
A good escalation record protects the customer experience as well as internal operations. It gives account teams a factual status, prevents repeated troubleshooting, and reduces the chance that another employee will create conflicting work.
Update instructions, bookmarks, and training
Old documentation can keep a retired behavior alive long after the official process changes. Search internal knowledge bases, shared drives, onboarding material, browser favorites, email templates, and renewal checklists for instructions that direct employees to begin Non-EA packages in eAgreements.
Update those materials to state four facts clearly:
- New, Renewal, and Extension package creation belongs in VL Central Contracts.
- eAgreements/VLCM is read-only for the affected Non-EA work.
- Existing records may still be searched, viewed, and downloaded before full retirement.
- The same package must not be worked in both systems.
Avoid publishing click-by-click instructions unless they have been validated against the current portal. Interface labels and navigation can change, and an unverified path may send users to the wrong place. Internal job aids should focus first on the required outcome, responsibility, and control points.
Training should include a real-world test rather than only a presentation. Have the relevant employees demonstrate that they can access the destination environment, identify how their assigned package work begins, recognize where a package is waiting, and locate the internal escalation route. Do not use a live customer deadline as the first access test.
Customer communications may also need revision. Remove old eAgreements links from reusable messages and explain the current process without overloading customers with platform-migration detail. Customers mainly need to know what action is required, how to recognize the correct request, and whom to contact if it fails.
Monitor the final retirement date without delaying action
Microsoft’s current retirement timeframe is August–September 2026. Teams should monitor VL Central Latest News for the final date because that date affects the remaining opportunity to retrieve records from eAgreements/VLCM.
Assign one person to monitor the announcement and distribute any change to licensing operations, administrators, records teams, legal, finance, and customer-facing staff. The notification should trigger a final exception review rather than the beginning of the migration.
A useful final-access checklist is:
- Confirm priority records have been downloaded.
- Recheck unresolved archive exceptions.
- Verify that all open packages have one owner and one system of record.
- Remove remaining internal instructions that suggest eAgreements can create packages.
- Confirm the escalation runbook has active owners.
- Notify affected teams of the final retrieval date.
- Document completion and any accepted gaps.
WindowsForum readers tracking the unusually heavy 2026 Microsoft retirement calendar have emphasized the need to separate dates that sound similar but require different actions. End of support, removal of a feature, loss of transaction capability, and final service retirement are not interchangeable milestones.
That distinction also appeared in WindowsForum discussions of Microsoft 365 support on Windows 10 and the wider group of Microsoft product deadlines around October 14, 2025. Those cases involve different products and support rules, so they should not be used as evidence for VL Central policy. They do, however, reinforce a sound planning habit: identify exactly what changes on each date, assign the corresponding action, and do not let a later headline date obscure an earlier functional restriction.
For this transition, the action map is simple:
- April 7, 2026: the remaining Non-EA programs became available in VL Central Contracts.
- July 10, 2026: eAgreements/VLCM became read-only for creating New, Renewal, and Extension packages in scope.
- August–September 2026: Microsoft’s current timeframe for full retirement.
- Until final retirement: retrieve and verify needed historical records, while conducting new package work in VL Central Contracts.
What completion looks like
A team has completed the operational transition when it can do more than sign in. It should be able to:
- Begin every affected New, Renewal, and Extension package in VL Central Contracts.
- Identify the owner and system of record for every in-flight package.
- Prevent parallel edits and duplicate packages.
- Retrieve required historical evidence from eAgreements while access remains available.
- Verify that employees can perform their assigned work.
- Escalate access, package, or signature problems with useful evidence.
- Tell customers what action they need to take.
- Monitor Microsoft’s VL Central Latest News for the confirmed retirement date.
- Close or accept archive exceptions before legacy access ends.
This is consistent with the strongest lesson in WindowsForum’s user reports on Microsoft’s legacy-tool overhaul: migration is an operational exercise, not a login exercise. Inventory, ownership, replacement procedures, evidence, and exception handling determine whether the transition is complete.
Frequently Asked Questions
Should we still use eAgreements for any new Non-EA deal?
No. Since July 10, 2026, eAgreements/VLCM cannot create New, Renewal, or Extension packages for the affected Non-EA programs. Create that work in VL Central Contracts.
Can we still retrieve old packages from eAgreements?
Yes, for now. The legacy system remains usable to search, view, and download existing packages. Full retirement is planned for the August–September 2026 timeframe, so retrieve needed evidence before access ends.
Which programs are affected?
Open Value, Open Value Subscription, SPLA, Campus/EES, ISV Royalty, Select, and Select Plus are in scope.
Which organizations need to act?
The transition applies to the relevant work performed by distributors, SPLA resellers, ISV distributors, and LSP/SSP organizations.
Can we continue editing a package in both platforms?
No. Microsoft advised partners not to work on the same package in both tools during the parallel period. Designate one authoritative package and stop parallel edits.
What can eAgreements still do?
For the affected Non-EA work, it can still be used to search, view, and download existing packages while read-only access remains available. It cannot create New, Renewal, or Extension packages.
Should we wait for Microsoft to publish the final retirement date?
No. The July 10 creation restriction is already in effect. Move all active package work to VL Central Contracts, archive needed historical evidence now, and monitor Microsoft’s VL Central Latest News for final retirement timing.
Does signing in prove that a user is ready?
No. WindowsForum recommends verifying that each user can perform the work assigned to that role before a live renewal or customer deadline. Treat access and role checks as internal readiness controls.
What should we do if a package or signature is stuck?
Preserve the package identifier, customer and program details, current state, attempted actions, errors, and deadline. Check for duplicates before creating anything new, then follow your organization’s documented escalation runbook.
Is Change of Channel Partner functionality a fallback for package problems?
Do not assume so. Microsoft has indicated that Change of Channel Partner functionality is upcoming, but that does not establish it as a workaround for access, package, or signature failures.
Is the archive checklist a Microsoft requirement?
It is a WindowsForum operational recommendation. Each organization should determine what evidence it needs and how that material should be stored, reviewed, protected, and retained.
What are the four most important actions right now?
Create all affected packages in VL Central Contracts, stop parallel work, download needed legacy evidence, and monitor VL Central Latest News for the final retirement date.