Multi-Tenant POS Platform: Build, Operate, Transfer

Envadel was engaged under a full Build-Operate-Transfer contract spanning 12 months with three defined phases: Build (months 1-4) — architecture, development, and deployment of the new multi-tenant POS platform; Operate (months 5-8) — running the platform in production, migrating locations incrementally, stabilizing, and optimizing; Transfer (months 9-12) — hiring support, training, documentation, and gradual handover to the client's new internal team.

The approach prioritized incremental migration: the new platform was deployed alongside the legacy system, with locations migrated in waves of 20-30 restaurants. Each wave included a pilot phase (2-3 locations for 1 week), validation, and then bulk migration. A real-time data synchronization layer ensured that corporate reporting was accurate regardless of which platform individual locations were running on.

Each BOT phase had explicit exit criteria and executive sign-off gates. The Build phase required passing acceptance tests for all core modules (orders, payments, inventory, reporting, multi-tenancy). The Operate phase required 200+ locations successfully migrated with 99.5%+ uptime. The Transfer phase required documented architecture, runbooks, on-call procedures, and a new internal team independently operating for 30 days.

The new platform was built on Node.js with TypeScript for the backend services and React with TypeScript for the frontend (POS terminal interface, kitchen display, management dashboard). PostgreSQL was the primary database, using row-level security (RLS) policies and tenant-scoped schemas to enforce data isolation at the database level — ensuring that no query from one tenant could ever access another tenant's data, even in case of application-level bugs.

Redis served multiple purposes: session management for POS terminals, real-time order queue synchronization between POS and kitchen display systems, and caching of menu configurations and pricing rules. An event-driven architecture using RabbitMQ handled asynchronous workflows: payment processing confirmations, inventory updates, and cross-location reporting aggregation. Each location maintained a local event buffer for offline resilience — if connectivity dropped, the POS continued operating and synchronized when reconnected.

The infrastructure ran on Azure (client's existing cloud provider), fully codified with Terraform. AKS (Azure Kubernetes Service) hosted the application layer with auto-scaling configured per service. Azure Database for PostgreSQL provided the managed database tier with automated backups, point-in-time recovery, and read replicas for the reporting workload. Azure CDN served the React frontend, and Azure Front Door provided global load balancing and WAF protection.

The migration tooling was purpose-built: a custom ETL pipeline extracted data from the legacy MySQL database, transformed it into the new multi-tenant schema (adding tenant IDs, normalizing menu structures, mapping legacy payment references), and loaded it into PostgreSQL. Each location's migration was atomic and reversible — if any validation check failed, the location was automatically rolled back to the legacy system with zero data loss.

The Build phase (months 1-4) followed 2-week sprints with demo sessions every sprint to the client's CTO and operations director. The first production deployment (pilot with 3 locations) happened at the end of month 3, providing early real-world feedback that shaped the remaining build work. Key decisions — like adding offline resilience capabilities — emerged from this pilot feedback.

The Operate phase (months 5-8) shifted to a dual track: ongoing feature development in sprints plus a dedicated migration workstream. Locations were migrated in waves of 20-30, with each wave taking approximately 2 weeks (pilot → validate → bulk migrate). A war room was established during migration weekends with both Envadel and client operations teams present for real-time issue resolution.

The Transfer phase (months 9-12) was structured around knowledge transfer and team building. Envadel's team conducted 40+ hours of recorded training sessions covering architecture decisions, operational runbooks, deployment procedures, and troubleshooting guides. The client hired 4 new engineers during this phase, each paired with an Envadel engineer for hands-on knowledge transfer.

Executive reporting followed the same cadence throughout: weekly status, monthly executive summary, and phase-gate reviews at each transition (Build→Operate, Operate→Transfer). The Transfer was formally completed when the client's team operated independently for 30 consecutive days with metrics meeting the agreed SLA thresholds.