Most of the guidance published this year treated two AWS changes as unrelated items on a compliance checklist: move to the new Partner Central, and configure Partner Revenue Measurement. They are not unrelated. One is a prerequisite for the other, in a fixed order.
The first date has now passed. The second is about two weeks away. If you tackled them in parallel, this post explains why that stalled and what is still recoverable.
The dependency nobody puts up front
Partner Revenue Measurement (PRM) credits you for the AWS consumption your software and services drive. For most product types it works by tagging AWS resources so AWS can attribute the spend on them to you.
Before you can tag anything, AWS asks you to get your account structure in order. Its resource tagging prerequisites recommend creating and linking an AWS account to represent your global business, then connecting each of your individual AWS Marketplace accounts to that primary account using Subsidiary Account Connections.
Here is the part that catches people. Subsidiary Account Connections are only accessible after you have migrated to the new Partner Central experience.
So the order is fixed:
- Migrate to Partner Central in the AWS Console
- Link and connect your accounts via Subsidiary Account Connections
- Deploy PRM tagging
- Check your coverage
Step 3 cannot be brought forward. Any plan that scheduled PRM work in parallel with the migration was going to stall at step 2.
What each date is
Partner Central migration — reported as June 30. AWS is retiring the standalone Partner Central portal and folding it into the AWS Management Console, with IAM-based sign-in replacing the old credentials. AWS documents the mechanics but does not publish a cutoff date on its migration page. The date circulating all year came from partner tooling vendors, including WorkSpan, which describes itself as an official launch partner. Their account of the consequences is consistent across sources: partners who have not migrated cannot submit opportunities, accept co-sell engagements, approve reseller relationships, or reach their solution metadata.
PRM setup — end of this month. The consequence here is quieter and worse: nothing breaks, you simply stop being credited.
Note the one-month gap between them. It was never enough time to do both from a standing start, because the migration needs scheduling and the account-connection work sits between the two.
If you have not migrated
You are locked out of the co-sell motion, not merely inconvenienced. Opportunities you cannot submit earn no cloud-seller attention, which means no quota credit for the AWS account team working your deal, which means the thing that makes marketplace co-sell work is switched off.
Two things to know before you start, both covered in more detail in the migration post:
- The migration cannot be reversed. Once you begin, there is no going back.
- Account linking becomes permanent. Before migrating you can unlink and relink a different AWS account. After migrating you cannot change it.
That second point deserves a pause even under time pressure. The account you link becomes the foundation for attribution afterwards. Pick the account that will plausibly still be your primary in five years — not whichever one your first marketplace listing happens to live in. Rushing this to hit a date is how companies end up permanently attached to the wrong account.
The cutover itself is short: AWS says it typically takes two to six hours. The work is in the preparation.
One useful exception if you are mid-project on CRM integration: upgrading from the S3-based integration to the API-based one does not require migrating first. Those two tracks are genuinely independent.
If you migrated but have not finished PRM
This is the more common position, and the easiest to misread as “done”. Migration completed, boxes ticked, no error anywhere — because PRM does not produce errors. It produces a smaller number.
The rule is blunt: untagged spend does not count toward your attribution, no matter how real the customer engagement behind it was. There is no retroactive credit for consumption that was not tagged while it happened. Which is why the remaining two weeks matter more than they look: every day without tagging is attribution you cannot recover later.
What to check, with the detail in PRM tagging in practice:
- Are your Marketplace accounts actually connected via Subsidiary Account Connections, or did the migration finish and that step get skipped?
- Are you using the current tag key? AWS directs partners to
aws-apn-id-<partner-central-aws-account-id>for all future attributions, including single-partner cases. - Do newly created resources get tagged, or only the ones that existed when someone last ran a script?
- What is your coverage percentage, per account? Without that number you are guessing.
If you sell AMI or machine learning products through AWS Marketplace, attribution for those happens automatically on purchase and use, with no implementation on your side. The tagging work is for consumption your solution drives around the purchase.
The part that keeps costing people
Tagging is not a project you finish. It is a state you maintain across accounts you do not control, as those accounts change. A one-time tagging pass measures the week it ran.
That is the shape of the problem CloudX’s PRM tagging addresses: one CloudFormation stack per target account, automatic discovery and tagging of supported resources, continued tagging as new resources appear, and coverage reporting per account so the number is visible rather than assumed. It requires your AWS accounts to be connected in the new Partner Central first — the dependency this whole post is about.
If you are untangling the order of operations for your own estate with two weeks on the clock, our advisory service exists for exactly this, and co-sell covers what sits on top once attribution is working.
What to take from this
The two deadlines were presented as parallel. They were serial, and the gap between them was narrow. If your attribution numbers look lower than your pipeline suggests they should, the cause is usually not a measurement error on AWS’s side. It is a step skipped in the middle of a chain nobody drew out.