The Square-to-Toast Migration Trap: New POS, Same Broken Back Office
You upgraded the half that was already working
You spent six months migrating from Square to Toast. The kitchen display is faster. The reporting is sharper. Your servers like the new tablets. The migration was a real win.
Now pull up the spreadsheet you used to reconcile inventory last month. Look familiar?
Same columns. Same formulas. Same manual rebuilds. Same vendor invoices flagged for follow-up that nobody followed up on.
This is the migration trap: the POS upgrade fixed the half of your operation that was already working. The half that was actually broken stayed exactly as it was.
Why operators migrate, and why those reasons are usually right
Square-to-Toast is the most common restaurant POS migration we see, and operators move for legitimate reasons. Toast's modifier handling is better for complex menus. The kitchen display system integrates with order routing more cleanly. The reporting is more granular than Square's defaults. Hardware reliability is generally better for high-volume operations. The third-party integration marketplace is broader.
None of these reasons are wrong. We've recommended Square-to-Toast migrations ourselves when the operational fit is clear. But the migration solves a front-of-house problem, not a back-of-house problem.
The expectation gap is what creates the trap. Operators sign the new POS contract believing — sometimes implicitly, sometimes explicitly because the salesperson said so — that the new system will fix the parts of their operation that are currently broken. Then 90 days post-migration, the front of house is humming and the back office is exactly where it was before the migration started.
What the migration didn't touch
Here's what stays exactly the same after a POS migration. Doesn't matter if you went Square to Toast, Toast to Lightspeed, or anything to anything else:
- Your vendor master is still in someone's email, a shared spreadsheet, or both
- Purchase orders are still placed by phone or text, with no approval workflow
- Vendor invoices still arrive, get processed, and get paid without anyone reconciling them to receipts
- Recipe costs are still calculated manually (or not at all) in a spreadsheet that hasn't been updated since the last menu change
- Inventory counts still get done on a clipboard and typed into Excel
- Consolidated multi-location reporting still requires someone to export, reformat, and rebuild
None of these are POS problems. They're operating-layer problems. The POS was never going to solve them — switching POSs was never going to solve them.
If three or more of these are true 90 days after your migration, the migration didn't fix what you thought it would:
- Your accounting team is doing the same end-of-month gymnastics they were doing before
- Food cost percentage hasn't moved meaningfully in either direction
- Inventory accuracy hasn't improved
- Closing the books still takes the same number of days
- You're still rebuilding multi-location reports manually
- Your COO or Controller is still spending their week chasing numbers
The post-migration window is the best fix window
The 90 days after a POS migration are the best possible time to address the back office. Your team is already in change mode. Workflows are being rewritten. Documentation is fresh. Inertia is at its lowest. Skip this window and you wait another two years for the next natural moment to make this kind of change.
Three things to put in place during that 90-day window:
1. Real recipe-to-cost mapping. Every menu item mapped to its ingredients in an ERP — not a spreadsheet. An actual relationship that updates food cost percentage when vendor pricing moves. This is the single highest-leverage operational change a multi-unit restaurant group can make. It's also one of the harder things to retrofit later, because the menu engineering team has to be involved.
2. A vendor master with discipline. Payment terms. Contract pricing. Approved-receiver list. A single authoritative source for every supplier relationship. No more "we always use Sysco for that — wait, actually we used US Foods last month." Standardize who orders from whom and on what terms.
3. Consolidated reporting that runs on its own. Pick one location to instrument first. Get the close down from 14 days to 5. Document the playbook. Then clone it across the rest of the locations. Don't try to fix all locations simultaneously. The pilot model works because it produces a documented playbook before scaling.
This isn't software work. It's operations work. The software just makes the operations sustainable.
Where the POS fits in
Operators sometimes ask: "If we're doing all this in Odoo, why did we just migrate the POS?"
Because the POS still has a job. Toast handles orders, payments, modifiers, kitchen display, the front-of-house experience. That job is real and it matters. Odoo doesn't replace any of that.
What Odoo adds is the operating layer: procurement, vendor management, recipe costing, multi-location reporting. POS data flows into Odoo nightly. Your team uses Toast on the floor. Your accounting and operations teams use Odoo for everything else. Neither system tries to be the other.
The pattern that fails is treating the POS as your ERP. The pattern that works is treating them as two systems that talk to each other and stay in their lanes.
If you migrated in the last 18 months
The migration didn't fail. It just didn't fix what you needed it to fix — because what you needed fixed was never the POS. The fix is a separate piece of work, and it's a smaller one than most operators expect. Most of our 90-day back-office engagements deliver visible margin recovery before they're finished.
The next post in this series, Built to Scale, looks at a related pattern from a different angle: single-location operators preparing for multi-unit growth before the seams start showing. It publishes June 1.
The 20-Minute Back-of-House Audit
If you migrated POS systems in the last 18 months and the back office still looks broken, the audit is the fastest way to map what stayed broken to what fixing it would actually require. No pitch, no slides — we walk your current workflow, name three risk areas, and recommend one next step.
You upgraded the half that was already working
You spent six months migrating from Square to Toast. The kitchen display is faster. The reporting is sharper. Your servers like the new tablets. The migration was a real win.
Now pull up the spreadsheet you used to reconcile inventory last month. Look familiar?
Same columns. Same formulas. Same manual rebuilds. Same vendor invoices flagged for follow-up that nobody followed up on.
This is the migration trap: the POS upgrade fixed the half of your operation that was already working. The half that was actually broken stayed exactly as it was.
Why operators migrate, and why those reasons are usually right
Square-to-Toast is the most common restaurant POS migration we see, and operators move for legitimate reasons. Toast's modifier handling is better for complex menus. The kitchen display system integrates with order routing more cleanly. The reporting is more granular than Square's defaults. Hardware reliability is generally better for high-volume operations. The third-party integration marketplace is broader.
None of these reasons are wrong. We've recommended Square-to-Toast migrations ourselves when the operational fit is clear. But the migration solves a front-of-house problem, not a back-of-house problem.
The expectation gap is what creates the trap. Operators sign the new POS contract believing — sometimes implicitly, sometimes explicitly because the salesperson said so — that the new system will fix the parts of their operation that are currently broken. Then 90 days post-migration, the front of house is humming and the back office is exactly where it was before the migration started.
What the migration didn't touch
Here's what stays exactly the same after a POS migration. Doesn't matter if you went Square to Toast, Toast to Lightspeed, or anything to anything else:
- Your vendor master is still in someone's email, a shared spreadsheet, or both
- Purchase orders are still placed by phone or text, with no approval workflow
- Vendor invoices still arrive, get processed, and get paid without anyone reconciling them to receipts
- Recipe costs are still calculated manually (or not at all) in a spreadsheet that hasn't been updated since the last menu change
- Inventory counts still get done on a clipboard and typed into Excel
- Consolidated multi-location reporting still requires someone to export, reformat, and rebuild
None of these are POS problems. They're operating-layer problems. The POS was never going to solve them — switching POSs was never going to solve them.
If three or more of these are true 90 days after your migration, the migration didn't fix what you thought it would:
- Your accounting team is doing the same end-of-month gymnastics they were doing before
- Food cost percentage hasn't moved meaningfully in either direction
- Inventory accuracy hasn't improved
- Closing the books still takes the same number of days
- You're still rebuilding multi-location reports manually
- Your COO or Controller is still spending their week chasing numbers
The post-migration window is the best fix window
The 90 days after a POS migration are the best possible time to address the back office. Your team is already in change mode. Workflows are being rewritten. Documentation is fresh. Inertia is at its lowest. Skip this window and you wait another two years for the next natural moment to make this kind of change.
Three things to put in place during that 90-day window:
1. Real recipe-to-cost mapping. Every menu item mapped to its ingredients in an ERP — not a spreadsheet. An actual relationship that updates food cost percentage when vendor pricing moves. This is the single highest-leverage operational change a multi-unit restaurant group can make. It's also one of the harder things to retrofit later, because the menu engineering team has to be involved.
2. A vendor master with discipline. Payment terms. Contract pricing. Approved-receiver list. A single authoritative source for every supplier relationship. No more "we always use Sysco for that — wait, actually we used US Foods last month." Standardize who orders from whom and on what terms.
3. Consolidated reporting that runs on its own. Pick one location to instrument first. Get the close down from 14 days to 5. Document the playbook. Then clone it across the rest of the locations. Don't try to fix all locations simultaneously. The pilot model works because it produces a documented playbook before scaling.
This isn't software work. It's operations work. The software just makes the operations sustainable.
Where the POS fits in
Operators sometimes ask: "If we're doing all this in Odoo, why did we just migrate the POS?"
Because the POS still has a job. Toast handles orders, payments, modifiers, kitchen display, the front-of-house experience. That job is real and it matters. Odoo doesn't replace any of that.
What Odoo adds is the operating layer: procurement, vendor management, recipe costing, multi-location reporting. POS data flows into Odoo nightly. Your team uses Toast on the floor. Your accounting and operations teams use Odoo for everything else. Neither system tries to be the other.
The pattern that fails is treating the POS as your ERP. The pattern that works is treating them as two systems that talk to each other and stay in their lanes.
If you migrated in the last 18 months
The migration didn't fail. It just didn't fix what you needed it to fix — because what you needed fixed was never the POS. The fix is a separate piece of work, and it's a smaller one than most operators expect. Most of our 90-day back-office engagements deliver visible margin recovery before they're finished.
The next post in this series, Built to Scale, looks at a related pattern from a different angle: single-location operators preparing for multi-unit growth before the seams start showing. It publishes June 1.
The 20-Minute Back-of-House Audit
If you migrated POS systems in the last 18 months and the back office still looks broken, the audit is the fastest way to map what stayed broken to what fixing it would actually require. No pitch, no slides — we walk your current workflow, name three risk areas, and recommend one next step.