The AWS Partner Central Migration Deadline Nobody Can Source

Search for the AWS Partner Central migration deadline and you will find it stated as fact, twice, with three months between the two answers.

WorkSpan: “By June 30, 2026, every AWS partner must complete a mandatory migration,” and, further down, “After June 30, 2026, the old Partner Central portal shuts down.” SaaSify: “The AWS Partner Central migration deadline is September 30, 2026,” and “the legacy portal is scheduled to shut down permanently on September 30, 2026.”

Neither cites an AWS source. Not a press release, not a documentation page, not a partner communication. Both simply assert it.

They cannot both be right. What is more interesting is the possibility that neither is — because AWS’s own migration documentation contains no date at all.

What AWS actually says

The Partner Central migration guide describes a four-step process: review the readiness checklist, link an AWS account to your APN account, set up user access through IAM with the new managed policies, and schedule or initiate the migration. It explains that alliance leads and cloud admins can use a self-service tool to choose a date and time, that migration typically takes between two and six hours depending on how much data has to move, that all users are locked out while it runs, and that AWS recommends scheduling it outside business hours.

What it does not contain is a deadline. There is no cut-off, no shutdown date, no end-of-life notice, and no language stating that anything stops working on a particular day. The tool lets you pick the date, which is a strange design for a migration with a fixed expiry.

This is the same pattern we found with Partner Revenue Measurement, and it is worth naming because it recurs. AWS communicates enforcement dates to partners through Partner Central, which requires a login and therefore cannot be cited by anyone writing publicly. Into that vacuum, vendors publish dates. The dates acquire authority through repetition rather than through sourcing, and eventually they are simply what everyone knows.

The detail that settles it

Here is a checkable fact that neither vendor appears to have looked for.

AWS maintains a public changelog of its managed policies for Partner Central users. On 30 June 2026 — the day WorkSpan says the legacy portal shut down — AWS added two new managed policies: AWSPartnerCentralRevenueAttributionManagement and AWSRevenueAttributionManagement, granting access to create and manage Revenue Attribution resources and Marketplace Revenue Share allocations.

AWS was shipping new capability into Partner Central on the exact date a vendor told partners it was being switched off. That does not merely fail to support the claim; it is difficult to reconcile with it at all.

The same changelog shows the platform under continuous, dated development: Partner Central agent session management via the Model Context Protocol added to four policies on 13 March 2026, prospecting actions added on 16 June 2026, Amazon Q permissions for the Partner Assistant in February. This is a system being invested in, and the changelog is public, dated, and takes about ninety seconds to check.

Why this matters more than pedantry

It would be easy to shrug at this. The migration is worth doing anyway, so does a wrong date really hurt?

Yes, in three specific ways.

It puts the work in the wrong order. A partner who believes they have until 30 June does the migration and stops. A partner who understands what migration actually unlocks does the migration and then uses what it unlocks. Those are different projects with different outcomes, and deadline-framing produces the first one.

It burns the credibility that real deadlines need. The PRM compliance requirement on 31 July 2026 was real and it was missed by a great many partners. One reason is that partner ops teams have learned to discount vendor urgency, because vendor urgency has been mostly noise. Crying wolf about migration dates is part of why a genuine date went unnoticed.

And it tells you something about the source. A vendor that publishes an unsourced date is telling you how it handles facts that are inconvenient to check. Both of the pages quoted above exist to sell migration assistance. That does not make the date wrong. It does mean nobody in the chain had an incentive to look it up.

What is genuinely mandatory

Here is the substitution worth making. Instead of asking when you must migrate, ask what you cannot do until you have. That question has documented answers.

Seeing your PRM attribution. The Attributed Revenue dashboard requires migration to Partner Central in the Console, full stop. You can instrument every workload perfectly, tag correctly, clear compliance — and see none of it. This is the sharpest one, because it connects migration to money that is already being measured on your behalf.

Revenue Attribution IDs. Migration is a stated prerequisite. These are the mechanism for mapping attributed revenue to specific deals, and from 2027 they underpin automated milestone-based payouts. A partner who has not migrated cannot create one. The deal-level layer covers what that means in practice.

Subsidiary account connections. If you hold more than one AWS Marketplace seller account, connecting them to a single primary partner account requires the new experience. Without it, attribution fragments across accounts and your reported numbers understate you.

Partner Central agents. The agent capability is post-migration only, and the policy changelog shows session management through the Model Context Protocol being added across four managed policies in March 2026. Agents read your ACE pipeline. What they can do for you is bounded by what is written in your opportunity records — but they cannot do anything at all before you migrate.

Every one of those is a capability argument rather than a threat, and capability arguments have a useful property: they survive being checked.

What migration actually costs

The part the deadline framing obscures is that this is not a button. The substantive work is identity, and it lands on whoever administers IAM rather than on whoever owns the partnership.

After migration, Partner Central access runs through the linked AWS account. Users authenticate with IAM credentials, and what they can do is governed by AWS managed policies rather than by legacy Partner Central roles. So somebody has to map every current user onto a policy.

There are more than a dozen to choose between, and the granularity is the point: AWSPartnerCentralFullAccess for everything, AWSPartnerCentralOpportunityManagement for people who work opportunities and leads, PartnerCentralIncentiveBenefitManagement for fund requests, claims and wallets, AWSPartnerCentralChannelManagement for channel relationships and deal registration, AWSPartnerCentralMarketingManagement for Marketing Central and case studies, and AWSPartnerCentralRevenueAttributionManagement for the revenue attribution work described above. Cloud admins additionally need PartnerCentralAccountManagementUserRoleAssociation to associate users with roles, and those roles must carry the name prefix PartnerCentralRoleFor.

Treat that mapping as the actual project. It is the first time most partner organisations will have been asked to state, explicitly, who is allowed to submit an opportunity, who can request funding, and who can see the money. Legacy roles let a lot of that stay vague. IAM does not.

Two practical notes that reduce the work. AWS points out that users who only need Skill Builder for training and certification no longer require Partner Central access at all — which in a large partner organisation can remove a substantial fraction of the list before you start. And the migration itself blocks every user for two to six hours, so it is an out-of-hours job with an internal comms plan attached, scheduled by an alliance lead or cloud admin.

What to do

Migrate — for the reasons that are true. The attribution dashboard, Revenue Attribution IDs, subsidiary account connections and agents are all real, documented and post-migration only. That is a stronger internal case than a date you cannot source, and it will not collapse if the date turns out to be wrong.

Ask your partner manager for the date, in writing.Not “is there a deadline” but “has AWS published a retirement date for legacy Partner Central, and where.” If one exists you will get it, and it will be authoritative. If the answer is vague, that is information too.

Start the IAM mapping now, separately. It is the long pole and it does not depend on when you migrate. Pull the user list, drop the Skill-Builder-only users, and assign policies deliberately rather than giving everyone full access because it is faster — the latter is a decision you will still be living with in three years.

Check any vendor date before you plan around it. The managed-policy changelog is public and dated. So is the migration guide. Ninety seconds of checking is the difference between a plan and a rumour.

Disclosure, because this piece attacks people who sell migration help

Both pages quoted at the top exist to sell migration assistance. So it would be evasive not to say that Wyra has a commercial interest in this too, and a fairly direct one.

Wyra syncs two-way with AWS Partner Central — opportunities moving in both directions in real time, on ACE-native stages — and that runs on the Partner Central API, which is a post-migration capability. Connecting it is a single CloudFormation template rather than an integration project. Our team also helps partners through the migration itself. So: same incentive as the vendors above.

Two things make that a disclosure rather than a defence. The first is that our claim runs the wrong way for us. Urgency sells migration assistance; we are telling you AWS has published no deadline, which removes the urgency. If the goal were to sell help, this is the worst possible article to write.

The second is that everything above is checkable in minutes against two public AWS pages, both linked. That is the standard we would want applied to anyone writing about your ecosystem, and it is the only reason to trust a vendor on a question where the vendor benefits from one answer.

The pattern worth carrying forward

The specific dates matter less than the shape they reveal. AWS is changing partner mechanics quickly — attribution, agents, marketplace retrieval, incentive calculation — and communicating most of it through a portal that requires a login. Public writing about those changes is therefore produced mostly by companies selling adjacent services, and it is not audited by anyone.

The defence is not cynicism, which is just as lazy as credulity. It is a habit: for any dated claim about your ecosystem, ask where it came from, and check whether the primary source says it. That habit takes minutes and it would have caught both of these.

And it is worth applying to this page too. Everything above traces to AWS’s public migration guide and its managed-policy changelog, both linked, both dated, both checkable. If AWS publishes a retirement date tomorrow, this piece is wrong and we will say so here — which is, in the end, the only real difference between a source and a rumour.