When Should You Rewrite vs Publish Your Application?

If you build Windows software, you have probably felt the pressure. Your customers want browser access, single sign-on, and the kind of always-current experience they get from every other tool they use. Your application already does its job, but it was not built for the web. That leaves most independent software vendors (ISVs) weighing the same choice: rebuild the whole thing as a web-native app, or find a faster route to the cloud. This is the rewrite vs application publishing decision, and it sits at the center of nearly every Windows app modernization conversation happening in 2026.

The instinct is often to assume modernization means replacing old code with new code. In practice, it is a set of decisions about how your application is delivered, accessed, and maintained, not just how it was written. Choosing well can save you years of work. Choosing wrong can put your roadmap, and your customer base, at risk.

What a Rewrite Actually Involves

A rewrite means you rebuild the app for the web from the ground up. It touches every workflow, every integration, and every line of code your customers depend on. Done well, it gives you a truly web-native codebase. Done at scale, it is one of the largest projects an ISV can take on.

Before committing, it helps to see the full scope of what a rewrite demands:

• Personnel: you need a development team with the skills to rebuild the app in a reasonable timeframe, while keeping the existing product running at the same time.
• Feature parity: matching an established Windows application feature for feature is extremely difficult, and some well-loved capabilities may have no web equivalent.
• Time to market: for complex, feature-rich products, a full rewrite can take years before it reaches customers.
• Integrations and hardware: printers, scanners, sensors, and other peripherals that work seamlessly on the desktop are hard to replicate in a browser.
• User adoption: customers who are happy with the current app are often reluctant to relearn a new interface.

What Application Publishing Actually Involves

Application publishing takes the opposite approach. Instead of rebuilding your app, you host it on a Windows server and deliver its interface to any browser or device. The application runs on the server and behaves as if it were installed locally, but users reach it through a web link with no local install.

Because the code stays exactly as it is, application publishing touches none of your workflows or integrations. Your team keeps shipping features on the product they already know, while users get the browser-based, SaaS-like experience they are asking for.

‍

{{CTAEMBED_IDENTIFIER}}

‍

When a Rewrite Makes Sense

A rewrite is not always the wrong answer. There are cases where rebuilding is the right long-term investment:

• Your core architecture is genuinely obsolete and can no longer be maintained or secured.
• Your differentiation depends on capabilities only a native web or mobile architecture can deliver.
• You have the budget, the engineering bandwidth, and the runway to sustain a multi-year project without stalling your roadmap.
• You are planning to fundamentally change what the product does, not just how it is delivered.

If none of those describe your situation, a rewrite may be solving a delivery problem with a development project.

When Application Publishing Is the Smarter Path

For most Windows ISVs, the pressure to modernize is really a pressure to deliver. Publishing tends to be the better call when:

• Your application works well and your customers value it as is.
• The real request is browser access and remote work, not a different feature set.
• You want to reach the market in weeks, not years.
• You need to preserve integrations with printers, peripherals, or external systems.
• You would rather invest your engineering time in the product than in a platform migration.

Making the Rewrite vs Application Publishing Decision

So how do you actually choose? Working through the rewrite vs application publishing decision is easier when you answer a few questions in order:

1. What is the goal? If it is a better delivery experience, publishing likely gets you there faster. If it is a fundamentally different product, a rewrite may be warranted.
2. What is the cost of waiting? Estimate how long a rewrite would realistically take, then ask what that delay costs you in lost deals and churn.
3. What will you lose? Inventory the Windows-specific features and integrations a rewrite would put at risk.
4. What can you deliver now? A publishing layer can give customers cloud access immediately, buying you time to plan any deeper modernization on your own schedule.

For many vendors, the honest answer is that publishing solves the immediate problem, and a rewrite, if it ever happens, can wait until it is truly justified.

Where Your Published Application Runs

Once you decide to publish rather than rewrite, the next question is where the application actually runs. GO-Global lets you publish your existing Windows application to any browser or device from a server in any public, private, or hybrid cloud, with no code changes. For vendors that would rather not manage that infrastructure themselves, ISVHost, GraphOn's hosting platform for ISVs, runs the servers, scaling, and delivery for you, so your team can stay focused on the application itself.

Choosing the Path That Protects What Works

Windows app modernization does not have to mean betting your roadmap on a full rebuild. In most cases, the fastest path to a modern, cloud-delivered experience is to publish the application you already have, and to save a rewrite for the rare case that genuinely calls for one. The decision is not rewrite or nothing. It is choosing the approach that gets your customers what they want with the least risk to what already works. Are you a Windows ISV exploring cloud-based application delivery? Contact us to learn how GO-Global can help you streamline software access for your end users. Or download a free trial to test it yourself.