A cloud marketplace integration has three parts with very different durations: configuring the listing (about an hour), connecting your marketplace account to the tooling that will run it (about twenty minutes), and the marketplace’s own review of your submission (weeks). Only the third one is on the critical path, and none of it is under your control.
An engineering lead asked to scope marketplace work against a launch date usually gets one of two useless answers: “it’s just a connector” or “allow a quarter.” Both are true about different parts of the job.
The useful answer separates the hands-on work from the waiting, because they are budgeted differently. Hands-on work consumes engineering capacity. Waiting consumes calendar. A plan that confuses them either over-staffs the project or misses the date.
Below is the breakdown from Suger’s published integration timeline, plus the part of the work that timeline cannot estimate — because it happens inside your product.
How long does it take, in one table
A net-new listing runs about three weeks on AWS and Azure, and about four weeks on Google Cloud — and the overwhelming majority of that is the marketplace’s review queue, not work.
| Step | AWS | Azure | Google Cloud |
|---|---|---|---|
| Create listing details | about an hour | about an hour | about an hour |
| Connect the marketplace account | about 20 minutes | about 20 minutes | about 20 minutes |
| Marketplace review | about 2 weeks | about 2 weeks | about 3 weeks |
| Net-new total | approx. 3 weeks | approx. 3 weeks | approx. 4 weeks |
| Migrating an existing listing | approx. 5 days | approx. 5 days | approx. 5 days |
The connector step is against AWS Marketplace, Azure Partner Center, and the GCP Producer Portal respectively. Adjacent connections are in the same range: the Salesforce connector at about an hour, the HubSpot connector at about ten minutes, and AWS APN for co-sell at about thirty minutes.
Read the table as roughly ninety minutes of hands-on configuration sitting inside a multi-week calendar. If your plan has an engineer blocked for three weeks, the plan is wrong.
What blocks what
The sequence matters more than the durations, because one ordering mistake adds a review cycle.
1. Seller account, tax, and banking. Blocks everything. Involves finance and sometimes a bank, so it has an external wait of its own. Start it first, always.
2. Pricing model and dimensions. Blocks listing creation. Also close to irreversible — Microsoft states the pricing model can’t be changed after publication, AWS once the listing is published to limited — so a wrong choice here is not a delay, it is a second listing.
3. Listing content and legal. Blocks submission. Copy, categories, support terms, and the contract path. Marketing and legal both need lead time; neither is on your team.
4. Product integration. Does not block submission on most listing types, and this is the ordering people get wrong. You can usually submit for review while the entitlement and metering work is still in flight, which moves weeks of queue time in parallel with weeks of engineering.
5. Marketplace review. Blocks public availability. Nothing you do shortens it; a rejected submission restarts it, which is the real argument for care rather than speed at step 3.
6. First offer. Blocks knowing whether any of it works.
The practical rule: anything with an external wait starts on day one, and anything internal happens during the waits. That is the difference between a three-week integration and a nine-week one.
The part the timeline can’t estimate
Configuration is bounded. The engineering inside your own product is not, and it is where scope actually lives.
Three pieces of work, in ascending order of effort:
Resolving the buyer. When someone subscribes, the marketplace hands your landing page a token that you exchange for a customer identifier. Small, well-documented, and unavoidable.
Granting and revoking access. Your product has to react to subscription and entitlement events — a new contract, an upgrade, a renewal, an expiry, a cancellation — and change what the customer can do. This is where most of the effort goes, because it touches your own account model, and where the expensive failures happen. When a buyer pays but provisioning never happens covers those failure modes; offer vs entitlement covers the two record types you are wiring together.
Metering, if you are usage-priced. Only relevant on usage-based models, and materially larger than the other two: you are now responsible for transmitting billing records, and records you fail to send are revenue you do not collect.
A useful scoping question: does the product already have a concept of a subscription that starts, changes, and ends, driven by an external system? If yes, this is days. If access is currently granted by a human in an admin console, it is weeks, and no marketplace tooling changes that.
Some listing types add a technical review of their own — the AWS Foundational Technical Review is one, covered in scaling IT operations with AWS FTR. Check whether yours needs one before you promise a date.
Migration is a different project
Moving an existing listing is roughly five days rather than three weeks, because the listing already passed review. On AWS the work is the connector — about twenty minutes — plus updating fulfillment URLs, at about three days.
That asymmetry is worth knowing at planning time: if a listing already exists somewhere, you are not scoping a launch, you are scoping a redirect. The multi-week review queue is not in your path at all.
What actually makes it take longer
Every overrun we see traces to one of five things, and none of them is the connector.
A rejected submission. The review restarts. Incomplete support terms, category mismatches, and missing security documentation are the usual causes — all of them content problems, all of them cheaper to fix before submission than after.
The pricing model changed after submission. Which on AWS and Azure is a new listing, not an edit.
Legal arrived late. The contract path decision needs legal, legal needs notice, and the request usually goes out when a real deal appears rather than in week two.
Nobody owns it. A project split across engineering, alliances, marketing, finance, and legal with no single owner moves at the speed of the slowest inbox.
Every marketplace at once. Each with its own console, vocabulary, review queue, and edge cases, learned simultaneously by people who have not done any of them once.
If you want the calendar view of the whole quarter rather than the integration alone, your first 90 days on a cloud marketplace lays out the milestones with owners.
Frequently asked questions
How long does an AWS Marketplace listing take? A net-new AWS listing runs about three weeks end to end: roughly an hour to create the listing details, about twenty minutes to connect the marketplace account, and about two weeks in AWS’s review queue.
How long does a Google Cloud Marketplace listing take? About four weeks for a net-new listing, with roughly three weeks of that in Google’s review. The hands-on configuration is the same order as the other marketplaces.
Can I shorten the marketplace review? No. The queue belongs to the marketplace. What you control is submitting a complete, accurate listing the first time, since a rejection restarts the wait.
Does the product integration have to finish before submitting? Usually not. On most listing types you can submit for review while entitlement and metering work continues, which runs weeks of queue time in parallel with engineering.
How long does migrating an existing listing take? About five days, because the listing has already passed review. On AWS the work is the connector plus updating fulfillment URLs, at roughly three days.
What is the biggest variable in the estimate? Your own product. If it already models externally driven subscriptions that start, change, and end, integration is days. If access is granted manually today, it is weeks.
Takeaways
- Roughly ninety minutes of configuration sits inside a three- to four-week calendar. Budget capacity and calendar separately.
- The marketplace review queue is the critical path, and nothing you do shortens it. A rejection restarts it.
- Product integration usually does not block submission — run them in parallel and save weeks.
- The unbounded part is inside your product: resolving the buyer, granting and revoking access, and metering if you are usage-priced.
- Migrating an existing listing is about five days, because review has already happened.
- Overruns come from rejected submissions, late legal, and no single owner. Never from the connector.
An integration is short; the coordination around it is not. See how product listing in Suger keeps listings, dimensions, and terms consistent across every marketplace from one definition — so the second listing is a copy, not a project.
Sources
Primary sources for the platform rules cited above. Last verified August 10, 2026. Cloud providers change fees, eligibility, and program terms without notice — check the source before relying on a figure.
- Suger integration timeline — Every duration in the step-by-step table, per cloud
- Suger: get started — The onboarding steps the timeline sequences
Stay Updated
Get the latest Cloud GTM insights, product updates, and marketplace strategies delivered to your inbox.