Modernisation 9 min read

Desktop to Web App Conversion: A Practical Guide

What to expect when converting a Windows desktop application to a browser-based web app, including planning approaches and common pitfalls.

Best for: IT leaders, operations managers Practical guide for business decision-makers

Who this is for

IT leaders and operations managers considering converting a Windows desktop application to a browser-based web application.

Question this answers

What's involved in converting a desktop application to a web app, and how should we plan it?

What you'll leave with

  • Why desktop-to-web conversion makes business sense
  • What fundamentally changes in the conversion
  • Three conversion approaches with different cost/risk profiles
  • Common challenges and how to plan for them

Why move to a web app?

  • Remote access: Web apps work from anywhere with a browser. No VPN, no remote desktop, no installation.
  • Multi-device: Works on Windows, Mac, tablets, phones without separate builds
  • No deployment overhead: Updates happen once on the server, not on every user's machine
  • Integration: Web apps connect more easily to modern SaaS tools, APIs, and cloud services
  • Talent pool: Web developers are more abundant and often less expensive than desktop developers for legacy technologies

What changes in the conversion

A web app isn't just a desktop app in a browser. The architecture is fundamentally different.

Things that improve:

  • Accessibility from any device
  • Automatic updates
  • Better scalability (cloud-hosted)
  • Modern UI/UX possibilities

Things that change significantly:

  • Offline capability: Desktop apps work offline naturally. Web apps need specific architecture for offline use.
  • Local file access: Desktop apps read and write local files directly. Web apps need explicit file upload/download.
  • Hardware access: Printers, scanners, barcode readers. Desktop apps interact directly. Web apps use different methods.
  • Performance: Complex calculations that run instantly on a desktop may need server-side processing in a web app.

Conversion approaches

1. Full rebuild (most common): Build the web application from scratch based on current requirements. Uses modern web technologies. Highest quality result but longest timeline.

2. Progressive migration: Build the most important features as a web app first. Keep the desktop app for less-used features. Gradually migrate everything. Lower risk, faster initial delivery.

3. Wrapper approach: Use technologies like Electron or Tauri to wrap existing code in a web-like shell. Quickest path but doesn't deliver the full benefits of a true web app. Often a stepping stone rather than a final solution.

Planning the conversion

  1. Audit the desktop app: Document all features, screens, reports, integrations, and business logic. Involve end users. They know the undocumented workflows.
  2. Prioritise: Which features are essential for v1? Which can wait? Which aren't needed at all?
  3. Address web-specific concerns: Authentication, security, hosting, data migration, offline requirements, hardware access.
  4. Design for the web: Responsive layouts, browser-native interactions, web-friendly workflows.
  5. Plan data migration: Desktop databases (SQL Server, SQLite, Access) to cloud-hosted databases.
  6. Training plan: Users comfortable with the desktop app will need guidance on the web version.

Common challenges

  • Feature creep: "While we're rebuilding, let's add…" Keep the scope to feature parity first, then enhance.
  • User resistance: People who've used the desktop app for years may resist change. Involve them early in design.
  • Undocumented logic: Desktop apps accumulate years of business rules in code. These must be discovered and documented before rebuilding.
  • Performance expectations: Desktop apps feel instant because everything is local. Web apps have network latency. Design for it.

Ready-to-convert checklist

Tick these off before the rebuild begins

  • Desktop app features are fully documented
  • End users have been consulted on requirements
  • Web-specific requirements are identified (auth, hosting, offline)
  • Budget is aligned with a rebuild (not a quick port)
  • Timeline allows for parallel running of both systems
  • Data migration plan is realistic
  • Training and change management are budgeted

Key takeaways

  • Desktop-to-web conversion is a rebuild, not a migration. The application is rewritten for a different platform.
  • The biggest benefit is accessibility: web apps work from any device, any location, with no installation.
  • Some desktop features (local file access, hardware integration, offline-heavy workflows) work differently on the web
  • Plan for 4-12 months depending on application complexity
  • Consider a progressive approach: build the highest-value features as a web app first, keep the desktop for the rest
Legacy SystemsModernisationWeb Apps

Meet the person

Written by the person who does the work

This guide comes from real projects. If it raises a question about your own system, you can ask the founder directly.

HELLO PEOPLE designs, builds and looks after AI, software, app and data solutions for Australian businesses, with senior expertise on every project and a scope agreed before work starts. For an older system, that means learning what it really does first, so nothing your business relies on is lost.

Since 2007, HELLO PEOPLE has delivered more than 100 projects from Perth for small and medium businesses across Australia: custom software and apps, system integrations, data migrations, reporting and dashboards, and AI that works inside the systems a business already runs.

I lead every engagement myself. I trained in accounting before moving into IT, hold accounting and IT professional qualifications and an MBA, and bring more than 20 years of experience across sales, service delivery, inventory and compliance. I am also a PhD candidate in AI at Curtin University, researching retrieval-augmented generation (RAG), so the technology is always judged by what it does for the business.

  • An old-fashioned service

    Small and boutique. The person who scopes the work is the person who does it, and the same person is there when the old system is switched off.

  • Quick responses

    No ticket queue and no account manager in between. You hear back within one business day, usually sooner.

  • A long-term partner

    The upgrade is the start, not the end. When you need the next system, integration or report, you call the same person, who already knows your business.

Related guides

Modernisation 10 min read

Rebuild vs Modernise vs Patch

Deciding on the right modernisation approach.

Read guide
Modernisation 9 min read

Legacy Software Modernisation Guide

Broader modernisation planning.

Read guide

Ask the author

Still have a question?

Ask it here and it comes straight to the founder. No sales call, no obligation, and a real answer even if the answer is that you do not need us.

Kasun Wijayamanna, Founder Kasun Wijayamanna
Founder, replies within one business day

Get Started

Want help choosing the right next step?

Tell us what you are comparing, replacing, or trying to improve. We will come back with a practical recommendation and realistic scope.

Australian owned and operated

Built here. Your data stays here.

  • No offshore development. Everything is written by our own team in Australia. Nothing is subcontracted overseas.
  • Your data stays onshore. Hosted in Australia, on infrastructure you own, under Australian law.
  • Every state, not just ours. Perth, Melbourne, Sydney, Brisbane, Adelaide and everywhere between.