Line-of-Business Apps That Can’t Move to the Cloud (and What to Do Instead)

Most line-of-business applications that cannot move to the cloud can still be hosted in the cloud. The blocker is almost never the software itself. It is a piece of attached hardware, a vendor support policy, or a latency problem that shows up the moment you separate the app from its database.

There is a sentence I hear a few times a year. Our software company says it does not support the cloud.

Sometimes that is true. Not often. More often it is a compressed version of something the vendor said that meant something narrower, and the compression is where the trouble starts. A vendor who says there is no hosted version of their product is telling you about their roadmap. A vendor who says they will not support their product running on a virtual machine is telling you about your options. Those are not the same statement. Only one of them actually limits what we can do for you.

So before anybody budgets for a cloud migration project, I want to pull that sentence apart. Our cloud and Microsoft 365 practice spends a fair amount of time on exactly this, and the answer is usually less dramatic than people expect.

The Word Cloud Is Doing Two Jobs Here

A line-of-business application is the software a company actually runs on. Estimating and takeoff. Practice management. Dispatch and routing. Case management. The program that, if it stops, people go home. When somebody says it cannot move to the cloud, they nearly always mean there is no subscription version of it. That is a product question. Not an infrastructure one.

Two very different things get called moving to the cloud.

• Replacing the app with a browser-based subscription product from the same vendor, or a competitor. This is the vendor’s decision and their timeline. You wait, or you switch products.
• Taking the exact same program, installing it on a server that happens to live in a Microsoft datacenter, and giving people a way to reach it. Nothing about the software changes. It does not know where it is.

The second one is available for almost everything. That is the part that gets lost. Almost everything.

Five Reasons an Application Really Does Stay Put

Now the honest half. Some things genuinely do not travel well, and I would rather name them than pretend every migration is clean. They are not.

Look at the right-hand column. One row says yes. Only one.

The vendor support policy is the only blocker on that list I cannot engineer around, because it is not an engineering problem. If a vendor puts in writing that a virtualized install voids support, you have a business decision in front of you, not a technical one. Every other row has a path through it. Some of those paths are ugly. I will say so when one is. But they exist.

The Dongle on the Back of the Server

Hardware dependency sounds like the hardest category and it is usually the easiest.

License dongles are still common in specialized software, and the pattern has barely changed in twenty years. A small USB key sits in a machine, the application checks for it on launch, and without it you get a licensing error and nothing else. No key, no program. Manufacturing, engineering, and medical software leaned on this heavily, and plenty of those products are still in production today at companies that have no interest in replacing working software.

Two normal ways through it. A USB-over-network appliance keeps the physical key on site and presents it to a virtual machine somewhere else. Or, if the vendor offers one, a network license server holds the entitlement and hands out seats to whoever launches the app.

Both work. Both also mean you still have a small piece of equipment in your building that the whole application now depends on, and I want that said plainly rather than buried. You did not eliminate the on-premises footprint. You shrank it. And you made what is left load-bearing. Sometimes that is a good trade. Sometimes it is not, and we leave the app where it is.

Lift It Into Azure and Hand People a Session

When an application cannot become a subscription product, this is the route I reach for most. Put the app on a Windows server in Azure, put the database next to it, and let people connect to a session rather than to the program.

The important detail is that the app and its database stay on the same fast network. They just both move. Together. Splitting them is what produces the complaints about a screen that used to open instantly and now takes nine seconds.

Two shapes this takes. The licensing is where people get caught.

Microsoft publishes the Windows 365 Business numbers, so you can price that half yourself before anybody quotes you. A two-processor Cloud PC with 8 GB of memory and 128 GB of storage runs $36 per user per month, the 4 by 16 configuration is $56, and a workstation-class 8 by 32 is $108.80. Microsoft’s own description of that entry configuration lists line-of-business applications as what it is for, which tells you something about who is buying it.

Azure Virtual Desktop is the more flexible option and the more conditional one. If your people are already on Microsoft 365 Business Premium, E3, or E5, the user access rights for Windows multi-session are already included in what you pay Microsoft, and you are only buying the Azure infrastructure underneath. That surprises people in a good way.

Then there is the trap. Run your session host on Windows Server instead of Windows multi-session and that entitlement does not apply. Every user or device connecting to a Windows Server session host needs a Remote Desktop Services client access license, either per user or per device, and for Azure Virtual Desktop specifically those CALs have to carry Software Assurance or be RDS User Subscription Licenses. Microsoft gives you a 120-day grace period before a license server is required. Then it stops. The symptom is not subtle. People cannot sign in.

One more number worth writing down. Microsoft’s guidance is that round-trip latency from your office to the Azure region hosting the session should stay under 150 milliseconds. From Rockland, Westchester, or Bergen to an East US region, that is not a close call. It is not close at all. Latency is a real constraint in this design, and it is not the one that will bite a Tri-State business.

Or Leave It on Site and Fix the Access Layer

Not every application needs to go anywhere.

If the software runs well, the server is healthy, and the only actual complaint is that people cannot reach it from home or from a job site, then the problem was never the application. It is the access layer. Different problem. Much cheaper one. Replacing working software because the remote access is bad is an expensive way to fix something small.

What I do not want you to do is the thing that gets typed into a firewall in about four minutes. Open port 3389 to the internet so people can remote in directly. CISA lists exposed remote desktop among the weak controls routinely exploited for initial access, and their guidance is consistent about it. Put it behind a VPN with multifactor authentication, or behind a gateway, and never hang it off a public IP on its own.

Worth noting that a properly built session host in Azure does not need an inbound port open at all. None. The connection is established outward from the host to the service over 443, which means there is no listening service on a public address for somebody to find with a scanner, no brute-force surface, and nothing to forget to close after a temporary change that was only supposed to last a weekend. That is a real security improvement over the on-premises version of the same idea, and it is one of the few arguments for moving that has nothing to do with cost.

What Actually Changes on the Invoice

Hosting a line-of-business app raises your cost per seat. I am not going to soften that. It goes up.

Locally hosted workstations running software off a server in your closet is the cheapest arrangement that exists, right up until the closet floods or the server does not come back from a reboot. Moving that same workload into an Azure environment with a session host costs meaningfully more every month. What you get for the difference is that disaster recovery stops being a project you keep meaning to schedule and becomes a property of how the thing is built. The server is already replicated. It lives somewhere with a generator.

That tradeoff is not specific to any industry. A construction company and a medical practice land in the same place on it, because the math is about how the environment is built, not about what the business does. Same numbers. If your backup and recovery position is currently one external drive and good intentions, then a portion of that monthly increase is not a new expense at all, it is a cost you have been carrying quietly and paying for in risk instead of in dollars.

For reference, our managed IT service starts at $995 a month, and hosted environments sit above that depending on what we are running for you. The project cost to get there is a separate number and it is driven by data volume and how many moving parts your application has, which is why I will not put a flat figure on it in a blog post.

The Order I Work Through This

When somebody brings me an application they have been told cannot move, this is the sequence. It has not changed much in twenty years.

• Get the vendor statement in writing. Not what the sales rep said on the phone. The actual support policy, because those two disagree more often than you would think.
• Find every piece of hardware physically attached to the current machine. Go look at the back of it. People skip this. It is the step that derails projects.
• Find out where the database lives and how big it is.
• Decide whether the app and the database can move together. If they cannot, stop. That is your answer.
• Price both routes honestly, the hosted version and the stay-put version with better access, and put them next to each other.
• Pick the boring one.

That last step is not a joke. The most common mistake I see is not a company that refuses to modernize. It is the opposite. Somebody moved a system that was working fine, because moving it sounded like progress, and then spent a year fighting problems they had created themselves.

If you are weighing whether the file server itself should go, that is a related but separate question, and I wrote through it in SharePoint and OneDrive versus a file server.

Questions That Come Up Once People Start Pricing This