We make a Shopify registry app, so we've done these migrations and we'd like you to do one with us. That's the bias. What follows is app-agnostic, because the constraints below aren't ours: they come from how registries work on Shopify, and they'd apply if you moved to a competitor instead.
Most of what you read about switching registry apps is either a sales page or a support article about one specific product. This is the field-by-field version. Read it before you ask your current provider for an export, because knowing what to ask for is most of the job.
The two fields everything hinges on
Every other field on this page is a nice-to-have. These two are not.
Registrant email. A migrated registry doesn't arrive already attached to a Shopify customer account, because the export has no way to tell us which customer record it belongs to. It's claimed by its owner the first time they sign in, by matching their email address against the registries waiting to be claimed. No email means a registry sitting on your store that its own registrant can never take control of. They can't rename it, add to it, or see who bought what, and there's no way to fix it afterwards short of editing the underlying data.
Item SKU or barcode. Every item on a registry has to point at a real variant in your Shopify catalog, because that's what makes it purchasable. When the source platform isn't Shopify, its internal product IDs are meaningless to us, and SKU is the only bridge. An item with no resolvable variant can't be imported at all. Product name is a fallback, but it's a fuzzy one, and on a catalog with colour and size variants it's frequently ambiguous.
What always transfers
Assuming the export contains them, these carry across from any source:
Registry names and the registrant's own description or message. Event type and event date. Registrant name and co-registrant name. Every item on the list, with the quantity requested. Shipping address and phone where the export carries them. The source app's own registry identifier, which matters more than it sounds and is covered below.
That last one deserves a sentence. We keep the old app's identifier on each migrated registry rather than discarding it. That's what makes it possible to point old shared links at the right registry afterwards, which is a whole article of its own on what happens to your customers' existing links.
What never transfers
Registry passwords. Not from any app, to any app, in either direction. Passwords are stored hashed, which means the app holding them can't read them either. There's nothing to put in an export. Registrants set a new one after the move, and this is worth a short email to the affected list rather than letting them discover it.
Item ordering and app-specific fields. How a registrant arranged their list, and any custom fields that exist only in the source app's own schema, arrive normalised rather than preserved.
Anything not in the export. Obvious, and still the one that catches people. If a piece of information is visible in your current app's admin but isn't in the file they hand you, it doesn't exist as far as the migration is concerned. This is why you ask for the export before you promise anything internally.
Old registry URLs, on their own. They stop resolving when the previous app is uninstalled. They are recoverable, with a redirect file, but they don't survive by themselves.
What sometimes transfers, and why it varies
| Usually survives | Depends on the export | |
|---|---|---|
| Registry names, dates, event types | Yes | No |
| Items and requested quantities | Yes | No |
| Registrant and co-registrant details | Yes | No |
| Shipping addresses | No | Yes |
| Gifted progress on in-flight registries | No | Yes |
| Buyer names against each purchase | No | Yes |
| Registry passwords | No | No |
| Item ordering and custom fields | No | No |
The variation is almost entirely in one row.
Why gifted progress is the hard one
When a guest buys something off a registry, the registry has to remember it, or the next guest buys the same thing. That memory is the thing most likely to be lost in a migration, and the reason is structural rather than lazy.
Gifted progress isn't a number stored against an item. It's derived from the actual orders attached to the registry, which is what makes it correct rather than approximate, and what lets a registrant see who bought what. So a spreadsheet column saying "3 purchased" has nowhere to live. It has to become order records, and those can only be reconstructed where the purchase went through your Shopify store and can still be matched back to the right registry and the right item.
Some source apps export purchase records that make this straightforward. Others export a count, or nothing at all, and then it's a reconstruction job against your Shopify order history.
Push hard for purchase records when you ask for the export. It's the field most likely to be omitted and the one whose absence your customers actually notice.
What to ask your current provider for
Keep the ask short. You're relaying it to a provider who has no particular incentive to help, and a long specification invites either a stall or a hand-curated subset that's missing exactly what you needed. Ask for the essentials, tell them not to tidy anything, and sort out the mapping afterwards.
Something close to this works:
We're moving our gift registry data and need an export, ideally CSV or a spreadsheet. The essentials are: registrant name and email address, event type and event date, the items on each registry with SKU or barcode and the quantity requested, and anything already purchased off a registry. Please send it exactly as it comes rather than reformatting or cleaning it up. If it contains more than the above, better still.
Two files joined on a registry identifier is the easiest shape to work with. One flat file with a row per item and the registry columns repeated is equally fine. Raw beats tidy every time, because tidying is where the column you needed gets dropped for looking redundant.
Questions, answered honestly
- Can we migrate without registrant email addresses?
- The registries will import, and their owners will never be able to claim them. That's usually worse than not migrating those registries at all, so it's a decision to make deliberately rather than discover.
- What if our source app isn't a Shopify app?
- Then its product IDs are meaningless here and SKU or barcode is doing all the work. Everything else on this page applies unchanged. Off-platform sources are also the case where product names are most likely to be the only identifier, which is where matching gets fuzzy.
- Is there a self-serve importer for this?
- Not with us, and we'd be sceptical of one anywhere. The parts that go wrong are catalog matching and purchase reconstruction, and neither is something a merchant can usefully debug from an upload screen. We run it with you from the export.
- Should we migrate closed or past registries too?
- Usually yes, and it's cheap to include them. They carry the order history that makes your reporting continuous, and a registrant who comes back next year finds their old list where they expect it.
- How long does the whole thing take?
- The export request to your current provider is often the longest part, and it's the part neither of us controls. Once the file exists, the checking is about an hour and the date follows from what it finds.
For the two most common source apps specifically, there's moving from Gift Reggie, which is the one migration where purchase history comes across intact, and moving from Swym, where it doesn't and that decides your timing. The migration page covers how we run the move itself.