Sage 100 on the web: three ways to access it remotely

The request always arrives the same way: a salesperson on the road wants to check a customer balance, an executive wants their numbers from home, a warehouse operator wants to log a receipt without walking back to the office. And it always hits the same fact: Sage 100c is a Windows application, designed to run on a workstation connected to the local network.

There are three serious ways to open Sage 100 beyond that perimeter. They do not deliver the same service, and the right answer is often a combination.

Option 1 — remote desktop

The classic route: publish the application through Windows Remote Desktop Services (RDS, formerly known as TSE) or an equivalent tool. The remote user opens a session on the server and finds Sage exactly as it is at the office.

It is the complete solution — all of Sage, every function — and that is its strength. Its limits are well known: licences and infrastructure to size, an experience that remains a relayed Windows screen (unpleasant on mobile), and an exposed surface that needs serious hardening — a remote desktop server open to the Internet without a gateway and MFA is an invitation.

For the user doing heavy accounting entry from a distance, it remains the reference.

Option 2 — third-party hosting

A variant of the first: Sage and its database leave your premises for a datacenter, and remain reachable through the same remote-session mechanism. Infrastructure becomes a subscription; backups and availability become contractual.

This choice commits more than it appears to: your management data lives at the host, service quality depends on the link, and customisations and interfaces with your other systems must follow. For a company subject to data-residency requirements, that point gets verified before signing.

Option 3 — a web layer wired into the database

The third route does not try to relay Sage’s screen: it gives access to Sage’s data from a web application. Sage stays installed where it is and remains the system of record; a web application connects to its SQL Server database and serves what the field actually consumes — looking up a customer and their balance, taking an order, running a stock count, indicators, approving documents — from a browser or a phone.

That is the architecture of OptiFlowPro, and it has one practical consequence: the remote user needs neither a Sage licence nor a Windows session. A salesperson, a warehouse operator or an executive works in a web interface built for their task, while the entries keep living in Sage. How reads and writes are separated is detailed here: direct reads on the database, controlled writes through a dedicated web service.

The limit is symmetrical to the remote desktop’s: a web layer does not replace the Sage client for configuration or production accounting. It does not aim to.

Choosing — and combining

The question to ask is not “how do we put Sage on the web?” but “who needs access to what, from where?”. In practice the answer draws almost always the same map: a few expert users on remote sessions for heavy accounting work, and everyone else — sales, logistics, management — on a web layer, because what they need is a specific flow, not the whole application.

It is an architecture decision before it is a software purchase, and it is best made from an audit of the existing installation — versions, licences, infrastructure, security requirements. That is where we start.