One cohort, not two systems for everyone
Shop, market, order date or controlled entry point defines which new returns Returno processes. Every case has one system of record.
Migration offer · no hard cutover
Run Returno in parallel. Prove it before you switch.
The Returno Parallel Launch limits risk and double processing: one explicit Shopify cohort runs through Returno while the incumbent completes in-flight returns. Policy version, webhooks, financial actions and rollback are fixed before the first live case.
Available as a guided Shopify pilot; scope and acceptance criteria are recorded before activation.
The migration product
A switching plan with boundaries, evidence and clear ownership.
Real paths first
Webhook, label, refund, store credit, email and safe retry are accepted on real cases, including expected failure modes.
Increase traffic only with evidence
The cohort grows after agreed quality and operations checks. Existing cases remain with the incumbent through completion.
Four phases
How a Parallel Launch runs.
Each phase is small enough for a safe way back and concrete enough for both teams to know when the next step is approved.
- 01
Map the current process and conflicts
Portal entry, webhooks, Shopify tags, refunds, credit, carriers and open incumbent returns are documented.
Proof: system-of-record matrix - 02
Build Returno as a production draft
Policies, reasons, methods, templates, branding and roles start from the existing policy and an industry preset.
Proof: approved preview + ruleset version - 03
Run real acceptance and rollback
At least one label, refund, credit outcome, email and safe retry run against the real shop. The fallback is exercised.
Proof: signed pilot checklist - 04
Activate and observe the cohort
Only the agreed group moves. Failures, queues, webhooks and shopper cases are observed before traffic grows.
Proof: go/hold/rollback decision
Scope of service
What Returno takes over during migration – and what it does not.
Returno takes care of
- Current-state and Shopify/webhook conflict review
- Translating policy into versioned Returno rules
- Portal, template, branding and role setup
- Test plan, technical acceptance, monitoring and rollback support
The merchant owns
- Access and contacts for Shopify, carrier and incumbent
- Business approval of policy, finance and shopper communication
- Pilot-cohort selection and approval of real test actions
- Decision to expand traffic and eventually retire the incumbent
Not included automatically: migration of open returns or existing store-credit balances. Export, tax treatment, expiry rules and reconciliation are agreed separately.
Switching questions
Can both return portals remain available?
Yes, if entry is routed unambiguously. An order or return must never be processed by both systems. This is tested before the pilot.
What happens to in-flight returns?
By default the incumbent completes them. Returno handles only new returns in the agreed cohort. Moving open cases is a separate reconciliation migration.
Are existing credit balances moved automatically?
No. Credit needs an export, balance reconciliation and explicit tax, expiry and reissue decisions. Without an approved plan it remains in the incumbent ledger.
When can the cohort expand?
After the agreed technical and operating checks are green: webhooks, label, refund, credit, email, retry, support path and rollback.
Switch without flying blind.
Send the shop, incumbent and intended pilot cohort. We reply with a conflict review, acceptance criteria and a concrete Parallel Launch scope.