When a custom application goes live, most attention is on features: the screens, the reports, the mobile app. Far less attention goes to where the software runs, how its data is protected and what happens when something fails. Yet these decisions determine whether the system is available when your team needs it, whether a mistake or attack can be recovered from, and whether you remain in control of your own software. This guide explains, in business terms, the hosting and operations decisions every owner of business software should understand.
Why owners should care
Imagine three mornings. On the first, the system is slow because last month's growth in data was never planned for. On the second, an employee accidentally deletes a batch of customer records, and nobody is sure whether yesterday's backup worked. On the third, the developer who set up the server has left, and nobody else has the password to the hosting account. None of these are coding problems. All of them are common, and all of them are prevented by decisions made — or not made — at launch.
Where to host
Cloud hosting
Most modern business applications run on cloud infrastructure from large providers. The advantages are considerable: professional data centres, redundant power and networking, managed databases with automatic backups, the ability to add capacity quickly and a wide range of security tools. You pay for what you use, and nobody in your office has to maintain hardware.
Within cloud hosting, there is a spectrum. At one end, you rent virtual servers and manage the operating system and software yourself (or through your partner). At the other end, you use managed services — managed databases, application platforms, storage — where the provider handles much of the maintenance. Managed services cost more per unit but reduce operational work and risk, which often makes them cheaper overall for small teams.
On-premise hosting
Running servers in your own premises still makes sense in certain cases: systems that must keep working when the internet is down (for example, shop-floor systems in factories with unreliable connectivity), strict data residency or regulatory requirements, very large data volumes generated locally, or existing infrastructure with skilled staff. The responsibilities are heavier: hardware, power, cooling, physical security, backups, off-site copies and replacement cycles all fall on you.
Hybrid
Some businesses combine both: a local system on the shop floor that synchronises with a cloud application, or cloud hosting for the main system with local caching for sites with poor connectivity. Hybrid designs add complexity and should be chosen for a clear reason.
Environments: not just "the server"
A professionally run application has more than one environment:
- Production — the live system your team and customers use.
- Staging or test — a copy of production used for testing new releases and for user acceptance testing.
- Development — where developers build and try changes.
Changes should flow from development to staging to production, never directly into production. Staging should be close enough to production — same software versions, similar data — that problems are found there first. Testing on production "just this once" is a common cause of incidents.
Backups that actually restore
Backups are the most important and most neglected part of hosting. Two questions should drive your backup design:
- How much data can we afford to lose? If the system failed now, would losing the last 24 hours of data be acceptable? The last hour? The last five minutes? This is called the recovery point objective.
- How quickly must we be working again? Can the business cope for a day, an hour, a few minutes? This is the recovery time objective.
The answers are business decisions. An internal reporting tool might tolerate a day's data loss and a day's downtime; an order-taking system for a busy distributor might tolerate neither.
Good backup practice
- Automatic, scheduled backups of databases and uploaded files — never dependent on someone remembering.
- Multiple copies, including at least one stored separately from the main hosting account or region, so a single failure or compromised account does not destroy everything.
- Retention — daily backups kept for weeks, plus weekly or monthly backups kept longer, so problems discovered late can still be recovered.
- Encryption of backups, with keys managed carefully.
- Regular restore tests — the only proof that backups work.
Many organisations discover their backups were incomplete only when they need them. A quarterly restore test, documented in a few lines, removes that risk.
Uptime and monitoring
"Uptime" is the share of time the system is available. Hosting providers publish availability commitments for their infrastructure, but your application's uptime also depends on the application itself, its database, third-party services it relies on and how changes are deployed.
Monitoring
Someone should know about a problem before your users call. Basic monitoring includes:
- Availability checks that test the application every minute or so from outside.
- Error tracking that records and alerts on application errors.
- Resource monitoring — CPU, memory, disk space, database performance.
- Alerts for failed backups and failed scheduled jobs (such as nightly reports or synchronisations).
- Certificate and domain expiry reminders.
Alerts should reach named people with clear responsibilities, not an unmonitored mailbox.
Planned maintenance
Updates and releases sometimes require brief downtime. Agree maintenance windows at times your business is quiet, announce them in advance, and prefer deployment methods that avoid downtime for routine releases.
Performance and scaling
Business applications slow down for predictable reasons: growing data, inefficient reports, more users, heavy file uploads. Plan for growth from the start: database indexes for common searches, archiving or summarising old data, background processing for heavy reports, file storage separate from the application server, and the ability to add capacity. Review performance a few times a year; slow screens are often fixed cheaply if caught early.
Security responsibilities
Cloud hosting follows a shared responsibility model: the provider secures its data centres and infrastructure; you (and your development partner) are responsible for how the application, data and accounts are configured. Key responsibilities on your side include:
- Strong authentication, including multi-factor authentication for hosting and admin accounts.
- Regular updates to operating systems, frameworks and libraries.
- Network rules that expose only what must be public.
- Encryption of data in transit and, where appropriate, at rest.
- Least-privilege access for staff and developers, removed promptly when people leave.
- Logs retained for investigation.
Who controls the accounts
This is the single most important non-technical decision. The hosting account, domain names, email sending services, app store accounts, payment gateways and other third-party services should be registered to your business, with billing in your name and at least two people in your company holding owner-level access. Your development partner should have their own access, granted by you and removable by you.
Too many businesses discover, years later, that their domain or hosting account is registered to a former developer or agency. Recovering it can be slow, expensive and sometimes impossible.
Keep a simple register of every account the system depends on: provider, purpose, owner in your company, renewal date and who has access.
Disaster recovery
Beyond everyday backups, consider larger failures: a hosting region outage, a ransomware attack, a compromised administrator account, or a serious mistake during a release. A disaster recovery plan answers:
- Where would we restore the system, and how long would it take?
- Which backups would we use, and are they protected from the same failure?
- Who decides to invoke the plan, and who does the work?
- How do we communicate with staff and customers in the meantime?
- How do our people keep working manually if needed?
For most small and mid-sized businesses, the plan can be a few pages. Rehearse it once a year, even as a desk exercise.
Costs to plan for
Hosting costs are ongoing and depend on usage, providers and the services chosen. Plan for compute, database, storage, backups, bandwidth, monitoring tools, email and messaging services, domain and certificate renewals, and the time your partner spends on operations. Review the bill periodically — unused resources and oversized servers are common sources of waste.
A launch checklist
| Area | Question | Done? |
|---|---|---|
| Ownership | Are hosting, domain and third-party accounts in the company's name with two internal owners? | |
| Environments | Do we have separate production and staging environments? | |
| Backups | Are automatic backups running, stored separately and tested by restore? | |
| Recovery objectives | Have we decided acceptable data loss and downtime? | |
| Monitoring | Will named people be alerted to downtime, errors and failed jobs? | |
| Security | Is MFA enabled on admin accounts? Are updates scheduled? | |
| Scaling | Do we know how the system will handle twice today's data and users? | |
| Disaster recovery | Is there a written plan, and has it been rehearsed? | |
| Documentation | Is the setup documented so another team could take over? |
Example
A distributor's order system ran on a single server rented years earlier by a freelance developer, with backups copied to the same server. When the developer became unreachable and the server's disk began failing, the company discovered that the hosting account was in his name and the backups were on the failing disk. Recovery took days and some data was lost. When the system was later rebuilt, the company insisted on hosting in its own account, managed database backups with copies in a separate region, quarterly restore tests, monitoring with alerts to two staff members and a one-page disaster recovery plan. Two years later, an accidental bulk deletion was recovered within an hour from point-in-time backups.
Summary
Hosting and operations decide whether business software is available, recoverable and under your control. Choose hosting that fits your needs — usually managed cloud services — with separate environments. Decide how much data loss and downtime you can tolerate, design backups to match and test restores regularly. Monitor the system, plan for growth, share security responsibilities clearly, keep every account in your company's name and write a short disaster recovery plan. These are not technical details to leave to chance; they are business decisions.
Frequently asked questions
Should business software be hosted in the cloud or on our own server?
For most businesses, a reputable cloud provider offers better reliability, security and backup options than a server in the office. On-premise hosting still makes sense in specific cases, such as strict data residency rules, factory systems that must work without internet, or existing infrastructure with skilled staff.
Who should own the hosting account?
Your business. The development partner can manage it with their own access, but the account, billing and ultimate control should be in your company's name so you are never locked out.
How often should backups run?
It depends on how much data you can afford to lose. Many business systems take automatic database backups at least daily, with more frequent point-in-time backups for critical data. The answer should come from a business decision, not a default setting.
How do we know backups work?
Test restores regularly — for example, restore last night's backup into a separate environment every quarter and check that the data and application work. A backup that has never been restored is only a hope.
What uptime should we expect?
Well-hosted business applications commonly achieve very high availability, but planned maintenance and rare incidents happen. Agree expectations, maintenance windows and response times in your support arrangement.
