Windows desktop application to web

Because the business has left the office and the system hasn't. People work from home, from vans, from sites and from customers' premises, and a system that only runs on the PCs in one building has stopped fitting how the work happens. Installing it on every laptop, keeping every copy on the same version, and getting it through a VPN are the daily costs.

The other reasons arrive one at a time. A customer wants to see their own orders. A driver needs to confirm a delivery on a phone. A new starter is on a Mac. The IT company won't support the old runtime any more. Each is a reason to put one process on the web, and that's the right unit to think in.

Carries over. The data model, nearly always. The business rules, once they've been found: pricing, validation, status flows, the checks the office relies on. The reports, as a specification of what people need to see. Years of records.

Doesn't. The screens. A desktop form with forty fields, a grid, six buttons and keyboard shortcuts the office has used for a decade doesn't translate to a browser, and it translates worse to a phone. The web version of that screen is designed from the process, not copied from the form. That's the part of the project that needs care and the part that pays back most, because the desktop form was usually shaped by the tool that built it rather than by the work.

Changes shape. Printing, barcode scanners, label printers, local file access and anything that talked to hardware on the PC. All solvable on the web, all needing a decision rather than an assumption.

1. Map it. The assessment writes down what the desktop system does, which screens serve which processes, and what depends on the database besides the application.
2. Put the data somewhere both can reach. If it's already SQL Server, nothing moves. If it's an Access file or a local database, it moves to a server first, and the desktop application is re-pointed at it. The desktop system keeps working; it's now sharing a database.
3. An API over the database. A thin layer that enforces the business rules once, so the desktop application and the new web screens can't disagree about what a valid order is.
4. One process as a web screen. The one that most needs to leave the building: the driver's delivery confirmation, the site manager's timesheet, the customer's order history. Built, tested on a copy, run in staging alongside the desktop system on the same data, checked by the people who use it, then live. The desktop screen for that process stays available.
5. Repeat, in order of value. Each screen is a stage with its own fixed price. Some desktop screens may never move, because nobody needs them outside the office, and that's fine.
6. Retire the desktop application when the last screen that matters has moved, or keep it for the back-office jobs it still does well.

No cutover weekend. No day when the old system is switched off and the new one has to work.

It stays in one place throughout, which is the point of doing the data first. Both applications read and write the same database, so there's no synchronisation and no day when two versions of the truth exist. Any move of the data itself, from a file to a server, is tested on a copy, then run in staging with counts and totals reconciled, before anything connects to live.

That's the only way we do it. The desktop application and the web application run side by side for as long as the migration takes, sharing the database. Users move one process at a time, and the ones who never leave the office may keep the desktop screens they know. Each stage is priced before you commit to it, and you can stop after any stage with a working system.

The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a desktop-to-web move it establishes where the data is, where the rules live, which processes need to leave the building, and what hardware the screens talk to, then prices the first stage and the rest as fixed numbers. What drives the price and the payment terms each have a page.

The rewrite. A desktop-to-web project that tries to rebuild every screen before going live is the one that drags on and gets cancelled. Staging it by process is the protection.

The second risk is copying the desktop screens onto the web as they are. It feels safe because the office knows them, and it produces a web application that's worse than the desktop one on a laptop and unusable on a phone. Designing from the process is more work up front and the only version that pays back.

Data first, rules once, screens by process. Marc Allington has built desktop and client-server business systems and web applications and has moved work between the two, so the trade-offs are familiar. Everything we build runs on open, widely used technology, React and Node or .NET over SQL Server or PostgreSQL, in your own accounts, with full source code and ownership transferring to you on final payment.