If you take online orders through Toast or Olo today, the useful question isn’t whether Eatsy can replace that layer. It’s what carries over, what you rebuild, and how long you’re exposed while the switch happens.

The short answer on exposure: none, if you sequence it right. Nothing in this migration requires you to shut off your current provider first. You build Eatsy alongside it, test it with a real order, then move your links. Only after that do you wind the old one down.

Step 1: Gather these before your kickoff call

Migration prep is the same as any Eatsy launch, plus two items that only matter when you already have a live ordering page.

Bring to your 30-minute kickoff call:

  1. Your menu in any exportable format. A PDF export from your current platform, a printed menu, a photo, or a POS export. If you can send an original vector PDF instead of a scan, do: text extraction is dramatically better.
  2. Your logo (vector preferred) and your brand colors as hex codes.
  3. Your delivery footprint: the zones you deliver to, the fee and minimum for each one, and your estimated times.
  4. Your domain access: the registrar login (GoDaddy, Namecheap, Cloudflare, and so on) or delegated access.
  5. Every live ordering URL you have. This one is migration-specific. Write down the exact addresses customers land on today: your main ordering page, per-location pages, and any deep links printed on flyers, table tents, or sitting in your Google Business Profile. This list becomes your redirect map.
  6. Your POS. Also migration-specific. Which point of sale you run in-restaurant is what decides how deeply Eatsy connects on day one.

Step 2: Know where your setup lands in the integration table

Eatsy is online ordering software, not a POS. We sit alongside your point-of-sale system, so your integration depth is a function of the POS, not of the ordering platform you’re leaving.

If you run Toast as your POS: Toast is supported today at the order-routing tier. Online orders push into Toast Hub as tickets, the menu lives in Eatsy as a one-way setup, and payment reconciliation is a manual CSV export. A native Toast integration with full menu sync and payment reconciliation is on the roadmap for Q3 2026.

If you’re on Olo: Olo isn’t in our POS table, because it isn’t a POS. It occupies the same slot Eatsy does, which is the online ordering layer on top of your POS. So the first thing to settle is what POS sits underneath, and then read your tier off the table.

If your POS isn’t listed at all: Eatsy still runs. Orders land in Order Management, our kitchen-tablet product, or print straight to a kitchen printer instead of routing into your POS’s kitchen display. See Order Management Training.

The full tier-by-tier breakdown lives in Supported POS Integrations. Read it before your kickoff call so you arrive with the right expectations.

Step 3: How your menu comes across

Menu setup at Eatsy is staff-led. There is no “Import” button you have to find: your onboarding manager runs the import and hands the catalog back to you in admin.eatsyorders.com → Menu management for review.

For a migration, one of two paths applies:

  • POS sync. If you’re on a POS we connect to, we pull the live catalog: items, modifier groups, modifiers, prices, categories, and category order. Items currently disabled in your POS come across as inactive in Eatsy. Allergen tags come over if you tagged them. Note that for Toast specifically, this is a one-time manual import today rather than an ongoing sync, so after launch your Eatsy catalog is the one you edit.
  • Flamsy AI from photo or PDF. If exporting from your current platform is awkward, skip it entirely. Send the menu as a PDF or a photo. Flamsy AI, Eatsy’s menu intelligence, pulls items, descriptions, prices, modifier groups, and category headings. Accuracy runs 95% or better on printed menus and PDFs, 80-90% on chalkboards, and 75-90% on handwriting. Menus of 10 pages or more get processed in batches of 4 to 5 pages, reviewed batch by batch.

Either way, Flamsy AI then writes bilingual EN and ES descriptions for every item in your brand voice. You’ll get an email when the catalog is ready, typically within 4 hours of the import.

Two things that don’t come across automatically: item photos (most systems don’t store them at the resolution we need, so you upload them in Eatsy) and inventory tracking (Eatsy doesn’t sync inventory two-way today). And if you want your existing customer list brought over from your current provider, raise it on the kickoff call rather than assuming it travels with the menu.

Then you walk the catalog yourself in Menu management: the Menus, Categories, Products, and Modifiers tabs, plus featured products (pin 3 to 6 high-margin items) and schedules for anything that’s only available certain days or hours. Most operators spend 30 to 45 minutes here; a 200-item menu takes 1 to 2 hours. Full detail in How We Import Your Menu.

Step 4: What we configure while you’re still selling

The point of a high-touch onboarding is that your kitchen never stops to accommodate the migration. Your onboarding manager configures, in our internal systems:

  • Hours of operation, including your online ordering window and holiday closures
  • Your delivery footprint: zones, fees, minimums, and estimated times, running on either IHD (Eatsy’s delivery aggregator, which fans out to Uber Direct, DoorDash Drive, and Routemasters) or your own in-house fleet
  • Local sales tax rates, set per location
  • Your payment gateway, Shift4 or NMI, connecting to your own merchant account
  • 3D Secure fraud protection
  • The first employee accounts and roles from your team list
  • The POS connection and first sync, if you’re on a supported POS
  • DNS, SSL, and email forwarding
  • Branded App submission to the App Store and Google Play, if you’re on that plan

What stays yours to configure in admin.eatsyorders.com: brand appearance, menu, microsite page toggles, marketing campaigns, discounts, cross-selling, loyalty, and employees. The honest split is in Going Live: What We Handle vs. What You Configure.

Don't cancel anything yet. None of this work touches your current provider. Your existing ordering page keeps taking orders through the entire build. The cancellation conversation belongs at the end of this guide, not the start.

This is the part unique to a migration: your customers already know a URL, and it currently points somewhere else. You have three ways to handle it.

Full custom domain takeover. Your domain becomes your Eatsy Microsite. We update the A and CNAME records, provision an auto-renewing SSL certificate, and set up email forwarding so orders@yourrestaurant.com still reaches your inbox. Live in 24 to 48 hours, with DNS propagation as the bottleneck.

Subdomain only. Your existing site stays exactly as it is, and we point something like order.yourrestaurant.com or pedidos.yourrestaurant.com at Eatsy. You add one CNAME record using the target your onboarding manager gives you, then repoint your site’s “Order Online” button. Live in 1 to 4 hours after DNS propagates. This is the right answer if your current website is on Squarespace, Wix, or Shopify and you want to keep it.

Free Eatsy subdomain. <yourslug>.eatsyorders.com, live within minutes of menu approval, zero DNS work on your side. You can upgrade to a custom domain later without losing your menu, your customer database, or live orders.

Whichever you pick, hand your onboarding manager the URL list you gathered in step 1. If your current ordering pages rank in Google, we set up 301 redirects from the old URLs to the new equivalents so you keep that authority. Tell us which pages matter most so they make it into the redirect map. See Connect Your Domain.

The links you'll forget. Your Google Business Profile ordering URL, the link in your Instagram bio, the QR codes printed on your table tents, and the "Order Online" button on your own website. Redirects cover the web ones. Printed material you have to reprint, so budget a batch.

Step 6: What to do about your current provider

In this order, and not before:

  1. Get Eatsy live at a real URL. Menu published, gateway connected, hours and delivery zones configured.
  2. Place a real test order yourself. Browse the Microsite, customize an item, pay with your own card, confirm it lands in your Orders log and on the Order Management tablet, then fulfill it. This single step catches most preventable problems.
  3. Run both in parallel for a full week, weekend included. A Saturday dinner rush surfaces things a Tuesday lunch never will.
  4. Move the links. Repoint your website button, update your Google Business Profile, publish the redirects, tell your customer list.
  5. Then wind the old one down. Before you cancel, review your existing agreement for notice periods and commitments, and ask your current provider what data they’ll export for you.

There’s no prize for cancelling early. There is a real cost to a dark ordering page during a dinner rush.

A realistic timeline

Single location, most operators are live in 5 to 7 days:

WhenWhat happens
Day 130-minute kickoff call. You hand over menu, brand assets, delivery footprint, URL list.
Day 2Menu import runs. Catalog lands in Menu management for your review, usually within 24 hours of kickoff.
Day 2-3You review the catalog and confirm brand appearance. 30 to 45 minutes for most menus.
Day 3-4Domain, SSL, and email forwarding configured. Gateway connected. Hours, taxes, and delivery zones set.
Day 5-6Microsite goes live. You place your test order.
Day 6-7Links and redirects switch over. You announce.

Two adjustments to that:

  • Multi-location takes 2 to 3 weeks instead, because each location gets its own catalog overrides, hours, delivery footprint, and staff. See Multi-Location Setup.
  • Branded App submissions go out the same week, and App Store and Google Play approval typically takes another 5 to 7 days. Launch your Microsite first and let the app follow.

Run the Pre-Launch Checklist before you announce anything.