Switching Shipping Guarantee Apps Mid-Year Without Losing Open Resolutions: A Migration Checklist

The hardest part of switching shipping guarantee providers is never the new app install. It is the orders placed under the old provider that still have open resolutions in flight the day you flip the switch.

Why the Cutover Date Is the Real Risk

Every order placed before your cutover was sold a guarantee by your old provider, under their terms, with their resolution process. Some of those orders are still in transit. Some already have a lost or damaged package resolution sitting open.

If you deactivate the old provider before those resolutions close, the customer who paid for a guarantee on that order has nowhere to go. That is the scenario to design around: not "how do we install the new app," but "how do we make sure nobody who paid for a guarantee loses it because of our timing."

The second risk sits right next to the first one. If there is any gap between turning off the old checkout widget and turning on the new one, orders placed during that window were sold nothing at all. Customers paid a shipping fee and got no guarantee behind it, and you will not find out until one of them files a resolution.

Neither risk shows up on launch day. They surface weeks later, when a package that shipped during the transition goes missing and support cannot find a matching guarantee anywhere. By then the order history has moved on and the fix is a manual, case-by-case cleanup instead of a five-minute reconciliation. Planning the migration around these two failure points up front is what avoids that cleanup entirely.

Step One: Pull a Full Export From the Old Provider Before You Touch Anything

Before you change a single setting, export everything from your current provider while your account access is still active. That means every order that had a guarantee attached, every open resolution and its status, and the guarantee terms and payout structure that applied to each order.

This export is your source of truth for the transition period. Once you cancel the old subscription, you may lose access to this data entirely, and there is no way to reconstruct a customer's resolution history after the fact.

Save this export somewhere your support team can reference for at least the length of your longest shipping window, typically 60 to 90 days past the cutover date.

Step Two: Separate Orders Into Three Buckets

Every order in that export falls into one of three groups, and each one needs a different plan.

Orders with no issue and no open resolution need nothing further. The guarantee period on those orders simply runs out under the old provider's terms as the delivery window closes.

Orders with an open resolution need to stay in the old provider's resolution process until closed. Do not attempt to move an in-progress resolution into your new provider's system. Resolutions are tied to the terms and payout structure the customer originally agreed to, and moving them mid-process creates a support headache with no clean fix.

Orders that are still in transit but have no reported issue yet are the group to watch closely. They need to remain covered by the old provider's guarantee terms through delivery, even after your new provider is live on the storefront, because that is the guarantee the customer actually purchased.

Step Three: Decide the Cutover Moment, Not Just the Cutover Day

A mid-year switch fails when a team treats it as an event and not a specific timestamp. Pick the exact moment the old checkout widget comes off and the new one goes live, and make sure there is zero gap between them.

The cleanest approach is a same-session swap: deactivate the old widget and activate the new one in the same maintenance window, ideally during your lowest order-volume hours. Test a checkout end to end immediately after the swap to confirm the new guarantee is actually attaching to orders before you walk away.

Do not schedule the storefront swap for a different day than the backend cancellation of the old app. If the old provider's checkout widget is still live after you have effectively moved on, or if it goes dark before the new one is ready, that gap is exactly where uncovered orders happen.

Step Four: Decide What Customers Actually Need to Know

Most customers do not need an email announcing a shipping guarantee provider change. What they need is for their resolution to work the way it was supposed to when they file it.

The exception is any customer with an open resolution at the time of cutover. If your old provider's support channel or resolution portal is changing or going away, tell that specific group directly, with a clear point of contact until their resolution closes. Silence there is what turns a backend vendor swap into a support complaint.

For everyone else, ShipAid's branded resolution flow runs inside your own store experience rather than a third-party portal, so going forward there is no portal switch for customers to notice at all. The change is invisible to a customer placing a new order after cutover.

Step Five: Confirm There Is No Coverage Gap Before You Call It Done

Before closing out the migration, reconcile order by order for a short window around the cutover: every order placed in the 24 to 48 hours before and after the switch should have exactly one active guarantee attached, from exactly one provider.

Flag anything with zero guarantees attached or, less commonly, two. Both are signs the cutover timing slipped, and both are fixable quickly if you catch them in the first few days rather than weeks later when a customer files a resolution on an order that was never actually covered.

This reconciliation step is the difference between a migration you can defend and one you are guessing about. It takes an afternoon to run and it is the only way to know, with certainty, that the switch did not quietly leave a stretch of orders without a guarantee from either provider.

Once that reconciliation is clean, keep the old provider's export on file until every in-flight resolution and every in-transit order from the old system has fully closed out. That is the real end of the migration, not the day the new widget went live.

Give Support One Owner and One Reference Sheet

Whoever answers customer messages during the transition needs a single place to check which provider covers a given order. Without that, a support agent can end up telling a customer their resolution is with the wrong provider entirely, which turns a routine migration into a trust problem.

A simple reference works fine: the cutover date and time, the old provider's export, and a note on where open resolutions currently stand. Give this to your support team before the cutover happens, not after the first confused customer message arrives.

Assign one person to own the migration itself, even if support is handled by several people day to day. A clean mid-year switch depends on someone tracking the export, the cutover timing, and the reconciliation step as one connected job, not three separate tasks that different people assume someone else is handling.

ShipAid's Shipping Guarantee runs resolutions inside your own store experience, making it a clean landing spot for merchants migrating off another provider mid-year without a coverage gap.