Migrating Off Aloha and Micros POS: 2026 Playbook

A 24-unit casual-dining group in the English Midlands ran Aloha Classic on aging NT-era boxes until their NCR account manager sent the 2025 renewal quote. The quote came with a footnote: the on-prem product would no longer receive PCI DSS v4.0.1 attestation. The operator had nine months to pick a successor, migrate 11,400 active loyalty members, and re-certify payment with three acquirers. The group is now nine months into the project, and the gift card balances and split-check rules are still being modeled.

This is the recurring shape of POS migration in 2026. NCR Voyix has moved Aloha Classic into extended support only. Oracle has pushed Simphony Cloud as the only forward path for Micros 9700 customers. The result is a wave of mid-market and enterprise restaurant operators looking for a replatform that does not break the operation.

This post is for restaurant CIOs, group operations leads, and CFOs scoping a POS replatform in 2026. It walks through the vendor shortlist by segment, the integration map that decides scope, the realistic cost stack, and the cutover playbook that protects revenue through the switch.

Why Aloha Classic and Micros 9700 are no longer renewable

The end-of-life signal is now unambiguous:

• NCR Voyix has confirmed that Aloha Classic, the on-prem build that many US and EU operators ran for two decades, is in extended support. The forward products are Aloha Cloud and Aloha Essentials. Active product investment has moved to the cloud platforms. Significant updates to Aloha Classic have effectively stopped.
• Oracle has positioned Simphony Cloud as the sole forward path. Micros 9700, which served many of the largest hotel F&B operations, has been EOL since 2020 with extended runtime support continuing in limited form. Enterprise renewals are now on Simphony.
• PCI DSS v4.0.1 became fully mandatory on 31 March 2025. Future-dated requirements (6.4.3 payment page script management, 11.6.1 tamper detection, 12.6 security awareness updates) are now enforced. POS replatforms must comply at cutover; vendors holding extended-support-only products have not retrofitted v4.0.1 controls into them.

The economic case is asymmetric. Staying on a legacy POS that can no longer attest to PCI DSS exposes the operator to acquirer liability and potential fines. Switching to the same vendor’s cloud product is one option but rarely the cheapest or the best fit. Most operators use the forced moment to re-evaluate the entire POS stack.

POS vendor shortlist by segment

The 2026 vendor landscape sorts cleanly by segment. The decision is usually made within a segment, not across them.

• US-dominant mid-market and enterprise: Toast (public, broad ecosystem, strong DSP integration), SpotOn (mid-market, including Cuboh DSP aggregation), Square for Restaurants (SMB to lower mid-market), Revel Systems (mid-market with strong inventory).
• EU mid-market and multi-unit: Lightspeed Restaurant K-Series (formerly Kounta, strong in UK, Australia, and continental EU), Tevalis (UK QSR and groups), Zonal (UK pubs and casual dining), TouchBistro (multi-region with strong tablet-first deployments).
• Enterprise and hotel F&B: Oracle Simphony Cloud (still dominant in hotel groups), Agilysys InfoGenesis (hotel-led), HotSchedules / Fourth in adjacent labor and inventory.
• QSR-specific: Olo + Qu, par Brink, NCR Aloha Cloud for operators staying within NCR but moving forward.

For a 20 to 50 unit casual-dining group, the realistic shortlist in 2026 is typically Toast, Lightspeed K, and SpotOn or Simphony, depending on geography. For a 200-plus unit chain, the shortlist narrows to Toast and Simphony in most regions, with Lightspeed K viable for some EU footprints.

The trap is treating the POS as a head-unit decision. The POS is the orchestrator of payments, kitchen display, inventory, loyalty, online ordering, scheduling, and accounting. The right POS is the one whose integration ecosystem matches the operator’s existing or planned tech stack.

Integration map: the part that decides scope

The integration matrix is the single largest hidden cost in a POS migration. A typical multi-channel restaurant operation in 2026 integrates:

• Payments: card present (Adyen, Stripe Terminal, SumUp, Worldpay, FreedomPay), card not present for online ordering, mobile wallet, tipping logic, gratuity reconciliation.
• Kitchen Display System (KDS): Aloha KPS, Oracle KDS, Toast KDS, Fresh KDS, QSR Automations.
• Inventory and recipe management: MarketMan, Compeat, Crunchtime, Procurant, Restaurant365.
• Loyalty and CRM: Punchh, Paytronix, Thanx, Como, custom on top of the POS.
• Online ordering and DSP aggregator: Olo, Lunchbox, Deliverect, Otter, Chowly, HungerRush. Plus the DSPs themselves (Uber Eats, Deliveroo, DoorDash, Just Eat, Wolt).
• Reservation and waitlist: OpenTable, SevenRooms, Resy, Yelp Reservations.
• Labor and scheduling: 7shifts, Deputy, Fourth, Crunchtime.
• Accounting and finance: Sage Intacct, NetSuite, QuickBooks, Restaurant365, Xero.
• Reporting and BI: native POS reporting, plus typically a warehouse load to Snowflake, BigQuery, or a Looker model.

Every integration on this list is either certified by the new POS vendor, available through a community connector, or a custom build. The migration project sums the integration cost of every line. For a 24-unit group, the integration alone is typically EUR 50,000 to EUR 250,000 of professional services depending on how many connectors need custom work.

A practical migration scoping rule: every integration that already works against the legacy POS is at risk of needing 8 to 40 hours of remediation on the new POS, even with certified connectors. The estimate that assumes “the connector will just work” is the estimate that breaks the project.

Cost model: hardware, SaaS, integration, services, and runtime

A realistic 2026 cost stack for a typical 24-unit casual-dining migration:

• Hardware (terminals, kitchen printers, KDS displays, payment hardware): USD 1,500 to USD 3,500 per location. Toast, Lightspeed K, and Simphony all have certified hardware bundles; reusing existing kitchen printers and KDS displays is sometimes possible.
• Software subscription: USD 79 to USD 165 per terminal per month for the POS itself, plus modules (loyalty, online ordering, reporting) typically adding USD 30 to USD 80 per location.
• Integration / connector subscription: USD 30 to USD 200 per location per month for the connector stack (Olo, Deliverect, Punchh, etc.), depending on coverage.
• Implementation professional services: USD 25,000 to USD 250,000 depending on chain size, customization, and integration complexity.
• Internal cost: typically 0.5 to 2 FTE of internal IT or operations time over the project, plus per-site rollout time.

The recurring software cost on the new stack often comes out 20 to 60% higher than the legacy stack the operator is leaving. The justification has to be in operational lift (lower checkout time, better attach rates, lower payment cost per ticket) or in cost avoidance (PCI DSS attestation, support cost on aging hardware). Selling the migration as a cost-cut typically fails; selling it as risk reduction and revenue uplift usually holds.

Cutover playbook: pilot, freeze, parallel run, payment certification

The cutover sequence that survives a multi-unit rollout looks the same regardless of vendor:

1. Pilot site (1 location, 4 to 6 weeks). Full menu modeled, all integrations live, all reporting tested. The pilot is not done until a full week of normal trade has produced reconciled reports.
2. Menu freeze for the chain (2 weeks before rollout starts). Any menu change after freeze must be cleared explicitly; otherwise modifier matching across legacy and new POS breaks.
3. Parallel run at 2 to 4 sites for 1 to 2 weeks. Sales rung on the new POS, financial reporting still produced from the old. End-of-day reconciliation forced daily.
4. Wave rollout (typically 3 to 5 sites per week for a 20 to 50 unit chain). Each wave includes a pre-rollout checklist, a 24-hour rollout window per site, and a 7-day post-rollout watch.
5. Payment certification runs alongside. Each acquirer relationship requires re-certification of the new POS integration. Allow 2 to 6 weeks per acquirer; running multiple acquirer certifications in parallel is the only way to keep the rollout on schedule.
6. Post-cutover stabilization for 30 to 60 days, with daily reporting reconciliation and a fast-feedback channel from operations to the project team.

The single most important cutover discipline is the per-site checklist. Every site that goes live carries a checklist of menu items, modifier groups, tax rules, gift card balances, loyalty accounts migrated, integration health checks, and a post-rollout receipt comparison. Sites that skip the checklist break revenue reporting and trigger emergency back-outs.

PCI DSS v4.0.1 and SEPA Instant requirements at the moment of cutover

Two compliance regimes apply at the moment of cutover:

• PCI DSS v4.0.1: the new POS stack must hold a valid attestation. For SAQ-eligible operators, this is typically inherited from the SaaS vendor’s QSA. For Level 1 merchants, the operator’s own QSA must re-attest the integrated environment after cutover. Allow 6 to 10 weeks for the post-cutover assessment.
• EU Instant Payments Regulation (Regulation (EU) 2024/886): SEPA Instant capability for PSPs has been mandated since 9 October 2025 (receive) and 9 January 2026 (send). Payment integrations in the new POS stack should support instant settlement where the acquirer offers it; this changes tipping flow timing and reduces same-day cash reconciliation friction.

Surcharging rules remain a per-jurisdiction concern. The EU continues to ban consumer card surcharging under PSD2 Article 62(4). US 2024 Visa rules cap credit surcharges at 3%. Both must be configured correctly in the new POS at cutover, not after the first audit.

Data migration: modifiers, loyalty, historical sales, gift cards

Data migration is where most projects lose 5 to 12% of menu-modifier fidelity unless modeled explicitly. The recurring problems:

• Modifier hierarchies in Aloha and Micros are deeply nested and often differ between sites. Lifting into a flatter modern POS structure loses combinations that customers actually order. A 24-unit chain typically discovers 200 to 800 missing modifier combinations in pilot.
• Loyalty data loses 10 to 30% of customer records on bad email hygiene. Multiple records per customer (same email, different names) merge inconsistently. Loyalty point balances need a defined reconciliation point.
• Gift card balances must transfer with full audit trail. Several acquirer relationships require explicit cutover certification for gift card programs.
• Historical sales for 24 to 36 months of comparable reporting is usually staged in a warehouse rather than imported into the new POS. The POS holds prospective data only; comparable reporting comes from a unified BI layer.
• Tax configurations must be reapplied per jurisdiction. Sites operating across multiple tax authorities need a per-site review.

The right time to scope migration data is in the pilot, not in the planning. The pilot site surfaces the actual cases the chain depends on; the planning estimate inevitably understates them.

A realistic migration timeline for a 24-unit chain

End-to-end, the project takes 9 to 14 months for a 20 to 50 unit operation in 2026:

• Months 1 to 2: vendor selection, contract, integration matrix scoping.
• Months 2 to 4: pilot site implementation, menu modeling, integration testing.
• Month 4: pilot stabilization, lessons-learned review.
• Months 5 to 9: wave rollout, 3 to 5 sites per week.
• Months 9 to 11: post-cutover stabilization, full integration coverage, BI reconciliation.
• Months 11 to 14: optimization, decommissioning of legacy hardware, residual data archival.

For a 100-plus unit chain, scale up the rollout phase but not the pilot phase. The pilot still runs in one location for the same window; the wave size grows.

Operators in 2026 who try to compress the timeline below 9 months almost always lose either menu fidelity, integration coverage, or reporting continuity. The legacy POS end-of-life is a deadline, but the cutover quality determines whether the migration is a win or a recovery story. The chains that picked their successor in early 2025 are now stabilizing on it. The chains that delayed are running into the deadline with smaller windows for testing and reconciliation. The lesson is straightforward: when the renewal letter arrives, the project starts that quarter, not the quarter the renewal expires.