Can I migrate during peak season without downtime?

Yes. Mid-week morning cutover window. The parallel build means downtime is functionally zero.

Will customers have to enter payment info again?

If you use the same processor, saved cards usually carry over via tokenization. Change processors and customers re-enter.

How to Migrate Your Marketplace from Hyperzod: A Step-by-Step Guide

tl;dr

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 migration isn't the hard part. The decision is.

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.

The platforms change. The customers shouldn't notice. That's the whole goal.

Most marketplaces complete in 2–3 weeks; complex setups stretch to 4. The cutover itself is one afternoon.

Step 1 · Export everything from Hyperzod

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:

Merchant list — names, addresses, contact info, business hours, commission rates, payment-account details.

Product catalogs — per merchant, with categories, modifiers, prices, images, descriptions.

Customer data — names, emails, phone numbers, saved addresses, order history.

Driver roster — names, contact info, vehicle types, zones.

Order history — at least the last 90 days, for customer reference and dispute resolution.

Settings & configuration — delivery zones, fee structures, coupon codes, loyalty balances.

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.

Step 2 · Choose a platform that supports white-label app transitions

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.

Step 3 · Map your data into the new platform

This is the longest single step. Plan 3–7 working days depending on portfolio size. The mapping work falls into three buckets:

Bucket · 1 of 3

Merchants & catalogs

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.

Bucket · 2 of 3

Customers & loyalty

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.

Bucket · 3 of 3

Settings & integrations

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.

Step 4 · Run a parallel test before cutover

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.

Step 5 · The cutover

Pick a low-volume window — typically Tuesday or Wednesday morning, not Friday afternoon. The cutover itself is three actions:

Step A · DNS flip

Point your marketplace domain to the new platform. A standard DNS A-record change. Propagation takes 5–60 minutes depending on TTL settings. The new platform is live as soon as DNS resolves.

Step B · Push the new app build

Submit the new iOS and Android builds for review. If your new platform manages the app stores, this is handled for you. Approval times: Apple typically 24–48 hours, Google typically 2–24 hours. Builds release as updates, not new installs.

Step C · Notify everyone

Customers, merchants, drivers, and your team. Customers get a brief email ("we've upgraded our platform — same app, faster experience"). Merchants get login details for the new dashboard. Drivers get a heads-up on which app to expect updates from. Your support team gets a quick-reference cheat sheet for the most common questions on day one.

Customers and drivers should barely notice. Merchants and your team get a brief learning curve.

Three pitfalls worth naming

Pitfall · 1 of 3

Cutting over before merchant training is done

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.

Pitfall · 2 of 3

Losing loyalty balances

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.

Pitfall · 3 of 3

Silent cutover with no customer communication

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.

If you don't want to run the playbook yourself

Pick a platform that runs the migration for you

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.

Frequently asked questions

Can I migrate during a peak season without downtime? +

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.

Want us to run the playbook for you?

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

Topics: Business Intelligence Marketing and Loyalty Online Ordering Growth

How to Migrate Your Marketplace from Hyperzod: A Step-by-Step Guide

The migration isn't the hard part. The decision is.

Step 1 · Export everything from Hyperzod

Step 2 · Choose a platform that supports white-label app transitions