Data portability
Your restaurant data is yours. Migration planning includes export expectations up front, and MarginKind keeps portability part of the operating conversation instead of a renewal surprise.
Migration guide
Switching from Lightspeed to MarginKind
Use the switch to clarify which product, inventory, service, and reporting decisions belong together before recreating old setup drift in a new platform.
Import-led path
Move the menu before you move service
Lightspeed migrations are a structured rebuild today. Toast and Square import remain the shipped automated paths, while Lightspeed exports can still guide staged menu, recipe, inventory, and reporting setup.
Capability tag: shipped for Toast/Square import and AI recipe-generation during import; roadmap for automated imports from other vendors.
Step 1
Export products and menu structure
Gather products, categories, menus, modifiers, pantry items, KDS routes, and active reports before changing service.
- Export product/menu lists
- Capture pantry and stock conventions
- Document current KDS routing
Step 2
Rebuild around recipes and stock
Create a staging model that connects sellable menu items to recipes, stock, receiving, and waste review.
- Map products to menu modules
- Attach recipes where available
- Validate inventory units
Step 3
Rehearse reporting and close-out
Run representative service tickets and compare reporting expectations before committing the production switch.
- Run sample tickets
- Review manager close-out
- Compare owner reports
Migration confidence pack
What MarginKind does vs. what your team owns
MarginKind helps with
- Maps exported menu and item data into a staging tenant before service is affected.
- Helps review recipes, ingredients, modifiers, staff roles, and reporting assumptions before cutover.
- Keeps roadmap-only migration work labeled separately from shipped import and review workflows.
Your team provides
- Exports current menu, modifier, staff-role, and reporting reference data from the incumbent system.
- Chooses a low-risk service window for rehearsal and production cutover.
- Keeps the incumbent available during the first live services while managers compare close-out reports.
Parallel running
For most operators, the safest path is at least two rehearsal services plus two to five live service days where managers can compare tickets, menu behavior, payments, and close-out reporting before relying on the new system alone.
Want help pressure-testing the plan?
Bring your current menu, staff role list, and one week of close-out reports. We can map the riskiest cutover points before you commit.
Plan a migration call