Almost every organization we assess has at least one application that cannot move to a modern cloud service this year. An ERP system, a practice management platform, a county application mandated by the state, or software written for the business a decade ago by someone who has since retired.
Two problems that get confused
There is a hardware problem: the server is old, out of warranty, and sitting in a room that is not a datacenter. There is also a software problem: the application is dated and will eventually need replacing.
These get treated as one problem, which is why they stall. Replacing the application is a long project with a real budget, so the hardware keeps running past the point where it should.
Hosting separates them. The hardware problem is solved now. The software decision gets the time it deserves.
What we check before agreeing to host
Not everything should be hosted, and we say so when it should not:
- Does the application run on a supported platform, or can it be brought to one?
- What is the software vendor's position on hosted deployment?
- How is licensing handled for the hosted model?
- What security exposure does the application create, and can it be contained?
- Does it require local hardware such as dongles or serial devices?
- Will performance over the network satisfy the people who use it all day?
Being honest about the limits
Hosting improves everything around an application: power, redundancy, backup, monitoring, access control. It does not fix vulnerabilities inside outdated software.
So we treat it as a bridge. The organization eliminates failing hardware immediately, and in parallel builds a realistic plan for replacing or upgrading the application. We revisit that assessment as the application ages, because a bridge with no far end is just a delay.