This checklist belongs to the returns platform replacement guide. The questions are first asked in the 30-minute meeting agenda; this page carries them through to the day the old app goes dark.
Fixing the countdown dates
A countdown is only useful if its dates are real. Write down the three dates the brand has documented and where each came from before you mark any item.
| Milestone | Where the date usually comes from | If no date exists yet |
|---|---|---|
| Announcement | The project kickoff note or the agency statement of work | Start milestone one with the owner and operations lead |
| Cutover | The new app's go-live plan | Record who decides go-live and come back when it is set |
| Switch-off | The old app's subscription term or cancellation notice | Leave it open; the item becomes "confirm the contract end" |
Every item gets one of three states: confirmed (a responsible person said so), unknown (with a name for who will find out) or at risk (the current plan loses it). Do not confirm an item because a settings page suggests it; ask the person who owns it.
Keep the record in a simple sheet shared only with the people who answered. It describes systems, owners and plans. No order numbers, customer names, photos or refund amounts belong in it.
Cadence. Review the sheet in the regular project status call, as one standing line rather than a separate meeting: "Any change to the history items?" That keeps the questions alive without adding work, and it puts open items in front of the people who can close them.
Phrasing. Ask for descriptions, never for proof. "Where would that be recorded?" works; "Can you send me one?" does not. If someone offers to share a screen or a file, thank them and decline. The point is to know what exists and who owns it.
Escalation. If an item stays unknown across two status calls, raise it with the owner directly. Silence on a history question usually means nobody owns it, which is exactly the gap the checklist is there to find.
Milestone one: before the switch is announced
Nothing has been decided yet about the old app's history, which makes this the easiest moment to ask.
| Confirm | Owner | What happens if it is skipped |
|---|---|---|
| Roughly how many returns per year are graded and recorded, and for how many years | Operations lead | The history cannot be described with any shape |
| Where the customer's own words about each return are stored | CX or ecommerce manager | Instructions are assumed to migrate when they may not |
| Whether refusals carry a recorded reason | CX manager | The approval step of the chain has unknown gaps |
| Who can authorize a licensing discussion about the brand's records | Founder or CEO | An interested brand has nobody able to say yes |
Milestone two: before cutover to the new app
Import scope decides what survives in usable form. Closed returns are easy to leave out.
| Confirm | Owner | What happens if it is skipped |
|---|---|---|
| Whether the new app imports closed returns or only open ones | Agency project lead | Years of decided returns stay in the old app only |
| Where condition grades, photos and inspector notes live | Warehouse or 3PL lead | The middle of the chain is lost or stranded |
| Whether a 3PL performs inspection, and that its agreement exists (not its contents) | Operations lead | Rights to inspection records are unclear later |
| Whether manual refund overrides carry a recorded reason | Finance lead | Exceptions cannot be told apart from routine refunds |
Two rows above depend on what the store platform keeps without any app. Shopify's own record covers the status trail, from requested through opened, declined or closed after every item gets a restock decision, plus an internal-only decline reason the shopper never sees. So for the refusal row, the useful follow-up at cutover is whether staff pick a reason every time or skip the field when busy; for the grades row, it is whether anything about condition ever reaches Shopify at all. Background, not a deadline: Shopify added return processing in API version 2025-07 and asks existing returns apps to move to it, so some brands revisit their app around now. Only the brand's own contract sets a date.
ShopifyMilestone three: before the old app is switched off
Once the subscription ends, whatever was not exported or archived may be gone.
| Confirm | Owner | What happens if it is skipped |
|---|---|---|
| The exact access end date under the old app's contract | Founder or finance lead | The team discovers the end date after it has passed |
| Who can export history from the old app, by name | Owner | Nobody has the rights or knowledge to export in time |
| Where exported returns history will live and who can access it | Operations lead | The history exists but is unreadable or lost in a drive |
| Whether inspection spreadsheets or warehouse records are kept with it | Warehouse lead | Grades and photos are separated from the returns they explain |
The ERP replacement handoff checklist and the email platform migration checklist apply the same logic to other systems, and the quality inspection records checklist looks at inspection evidence more broadly.
Reading the finished checklist back to the owner
Illustrative. A 160-person home goods brand on Shopify Plus, selling ceramic dinnerware, rugs and bedding, completed all three milestones. Its hardest items were breakage claims, where the shopper's photo of a cracked plate replaces any warehouse inspection, and oversized rugs collected by a freight carrier and graded days later at a returns hub. Its summary for the founder read:
| Area | State | Note |
|---|---|---|
| Return volumes and years | Confirmed | Four years of graded returns |
| Customer instructions | Confirmed | Reason and comment on every return in the app |
| Decline reasons | Confirmed | Recorded consistently from year two only |
| Inspection grades and photos | At risk | Hub grades for rugs and breakage photos in the old app; not in the import scope |
| Refund overrides | Confirmed | Reason recorded by finance |
| Old app access end | Confirmed | Contract term known; export owner named |
That is a sound metadata-level description. If the founder wants to explore licensing:
Disclose. You are a SourceX referral partner. If a qualifying license completes and every payment condition is met, SourceX may pay you a reward that is funded separately and never deducted from the brand's payout. SourceX licenses approved business data directly from companies for AI training and evaluation, and manages agreement, rights review, data preparation, delivery and payout.
Check fit. 50+ full-time employees at peak (contractors excluded; 3PL staff do not count), a documented operating history, rights to license the records, and an authorized contact. Companies in the U.S., Canada and the EU qualify, as do companies in the UK, Australia, New Zealand, India, Singapore, South Africa, Latin America, the UAE and Saudi Arabia when at least 90% of the data is in English. SourceX's current data needs, the rights review result and any offer stay unknown until SourceX reviews an application.
Introduce. Use the annotated introduction email. Sign the Channel Partner Agreement first. Attribution goes to the first valid introduction within the 90-day window, credited when the company submits a verified application, with one partner per company. Illustrative only: a $40,000 qualifying payout to the brand would mean a $10,000 default reward. The rewards page lists every condition, and the ecommerce industry page covers the wider sector.
Next step
Refer a company. Earn up to $100,000. Default reward: 25% of Actual Supplier Payout, capped at $100,000 cumulatively per referred company. Eligibility and payment conditions apply, and a signed Schedule A or addendum can differ. A lead, meeting or signature alone does not trigger payment.
If the checklist shows the chain survives switch-off and the founder wants to talk, register as a partner, check who qualifies, and read the program terms before you make the introduction.