How to Migrate a Client From Another Fulfilment Agent

Migrate for the reliability problem, not the cheaper quote

When a client asks you to move fulfilment, the word you will hear is "cheaper". The reason the account is actually at risk is usually reliability: parcels went out late, exceptions were handled silently, a lost-parcel claim died in a chat thread with no evidence attached. Price is what the client says out loud. Reliability is what broke. If you migrate for the headline number and the new route stumbles the same way, you have spent the relationship's goodwill twice and fixed nothing.

So diagnose before you move anything. Ask the outgoing setup three questions and insist on real answers: what was the actual dispatch time on the last hundred orders, not the promised one; how many orders are open right now; and what happened the last time a parcel went missing. A migration that fixes late dispatch or dead-end claims is worth running. A migration that only shaves a point off unit cost, on a route that already delivered on time, is a lot of risk for a number your client will never feel.

Judge the new agent on the same axis you are leaving the old one over. Response speed is part of reliability and it is measurable: our own median first reply is 23 minutes in working hours, with the honest other half that about one in five in-hours messages still take more than half a day. See the response-time note. Hold any provider to a figure they will state that plainly.

Capture everything the outgoing agent holds, before anyone gives notice

The single rule of a clean migration is to extract while access still exists. The day a client gives notice, cooperation drops and records start to disappear. A new agent inherits the quality of the old agent's records: where a supplier trail does not exist, you cannot recreate it by asking harder, and the product has to be re-sourced from scratch. Get all of this into a file you control before the outgoing agent is told anything:

• The open order list: every paid-but-unshipped order with its current status.
• Tracking numbers and the carrier for every in-transit parcel, so you can keep answering end customers through the move.
• Supplier references and full product specs: the exact SKU, variant, material and packaging spec for every product you intend to keep selling.
• Any pre-stock the outgoing agent is holding, the quantity, and who owns it.
• The open balance: prepaid credit, deposits and unbilled fees. Money left on a dying account is hard to get back once the relationship sours.
• The store connection itself: which app or collaborator account is pushing tracking, so you know exactly what to disconnect later.

Move one small product set first

Do not cut the whole catalogue over in a weekend. Pick one product to migrate alone, ideally a steady seller with predictable volume on a route you already understand. Connect the store to the new backend for that SKU only, place real orders through it, and watch them all the way to delivery. A small first set means a mistake costs one product's orders, not the account.

Decide who applies tracking before the first order runs. Shopify and WooCommerce connect two-way automatically: orders pull in and tracking uploads back to the store, which fires the store's own shipping notification. On TikTok Shop, eBay and Etsy the tracking number is sent to you to apply on your side, so name the owner of that step now rather than in the middle of a live order. The connection detail is on platform integrations.

Keep the old route live until the new one has proven itself

This is the part sellers get wrong and agencies cannot afford to. Do not switch the old agent off the day the new one is connected. Run both in parallel: the pilot product on the new route, everything else still on the old one. Route new orders for the pilot SKU to the new backend and leave the rest where they are. You widen the migration only once the pilot has passed, and passed means measured, not felt.

What "passed" actually looks like

A route has proven itself when it has handled the normal case and at least one bad case. Before you move the next product, confirm all three:

• Live orders dispatched inside the window you were quoted. Treat that window as a route-specific estimate, never a guarantee, and hold the new agent to the same honesty you are leaving the old one for.
• Tracking events flowing back into the store correctly, so you and your client read each scan the same way.
• At least one exception run to ground: a delayed parcel, a bad address, or a test claim. You want to watch the new agent handle the exact kind of thing the old one failed at.

If you cannot fault-test a route, you have not proven it. The same seller-side references your client already reads, tracking status meanings and the order issue centre, are the material a partner works from, so line your exception checks up against them instead of inventing a private standard.

Protect against stocking out in the middle

The failure mode of a careless migration is a gap: the old agent has stopped taking orders for a SKU, the new one is not fully live, and the product goes out of stock during the handover. On pure dropship the usual risk is sourcing not yet confirmed on the new side, so confirm the supplier and the route on the new backend before you divert a single order to it. Where your client pre-stocks, do not let inventory strand on the outgoing agent: migrate the stock, or run it down deliberately on the old route while the new route ramps, so the two overlap instead of leaving a hole. Time the cutover to demand, not to your admin calendar. Never over a weekend, and never into a peak.

The stock-timing mechanics your client will want to see are set out on the seller-side guide, switching fulfilment agents without stocking out. Point them there for the operational detail rather than re-explaining it in your own words, and keep your own note to the agency decisions: sequence, timing and who owns each cutover.

Decide who holds the account before the client sees anything new

Settle the commercial shape first, because it changes what your client experiences during the move. Through the Agency Desk, two structures put you in front: on Co-Manage and White Label your agency holds the contract, invoices the client, sets the price and takes first-line support, and RyanFulfil invoices you and runs the China side. On the Refer path RyanFulfil contracts, invoices, supports and prices the seller, and the quote it issues discloses your commission.

On the priced paths you name the commission and it is added into the quote we issue, with guidance around 2%, the level that keeps your client's landed cost competitive against buying direct. Fulfilment runs DDP on most routes, out of Guangzhou, on 4PX, YunTu and Wanbang. None of that changes because the account arrived by migration rather than as a fresh onboarding.

Register the client so the account is recorded as protected under client protection. And be straight with your client about the limit of white label: it is a tested operating configuration, not a logo switch. Some touchpoints stay visible whatever you configure: the carrier and the shipment origin, customs and export documents, the bank beneficiary wherever money moves directly, store app or collaborator access, and the return address. Configure what can be configured, and tell your client the rest before they find it themselves in a tracking event.

The order to run a migration in

• Diagnose the real failure. It is almost always reliability, not the headline price.
• Capture orders, tracking, supplier specs, stock and balances while access still exists.
• Choose the commercial path and register the client so the account is protected.
• Connect one small product set to the new backend and place live orders through it.
• Keep the old route live for everything else, running in parallel.
• Confirm dispatch inside the quoted window, tracking flowing back, and one worked exception before you widen.
• Widen product by product, timing each cutover to demand so nothing stocks out.
• Retire the old agent only when the last SKU has passed and its open balance is settled.

If you have a client migration coming up, apply for founding partner access. Tell us the product set, the current route and the open-order count, and we will tell you which path fits before you give notice to anyone.