Back to Blog
POS migrationrestaurant operationsswitching POS

How to Switch POS Systems Without Losing a Saturday Night

A practical guide to restaurant POS migration — exporting from Toast, Square, and Clover, training your staff, running both systems in parallel, and going live without a disaster.

Corvus POS 15 min read

Switching POS systems sounds administrative. It isn’t. Your POS controls how every order moves from a customer’s mouth to the kitchen, how your staff works the line, how you close the night, and how you know if you made money. Getting the migration wrong doesn’t mean a software headache — it means a ruined service.

This guide is for independent restaurant operators who have decided to switch and want to know how to do it without a catastrophe. I’ll cover what data actually transfers, how long the realistic timeline is, how to train staff without losing shifts, and how to run a parallel cutover.

It’s not written to sell you on any particular system. It’s written because “how to switch POS” content online is mostly vendor blogs steering you toward their migration path.


Before You Start: What Data Actually Transfers

This is where most guides get vague. Let’s be specific.

What migrates cleanly

Menu data — Every major POS exports your menu in CSV or JSON format. Item names, descriptions, prices, modifiers, and categories all export cleanly. Re-importing into a new system takes 2–4 hours of work for a typical menu. More complex menus (50+ items, deeply nested modifier groups) can take a full day.

Historical sales data — Most POS systems export daily sales reports as CSV. You won’t lose your history; it just lives in the old system or in exported files. You generally can’t import old sales history into a new system and have it appear in the new reporting dashboard. Plan to run parallel reports from the old system for 90 days post-switch for any historical comparisons.

Staff accounts — Staff logins don’t transfer. You’ll create new accounts in the new system. Budget 5–10 minutes per staff member for account setup and permission configuration.

Gift card balances — If you have outstanding gift cards, this is the hardest data transfer. Some systems allow balance migration; most don’t. Plan to honor remaining balances through the old system’s dashboard for the life of those cards, or offer a credit exchange.

What doesn’t transfer

Customer loyalty points — Loyalty programs are closed ecosystems. Unless both systems are on the same loyalty platform, points don’t migrate. You’ll need a cutover policy (freeze points on day X, honor any redemptions through the old system dashboard for 30 days).

Open tabs and split tickets from the cutover night — Whatever is open when you switch systems needs to be closed in the old system before you go live on the new one. Never do a hard cutover mid-service.

Reservation/waitlist integrations — If your POS is integrated with OpenTable, Resy, or Yelp Waitlist, those integrations need to be reconfigured on the new system. Contact your reservation partner before you switch.


Realistic Timeline by Restaurant Size

Small independent (1 location, under 15 staff)

Recommended timeline: 2 weeks

  • Week 1: Menu build in new system, staff account setup, hardware install (if new hardware needed)
  • Week 2: 2–3 training shifts, 2–3 parallel operation shifts, go-live

Most guides say “7 days.” Two weeks is more realistic if you have a complex menu or if your staff needs meaningful training time.

Casual dining / food truck (under 30 staff, some complexity)

Recommended timeline: 3–4 weeks

  • 1 week menu + account setup
  • 1 week hardware + integration testing
  • 1 week staff training
  • 1 week parallel operation before full go-live

Multi-location (2+ locations)

Recommended timeline: 6–8 weeks

Roll out one location at a time. Get location 1 stable before you touch location 2. Shared menu changes across locations need to be coordinated.


Menu Export: System-Specific Notes

Exporting from Toast

Toast exports menus through the Toast Back Office portal. Go to Menus → Export. You’ll get a CSV with item names, prices, modifiers, and category structure. Modifier groups export separately; you’ll need to manually reconstruct modifier-to-item relationships in the new system.

Toast’s export format is reasonably clean but not universal. Budget time for reformatting if the new system expects a different CSV schema.

Source: Toast’s help documentation (help.toasttab.com), reviewed April 2026.

Exporting from Square

Square exports menu data through the Square Dashboard under Items → Export. The export is a flat CSV. If your menu has complex modifier groups or required modifiers vs. optional modifiers, you’ll need to rebuild that logic in the new system manually — the flat CSV doesn’t capture modifier rules cleanly.

Source: Square’s support documentation (squareup.com/help), reviewed April 2026.

Exporting from Clover

Clover’s data export is through the Clover Dashboard under the Employees or Reports section depending on what you’re exporting. Menu data exports are less standardized than Toast or Square — the format varies by Clover app (Clover Dining, Clover Counter Service, etc.). If you’re on a third-party Clover app, check that app’s export options, not just the base Clover dashboard.

Source: Clover’s developer documentation (docs.clover.com), reviewed April 2026.


Staff Training: The Part That Actually Matters

Here’s the truth: staff training is where POS migrations succeed or fail, not menu imports.

A staff member who learns a system during a slow Wednesday lunch is ready for Saturday night. A staff member who sees the new system for the first time during a busy service is a liability.

How to structure training

Step 1: Self-guided exploration (before any official training) Give staff access to the new system in test/sandbox mode (most POS systems have this) during a slow period. 20 minutes of clicking around a new interface before formal training dramatically reduces training time.

Step 2: Guided walkthrough (one session per role) Walk through the core workflows for each role:

  • FOH order entry: Opening a ticket, adding items, adding modifiers, splitting, applying discounts, closing with card vs. cash
  • Manager: End-of-day close, voids, refunds, reprinting receipts, pulling a shift report
  • Bar (if applicable): Opening tabs, keeping them open, running a bar tab to close at end of night

One 45-minute session per role is enough for a basic-complexity system. More complex menus or workflows need more time.

Step 3: Shadow shifts Run 1–2 shifts where trained staff shadow on the old system while the new system runs in parallel. They can use the new system for non-critical orders (voids don’t count against real inventory). This builds muscle memory without risk.

What usually goes wrong in training

Modifiers. Staff memorize where things are in the old system. Modifiers are in different places in every POS. Spend extra time on modifier navigation.

Voids and comps. Every POS handles these differently. Your staff needs to know exactly how to void an item or comp a table before they need to do it during a service.

End-of-day close. The person who does your night close needs a dedicated walkthrough. This is not something to learn on the fly at 11pm.


Running Parallel Systems

Parallel operation — running both the old and new POS simultaneously for 2–4 shifts — is the single biggest thing you can do to de-risk a migration.

Here’s how to structure it:

What runs on the new system: All new tickets go through the new system. Kitchen gets tickets from the new system. This builds real-world confidence in the new system before you depend on it.

What runs on the old system: Refunds, voids on old transactions, and any ticket that started before the cutover shift. Keep the old system available but not the primary.

What to watch during parallel:

  • Are kitchen tickets printing correctly? (Right items, right modifiers, right station routing)
  • Are modifiers appearing on tickets the way you expect?
  • Is the end-of-day close matching what you expect?
  • Are any items missing from the new system that staff are trying to ring in?

After 2–4 successful parallel shifts, you’re ready for full cutover.


The Cutover Moment

The actual cutover moment should be at the start of a shift, not during one.

Never switch POS mid-service. Open tickets, table maps, and in-progress orders are all in the old system. Switching mid-service means manually reconciling anything that was open.

Best cutover window: Before a slow shift. Tuesday breakfast or Sunday afternoon brunch. Not Friday night.

Pre-cutover checklist:

  • All open tabs from the previous service are closed and settled in the old system
  • Old system reports printed/exported for the shift (you’ll need these for comp with new system)
  • All staff are on the new system and have their accounts
  • Kitchen printers or KDS are configured to the new system
  • Payment terminals are configured and tested with the new system
  • Manager knows how to void, refund, and do end-of-day close in the new system

The first few hours: Stay on-site. Have your most experienced staff on FOH and BOH. Expect slower service — that’s normal. The speed comes back after 2–3 shifts.


What to Do When Things Go Wrong

Things will go wrong. That’s not a failure; it’s a migration.

A menu item is missing: Add it on the fly through the back office. Most POS systems let you add items in real time. Know where this is before go-live.

A kitchen printer isn’t printing: Check the connection first (USB or network), then restart the printer, then check routing settings in the POS. Know who to call for printer support.

A payment fails: Fall back to your standalone terminal if you have one, or take the card information manually and key it in later (as a last resort). Do not turn away guests because the POS payment isn’t working on cutover night.

End-of-day close shows a discrepancy: Don’t panic. Run the old system’s report for the same period and compare. Most discrepancies on cutover night are from the parallel transition period. Document them and reconcile the next morning with a clear head.


The Saturday Night Standard

A successful migration means you can run your busiest service on the new system with no meaningful increase in ticket times, errors, or guest-facing problems by your third shift on the new system.

If you’re still struggling at shift 5, something is wrong — either with the training, the menu setup, or potentially the system choice itself. Don’t normalize a rough experience for weeks.

The parallel operation period, the training structure above, and the pre-cutover checklist will get most independent restaurants through cleanly. The ones that have bad migrations usually skipped one of these steps.


Competitor documentation sourced from public help centers as of April 2026. Product features change; verify current export formats and procedures with your vendor before beginning migration.

Corvus POS publishes this guide. We’re one option among many. If you’re evaluating us for your next system, schedule a demo and we’ll walk through what the migration looks like for your specific setup.

Share this article