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 Clover to MarginKind
Plan around hardware, permissions, and inventory cleanup. Clover environments often grow through device setup and apps; MarginKind migration is a chance to simplify the operating map.
Import-led path
Move the menu before you move service
Clover migrations are usually a structured rebuild today. Automated settings migration stays roadmap-tagged, while menu and recipe review can still use the same staged import discipline when exports are available.
Capability tag: shipped for Toast/Square import and AI recipe-generation during import; roadmap for automated imports from other vendors.
Step 1
Document devices and apps
List Clover devices, payment flows, kitchen routing, employee permissions, inventory apps, and any third-party add-ons in active use.
- Inventory devices by station
- Export item and category data
- List third-party apps and dependencies
Step 2
Translate operations, not screens
Rebuild the workflows your team actually needs: order entry, KDS, receiving, waste, staff permissions, and reporting.
- Map menu categories to MarginKind modules
- Build stock and recipe records
- Configure staff roles by unit
Step 3
Stage payment and service cutover
Validate hardware/payment assumptions separately from service workflows so a payment decision does not block operational training.
- Confirm payment approach
- Run a mock service
- Train managers on close-out and exception handling
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