Wholesale trading · 2026

Modernising a legacy desktop system to the web

A wholesale trader ran sales, purchasing, stock and accounts on a desktop application installed on every PC, with only one developer left who knew it. The system moves to a web platform one module at a time, with both systems sharing data during the move, so not a single day of trading is lost.

Built by

Tech leadUI/UXFrontendBackendDevOpsQA

Client: Withheld at the client’s request
Approach: Module by module
Platforms: Web
Typical timeline: 6–9 months
Squad: 6 people · 5 disciplines

Technologies

Laravel
Next.js
PostgreSQL
SQL Server
Redis
Change data capture
Docker
GitHub Actions

The product

10 images

The same shortcuts, now in a browser
Every module switch can be undone
The new system must agree with the old one
One item across five branches, whichever system each branch still runs on
Purchase orders typed from the keyboard, with suggested quantities
The statement balance is checked against the old accounts system
A weekly printed report, now filtered on screen and refreshed every 15 minutes
Before: the same invoice in the old desktop system
Roles per branch, approval limits and a log of every change
Branch managers approve invoices and orders from their phones

Brief

The business ran on software nobody could change.

Context

The desktop system had grown for many years around the company’s way of working. It ran on a local server and had to be installed on every PC.

Problem

Remote work was impossible, branches synced overnight, reports were slow, and every change depended on one developer.

Goals

Replace it without stopping the business
Work from any browser, in any branch
Keep what users rely on
Own the code and the data

Team

The squad behind it.

Tech leadMigration plan, data mapping and cut-over	×1	Migration plan, data mapping and cut-over	Senior
Product designerRedesigned flows that keep users’ habits	×1	Redesigned flows that keep users’ habits	Senior
Frontend engineerWeb app with keyboard-first screens	×1	Web app with keyboard-first screens	Senior
Backend engineerNew API and data sync with the old database	×1	New API and data sync with the old database	Senior
DevOps engineerEnvironments, sync monitoring and rollback	×1	Environments, sync monitoring and rollback	Senior
QA engineerOld-versus-new comparison tests	×1	Old-versus-new comparison tests	Senior

Meet the team

UI/UX design

New screens, familiar habits.

Who worked on it

UI/UXFrontend

We sat with the people who used the old system every day and kept what made them fast: the same shortcut keys, the same order of fields, the same codes. Everything else was redesigned to be clearer.

Keyboard-first Arabic sales invoice with dense fields, an item search showing stock per branch and a shortcut bar. — The same shortcuts, now in a browser

The old Windows desktop system showing the same sales invoice in grey windows with small fonts, a cramped grid and an error message box. — Before: the same invoice in the old desktop system

Same shortcutsMuscle memory kept.
Clearer reportsFilters instead of fixed printouts.
Side-by-side trainingUsers try each module before switching.

Frontend

As fast as the desktop, from a browser.

Who worked on it

UI/UXFrontend

Data-entry screens work entirely from the keyboard, open in a fraction of a second and save drafts as you type. Branches open the same system in a browser, with nothing to install.

Keyboard-first Arabic purchase order with supplier, delivery date, lines with last purchase price, a suggested quantity and the approval route. — Purchase orders typed from the keyboard, with suggested quantities

Arabic phone view for a branch manager: today's sales and collections, invoices and orders awaiting approval, and items below reorder level. — Branch managers approve invoices and orders from their phones

Keyboard firstNo mouse needed for data entry.
Drafts savedNothing lost if a tab closes.
No installationAny branch, any PC.

Backend & architecture

Two systems, one set of data, until the last day.

Who worked on it

Tech leadBackend

The new platform is built beside the old one. Changes in the old database are captured and copied to the new one, and modules move over one at a time — reports first, then purchasing, then sales — until the old system is switched off.

Arabic stock inquiry for one item: on-hand, reserved and available stock per branch and warehouse, reorder alerts and recent movements. — One item across five branches, whichever system each branch still runs on

Permissions matrix for sales, warehouse, accounts and branch manager roles, with amount limits, one user's roles per branch and a log of changes. — Roles per branch, approval limits and a log of every change

Decision 1
Gradual replacement, not a big-bang rewrite
The business can’t risk a cut-over weekend that fails.
Trade-off · Two systems run side by side for months.
Decision 2
Change data capture from the old database
The old code is untouched, so nothing breaks there.
Trade-off · Sync lag is watched around the clock.
Decision 3
Reports move first
Read-only screens prove the new data is right before anyone writes to it.
Trade-off · Managers see the benefits before data-entry staff do.

DevOps

Every module switch can be undone.

Who worked on it

BackendDevOps

Each module goes live behind a switch per branch, so it can be turned on for one branch first and turned back if needed. Sync health, data differences and errors sit on one dashboard for the whole migration.

Migration control with modules switched on per branch, sync lag over the day, data mismatches and per-branch rollback. — Every module switch can be undone

Per-branch switchesOne branch first, then the rest.
Sync dashboardLag and mismatches visible live.
Rehearsed cut-overPractised on a copy before the real day.

The new system must agree with the old one.

Who worked on it

BackendQA

For every module, the same invoices, stock movements and reports are produced in both systems and compared line by line. A module switches over only when the two agree.