Two things decide whether your marketplace listings survive a replatform: whether the SKU code on a variant in Shopify is character-for-character identical to the seller SKU on Amazon.ae and the partner SKU in Noon's seller portal, and whether exactly one system owns the stock number. Get those right and a Shopify marketplace integration migration is a weekend of tedium. Get either wrong and you spend the next month cancelling Amazon orders you can't fulfil, watching your pre-fulfilment cancellation rate climb, and wondering why the Buy Box went quiet.
Almost nobody sorts the SKUs out first. We've picked up mid-flight migrations where the theme was built, the checkout was tested, and nobody had exported the Amazon listing report to compare it against the product CSV. That comparison takes an afternoon and it is the single highest-value afternoon in the project.
The order of operations, in one paragraph
Reconcile SKUs across all three systems before you migrate anything. Migrate products and orders to Shopify with the marketplace channels disconnected. Launch the storefront. Let it run for a few days on its own. Then reconnect Amazon, verify inventory pushes on a handful of SKUs by hand, and only after that reconnect Noon. Channels go back one at a time, never together, and never on launch day. Launch day already has enough failure modes.
The temptation to do it all at once comes from a reasonable fear: while a channel is disconnected, its stock levels are frozen at whatever number they were, and every sale drifts you further from reality. That fear is manageable with arithmetic, which we'll come to.
SKU is the join key, and it is fragile
Amazon matches your feed rows on seller SKU. Noon maps your partner SKU to its own internal catalogue identifier. Shopify stores the SKU on the variant, not the product. Any middleware you use joins on that string. It is case-sensitive in some tools and not in others, whitespace counts, and a leading apostrophe added by Excel to preserve a leading zero will silently break a match.
The failures we see repeatedly:
- The old platform stored SKUs at product level and generated variant SKUs by appending a size suffix. The migration flattens them differently, so KURTA-BLU-M becomes KURTA-BLU-Medium and 340 Amazon listings go orphan.
- Someone created listings directly in Seller Central during a stockout and invented a SKU that exists nowhere else.
- Noon holds a listing created from a bulk template two years ago with a partner SKU that has a trailing space.
- Barcodes are populated on 70% of variants and blank on the rest, so you can't use EAN as a fallback join.
Freeze the SKU scheme before migration and do not improve it. If your codes are ugly, keep them ugly. Renaming SKUs during a replatform means re-mapping every marketplace listing at the same time as everything else changes, and when something breaks you won't know which change broke it. Rename in a separate, boring project three months later, if at all.
The reconciliation sheet nobody wants to build
Pull three exports: the Shopify product CSV after a test migration, the Amazon All Listings report, and a Noon catalogue export. Put them in one sheet, one row per SKU, three columns for presence. Then count.
An illustrative run on a mid-size apparel catalogue looks like this. Shopify: 2,840 variants. Amazon.ae: 2,610 active and inactive listings. Noon: 1,930. Exact SKU match across all three: 1,802. That leaves 128 Noon SKUs with no Shopify twin, 808 Amazon SKUs unmatched, and 1,038 Shopify variants that exist on the storefront only.
Most of the Amazon gap is discontinued lines that were never closed out, which is fine — you delete those rows. What matters is the residue. Say 90 of the 808 turn out to be live, selling SKUs whose codes drifted. At an average order value of AED 140 and, generously, one order a week each, that's 90 × 140 = AED 12,600 of weekly revenue sitting on listings your new inventory feed will not be able to find. Those 90 rows are the whole job. Fix them by hand, in the marketplace, before cutover.
We get roughly a third of the ambiguous rows wrong on the first pass and catch them in the second reconciliation a week after go-live. Plan for a second pass.
One system owns stock. Pick it deliberately
If Shopify is your inventory master, every channel reads from it and nothing writes back except order-driven decrements. Clean, and it works well for sellers who self-ship everything from one warehouse.
It stops working the moment you have stock sitting inside Amazon's fulfilment network and inside Noon's fulfilment centre at the same time. Those are three physically separate pools: your own warehouse, Amazon's, Noon's. A single Shopify quantity cannot represent all three, and if you let it try, your storefront will happily sell units that are in a Noon DC in Dubai South and cannot be shipped to a D2C customer without a removal order.
The fix is unglamorous. Create separate Shopify locations for each fulfilment pool and leave them out of the online store's sellable inventory. Sync only the self-ship pool outward to marketplaces as available quantity. Let Amazon and Noon manage their own warehouse stock and reflect it back for reporting, not for allocation. If your integration tool cannot do location-level mapping, that's the feature you should be shopping for, not the number of channels it claims to support.
For sellers with genuinely complex allocation — reserved stock for a marketplace flash deal, kits assembled on demand, more than two or three warehouses — an OMS sitting between Shopify and the channels is usually the right call, and it means Shopify stops being the master. That's a bigger decision than the migration, and it's worth taking it separately rather than bundling it into launch week.
Amazon has a native channel app. Noon does not
Amazon connects through Shopify's own marketplace channel app, and for straightforward catalogues it's adequate. Check the current channel list on the app's Shopify App Store listing before you plan around it, because supported marketplaces change and regional Amazon sites are not always all included.
Noon needs either a third-party connector from the App Store or a direct build against Noon's seller API. Both are viable. The third-party route is faster and you inherit somebody else's rate-limit handling and retry logic; the direct build gives you control over how order status and returns flow back, which matters more than it sounds when you're reconciling.
What we'd push back on: writing your own connector during the migration. Two moving systems is already the hard part. If a paid connector gets you live and you replace it in six months with something custom, that's a good trade. If you want the custom build eventually, our team does that work as a separate engagement — see Shopify app development for how we scope private integrations.
Buffer stock, with the actual sum
Outbound inventory updates from Shopify fire quickly. The delay is on the other side: feed processing, polling intervals, queue depth during peak. Assume worst-case 15 minutes between a sale on your storefront and Amazon knowing about it. On a normal day that's harmless. During a Noon promotion or a White Friday spike, it is not.
Take a hero SKU that moves 30 units in an hour during a flash deal. That's 0.5 units a minute. Over a 15-minute sync gap you can oversell 7.5 units. So the buffer on that SKU is 8, not 2. On a slow-moving SKU selling 30 units a month — about 0.04 units per hour — a buffer of 1 is more than enough, and a blanket buffer of 5 across the catalogue just hides 5 units × 2,800 variants of sellable stock from every channel.
Set buffers by velocity band. Three bands is plenty: fast movers, normal, tail. Recalculate before every promotional peak and after.
Sequencing the cutover so the freeze costs almost nothing
You will need a window where marketplace inventory is stale. Price it before you argue about it.
A store doing AED 22,000 a day on Amazon.ae, with roughly 4% of daily orders landing between 2am and 6am Gulf time, is exposing 22,000 × 0.04 = AED 880 of orders to a four-hour freeze. Not all of those oversell — only the ones where stale stock exceeds real stock. The realistic exposure is a fraction of AED 880. That is a rounding error against the cost of rushing the cutover and getting the SKU mapping wrong.
Practical sequence for the window: pause new listings and price changes, take a final inventory snapshot from the old platform, complete the Shopify migration of products and inventory, spot-check 20 SKUs by hand across the three systems, then enable the Amazon connection with pushes on and watch the first feed submission report line by line. Noon follows a day or two later.
One thing that catches people: unfulfilled marketplace orders imported into Shopify will decrement inventory again if the old platform already decremented it. Import historical orders as fulfilled or with inventory tracking off for the import, then set your opening stock from a physical count. A stock count of a 2,800-SKU warehouse is a day of work. Do it anyway. Every number downstream depends on it.
The first fortnight is where the money is
Reconcile daily for two weeks: for each channel, count active listings, count listings receiving inventory updates, and list the difference. The gap should shrink each day. If it doesn't, something in the mapping is failing silently, and marketplace connectors are extremely good at failing silently.
Watch three signals. Pre-fulfilment cancellations on Amazon — the threshold is low and it's the metric that costs you the Buy Box, so check the current figure for your marketplace in Seller Central rather than trusting a number in a blog post. Noon's order acceptance and dispatch SLA, because a stock-driven cancellation there hits your seller score too. And your own storefront's out-of-stock rate, which will look artificially high for a week if your buffers are set too fat.
Pricing is a separate reconciliation and it's easy to forget during migration. Marketplace prices usually carry different margins to account for commission, and Amazon.ae and Noon both display prices inclusive of 5% VAT. If your integration syncs the Shopify price straight through, you'll be selling on both channels at storefront margin. Either set channel-specific price rules in the connector or accept that you're repricing manually, and be honest about which.
Where a mid-flight replatform genuinely goes wrong
Bundles and kits. A three-pack listed as a single SKU on Amazon draws down three units of a component in Shopify, and almost no connector handles that natively. You either list bundles as real Shopify products with their own tracked inventory and manage the component maths yourself, or you don't sell bundles on marketplaces during the migration.
Multi-location sellers with stock in both the UAE and India shipping cross-border into Amazon.ae have a second problem: lead times differ by pool, and marketplace handling-time settings are per-listing, not per-location. That usually forces a decision to serve marketplaces from one origin only.
And variants that exist on Shopify but were never listed on either marketplace will now get created automatically by some connectors, which is how sellers discover they've listed 400 products on Noon at the wrong price. Turn off auto-create. Publish deliberately.
If you're partway through a replatform and the marketplace side hasn't been mapped yet, the useful next step is the reconciliation sheet described above — three exports, one afternoon, before you touch anything else. If you'd rather someone else ran it, our Dubai team does this as part of a store audit, and we'll tell you plainly if the answer is to delay the cutover by a fortnight.