Migrating a marketplace off Hyperzod is straightforward but not zero-effort. The five steps that actually matter: export your data, choose a platform that supports white-label app transitions, map your merchants and customers, run a parallel build before cutover, and announce the change to your customers. Most operators finish in 1–4 weeks depending on portfolio size. Done right, you lose zero orders and your customers never re-download an app.
The most common reason operators delay leaving Hyperzod isn't that they think it'll be technically difficult. It's that they think it'll be operationally messy — lost customers, downtime, drivers calling support all day, merchants confused about logins. Those are real risks. They're also avoidable.
This guide walks through the actual sequence: what you export, what you import, what changes for your customers (almost nothing), what changes for your merchants (a new dashboard), and the timeline that works. If you've decided you're going to migrate, the playbook below is the whole thing.
Before you do anything else, get your data out. Hyperzod's admin panel supports exports for most of what you need; for the rest, you'll work with their support team. Plan to export:
Save everything to a single Drive folder. You'll reference it constantly over the next two weeks. Don't skip the loyalty balances — losing a customer's accumulated points is one of the few migration mistakes that generates support tickets.
This is the technical question that determines whether your customers re-download. Hyperzod publishes apps under your brand on the App Store and Google Play, using its own developer account. When you leave, your apps are deactivated.
The right new platform handles this two ways. Either it publishes apps under your own developer accounts (so the new apps simply update over the old ones), or it works with Hyperzod to transfer the existing app listings to a new account before publishing the new build. Either path means customers receive a normal app update, not a "please download our new app" notification.
Ordering.co does this by default — same brand, same App Store listing, same icon. Some platforms don't, which means your customers re-download. Worth confirming up front; the answer changes the migration plan materially.
This is the longest single step. Plan 3–7 working days depending on portfolio size. The mapping work falls into three buckets:
Bulk-import via CSV using the new platform's importer. Most platforms accept the same Hyperzod-export columns with minor renaming. Test with one merchant first — verify products, prices, modifiers, and images all carried over before running the full batch.
Import customer records with saved addresses and loyalty balances. Customers shouldn't have to re-create accounts — their email lookup should match an existing record on the new platform. If your new platform supports password-reset-on-first-login, use it; otherwise plan a one-time email to all customers prompting a password set.
Delivery zones, payment gateway (Stripe, MercadoPago, Fiserv, etc.), third-party logistics integrations (Uber Direct, DoorDash Drive, Rappi), POS connectors. Each integration is reconfigured against your existing accounts — you don't usually need new merchant accounts at Stripe or Uber, just new API connections.
Before flipping anything live, run real orders through the new platform with 1–3 friendly merchants. These should be merchants you trust to flag issues, not your largest revenue contributors. Place test orders, verify dispatch, verify driver app behavior, verify customer notifications, verify payments settle correctly.
Train your dispatch and support teams on the new admin panel during this week. By the time you cut over, your operators should already know where the merchant directory lives and how to refund an order on the new system — without looking it up mid-incident.
Pick a low-volume window — typically Tuesday or Wednesday morning, not Friday afternoon. The cutover itself is three actions:
If your merchants can't accept orders on day one, your operation breaks immediately. Insist on per-merchant training before cutover, even if it adds a week. The marginal cost of waiting one more week is far smaller than the cost of merchants angrily refusing orders because they can't find the "accept" button.
Every customer who notices their points are missing files a support ticket. Multiplied across your base, that's a week of customer-support headache. Migrate loyalty balances meticulously, and consider giving a small bonus on launch as a "thanks for sticking with us" gesture.
Even if technically nothing changes, customers notice something. A simple "we've upgraded our platform" email avoids the confusion of unexpected app updates and password prompts. Don't oversell — just acknowledge.
The five steps above are the work either you do or your new platform does. Some platforms charge for migration; some don't. Ordering.co's white-glove migration is included free for all new customers — a dedicated engineer maps your Hyperzod data, handles app store transitions, runs the parallel test, and coordinates cutover. Total elapsed time for most operators: under a week.
If you can do it yourself, do it yourself. If you'd rather hand it off, hand it off. Either way, the playbook above is the work that has to happen.
Yes, but pick your cutover window carefully. Mid-week morning is best. The parallel build means your new platform is fully tested before you flip DNS, so the actual downtime is functionally zero. The risk during peak is operational — you want your team focused, not stretched thin between cutover and a Friday dinner rush.
Will customers have to enter their payment info again? +If you use the same payment processor (Stripe, MercadoPago, etc.), saved cards usually carry over — they're tokenized at the processor, not Hyperzod. If you change processors during migration, customers will re-enter card details on first checkout. Most operators keep the same processor to avoid this.
What happens to my Hyperzod contract during migration? +You stay on Hyperzod through the parallel build phase, then cancel after cutover. Most Hyperzod contracts are month-to-month, so the cancellation is straightforward. If you're on an annual contract, time the cutover to coincide with renewal to avoid paying double in the final month.
What if something breaks during cutover? +The parallel-build approach minimizes this risk — by the time you flip DNS, the new platform has been running real test orders for a week. If something does break, DNS is reversible: you can point back to Hyperzod within an hour, fix the issue, and try again. White-glove migrations include 24/7 engineer-on-call support for the 72 hours around cutover.
Free white-glove migration. Dedicated engineer, parallel-build approach, zero customer downtime. Most marketplaces complete in under a week from kickoff to cutover.
See the migration page