Insight

Managed or unmanaged hosting: what should a Caribbean business choose?

Managed or unmanaged hosting: what should a Caribbean business choose?
Share
Short answer

For most Caribbean businesses, managed hosting is the right choice. Unmanaged hosting is cheaper only on the invoice: it moves patching, monitoring, backups, hardening and incident response onto your own staff. Choose unmanaged only if you genuinely employ someone to run servers. Everyone else should treat managed hosting as a cost of being online.

For most Caribbean businesses the honest answer is managed hosting. Unmanaged hosting is only cheaper on the invoice; it moves the real work of patching, monitoring, backups, security hardening and incident response onto your own staff, who almost never have the time or the tooling to do it properly. Choose unmanaged only if you employ someone whose actual job is to run servers, and who will still be there in eighteen months. Everyone else should pay for managed hosting and treat it as part of the cost of being online.

This guide is for business owners, association executives and operations managers in Jamaica and the wider Caribbean choosing where to put a website, a member portal or a business application. It covers what each term really means, what is genuinely included in managed hosting, what quietly becomes your problem on an unmanaged plan, the security baseline every business site needs, latency and uptime for a local audience, the questions to ask a host, and how to move without going offline.

What “managed” and “unmanaged” actually mean

The two words have no agreed definition in the market, which is exactly why they are used so loosely. A reseller in Kingston can sell you a JMD 2,500 per month plan (about US$16) and call it managed because someone answers a support ticket. A large international provider can sell you a bare virtual machine and also call it managed because they keep the physical hardware alive. Both are technically defensible and neither tells you what you need to know.

Read the words instead as a line drawn across a stack. Below the line the provider is responsible; above it, you are. Unmanaged hosting draws that line very low: the provider keeps the hardware, the network and possibly the operating system image running, and everything above is yours. Managed hosting draws it high: the provider owns the server, the software stack, the security posture, the backups and the behaviour of the site in production, and you own your content and your business decisions.

So the question to ask a vendor is never “is this managed?” It is “which of these specific tasks do you perform, and which do I perform?” Make them answer task by task. The answers are usually revealing.

What genuinely sits inside managed hosting

A managed plan worth paying for covers the following, in writing:

  • Provisioning and configuration of the server, web server, database and runtime, tuned for your application rather than left at defaults.
  • Operating system and stack patching on a stated cadence, including out-of-band patching for critical vulnerabilities.
  • Security hardening: closed ports, disabled unused services, enforced file permissions, blocked execution in upload directories, hardened administrative paths.
  • Monitoring of uptime, resource use, error rates and certificate expiry, with alerts that reach a human who acts on them.
  • Backups with tested restores. Backups nobody has ever restored are not backups. The restore is the product.
  • An uptime response commitment: a stated target and a stated time within which someone begins work when the site is down.
  • Performance tuning: caching layers, image handling, database optimisation, content delivery configuration.
  • A staging environment so changes are tested somewhere other than the live site.
  • SSL certificate and DNS management, including renewal, which is one of the most common causes of an avoidable outage.
  • Plugin, theme and dependency updates, applied on staging first and rolled back if they break something.
  • Incident response: a named process for what happens when the site is hacked, defaced or down, including cleanup and root cause.

Our own managed cloud hosting is built around that list, because it is the list that decides whether a site survives its third year.

What shared hosting actually gives you

Shared hosting gives you space on a server you share with dozens or hundreds of other sites, a control panel, an email account or two, and an automatic installer. It is a genuinely good product for a personal blog or a first small site with no revenue attached to it.

What it does not give you is isolation, meaningful monitoring, application-level security, a staging environment or anyone who notices when your site goes down at nine on a Friday night. Support is reactive by design: you open a ticket, and the answer is frequently that the issue is inside your application and therefore outside their scope. That answer is correct. It is also useless to you.

The hidden work that falls on your team with unmanaged hosting

On an unmanaged plan somebody in your organisation has to do the following: watch for security advisories, apply patches, test that the patches did not break the checkout or the member login, renew certificates, verify that backups ran, periodically restore one to prove it works, review access logs, remove staff accounts when people leave, tune performance when traffic grows, and be awake and available when something breaks.

Realistically that is a few hours in a quiet month and an entire week in a bad one. Most Caribbean MSMEs and associations do not have that person. The work gets assigned informally to whoever is most comfortable with computers, done inconsistently for a while, then stops. The site keeps working, which is the dangerous part: the absence of visible failure is mistaken for safety, and the failure arrives later and all at once.

Price the staff time honestly. If a competent technical person spends even a few hours a month doing this properly, managed hosting is usually the cheaper line item. Indicative market ranges for managed business hosting in the region run from roughly JMD 12,000 to JMD 60,000 per month (about US$75 to US$375) depending on the size of the site, traffic and response commitment. Those are indicative ranges for budgeting, not quotes.

Why cheap shared hosting sits behind most hacked sites in the region

When we are called in to clean up a defaced or hijacked WordPress site in Jamaica, the pattern is close to identical. The site was built two to five years ago, often well, then put on the cheapest available shared plan. Nobody owned it after launch. Plugins went unpatched for a year or more, an abandoned plugin with a known vulnerability was still active, the administrator account was called “admin” with a reused password and no second factor, and there were no off-server backups, so cleaning up meant rebuilding rather than restoring.

None of that is exotic. Attacks on small business sites are automated and indiscriminate: scanners sweep the internet for known vulnerable versions and exploit whatever answers. Being small, local or uninteresting is not protection, because nothing in the process is looking at who you are. The defence is boring and mechanical, which is precisely why it needs to be somebody’s job.

The security baseline every business site should have

Whatever you decide about hosting, this is the minimum. Treat anything missing as an open item with a name and a date against it.

  • A stated patching cadence for the operating system, the application core, plugins and dependencies, with critical fixes applied out of cycle.
  • Least-privilege accounts. Editors get editor rights. Administrators are few, named and reviewed quarterly. No shared logins, ever.
  • Two-factor authentication on every administrative account, including the host control panel and the domain registrar.
  • Unused plugins and themes removed, not merely deactivated. Deactivated code still sits on disk and can still be reachable.
  • A web application firewall in front of the site, filtering known attack traffic before it reaches your application.
  • File integrity monitoring so an unexpected change to a core file raises an alert rather than being discovered by a customer.
  • Off-server backups held somewhere an attacker who owns the server cannot reach, with a stated retention period.
  • A tested restore, performed at least once, with the date recorded and the elapsed time known.
  • A named owner for the site, internal or external, who is accountable for all of the above.

Latency and where to host for a Caribbean audience

Physical distance costs time. For a Jamaican audience, hosting in a North American region such as the eastern United States or central Canada generally performs well, and is where most of the reliable capacity actually sits. Hosting in Europe or Asia adds round-trip latency that is noticeable on a page with many requests, and it is entirely avoidable.

For most sites the bigger win is not server location but a content delivery network with regional edge presence, edge caching, compressed images and a page that does not make forty requests before it renders. A well-tuned site in a North American region will beat a badly built site hosted next door. Test on a mobile connection on a local network, not on office fibre, because that is what your customers use.

One caveat that is not about speed: if you handle personal data, where the data physically sits is a compliance question as well as a performance question. Confirm the region, get it in writing, and treat it as part of your data protection obligations rather than a technical footnote.

What uptime figures actually mean

Uptime percentages are easy to quote and easy to misread. Translated into time, 99 per cent allows roughly seven hours of downtime a month. 99.9 per cent allows about forty-three minutes. 99.99 per cent allows about four minutes. The gap between the first two is the difference between a bad day and a non-event.

Read what is actually promised. Most agreements exclude planned maintenance, exclude anything caused by your own application, and measure availability as whether the server responded rather than whether your site worked. A server returning an error page in under a second is technically up. Ask how availability is measured, what the remedy is when it is missed, and whether anyone tells you about an outage or you are expected to notice first.

Comparing the four realistic options

Option Who it suits What is included What you still have to do
Shared hosting Personal sites, a first brochure site with nothing transactional attached Disk space, control panel, basic support, automatic installer, shared resources Everything above the control panel: updates, security, trustworthy backups, monitoring, recovery
Unmanaged VPS or cloud instance Organisations with a real in-house systems administrator Isolated resources, full root access, network and hardware availability Operating system, stack, patching, hardening, firewall, backups, monitoring, tuning, incident response
Managed cloud hosting Most MSMEs, associations, professional firms and public-sector sites The full stack maintained: patching, hardening, monitoring, backups with tested restores, staging, SSL and DNS, tuning, incident response Content, business decisions, approving change windows, keeping your own user accounts in order
Enterprise managed platform High-traffic transactional platforms, regulated environments, multi-environment development teams All of the above plus contractual availability targets, formal change management, audit support, dedicated escalation Governance, internal approvals, integration ownership, and a budget that reflects it

The questions to ask a host before you sign

  • Where is my data, physically? Which country and which region, and does that change without notice?
  • Who has access to it? Which staff, which subcontractors, and how is that access logged?
  • What is the backup retention, and have you ever restored one? Ask for the date of the last test restore and how long it took.
  • What is your response time to an incident, in hours, outside business hours, and what does “response” mean in practice?
  • Do you patch, or do I? Specifically: operating system, web server, application core, plugins, dependencies. Get it named line by line.
  • Can I get a staging site? If there is nowhere to test, every change is tested on your customers.
  • What happens if I leave? Can you export everything, including the database, the uploads and the configuration, and how long does that take?
  • Who owns the domain and the DNS? If the answer is the vendor, fix that before anything else.

A host that answers all eight clearly and without irritation is usually a good host. Vagueness on any of them is the answer.

Migrating without downtime

Moving a live site is routine work if it is sequenced properly. The order matters more than the tooling.

  1. Inventory everything. Files, database, email, DNS records, certificates, scheduled jobs, integrations, payment gateways and anything pointing at the old server by IP address.
  2. Lower the DNS time-to-live to five minutes at least twenty-four hours before the move, so the cutover propagates quickly.
  3. Build the new environment and restore a full copy onto it, then test the site there using a temporary address or a local hosts entry.
  4. Test properly: forms, logins, checkout, search, email delivery, redirects and anything that touches a third party.
  5. Freeze content changes and take a final synchronisation of the database and uploads so nothing added in the last day is lost.
  6. Cut the DNS over during a low-traffic window, keeping the old server live and serving so any straggling traffic still works.
  7. Issue the certificate on the new host and confirm it is valid and auto-renewing.
  8. Monitor for a week, then take one clean backup of the old environment and decommission it.

Done this way users see no interruption. Painful migrations are rarely caused by technical difficulty; they are caused by changing DNS before the new environment has actually been tested.

A plain checklist for deciding

Answer these honestly. If you answer no to any of the first four, you want managed hosting.

  • Do we employ someone whose job description includes maintaining servers?
  • Will that person still be here, and still have the time, in eighteen months?
  • Does anyone currently know when the site was last patched, or when a backup was last restored?
  • Would a week of downtime, or a defacement discovered by a client, be merely annoying rather than damaging?
  • Does the site take payments, hold member records or hold personal data?
  • Does the site carry revenue, reputation or a regulatory obligation?

What this means for your organisation

Decide who owns the site, then choose hosting that matches that answer. If nobody inside the organisation owns it, buy the ownership as a service rather than pretending the gap does not exist. Write the security baseline above into whatever agreement you sign, ask the eight questions before you commit, and insist on a tested restore rather than a promise of backups.

If you want a view of where your setup stands today, a digital ecosystem assessment will tell you what is hosted where, what is unpatched and what it would take to put right. If the direction is already clear, our managed cloud hosting service and the care and growth plans built around it take the whole list off your team’s desk. The worst position is the common one: a site nobody owns, on a plan nobody chose, waiting for a scanner to find it.

Frequently asked questions

Is managed hosting worth the extra cost for a small business?

Usually yes, because the comparison is not hosting against hosting; it is hosting against staff time. Managed hosting bundles patching, monitoring, hardening, backups with tested restores, staging and incident response. Doing those properly in-house takes a few hours in a quiet month and far more in a bad one. If nobody in your organisation currently owns that work, managed hosting is generally the cheaper and safer option.

What is the difference between shared hosting and managed hosting?

Shared hosting gives you space on a server you share with many other sites, a control panel and reactive ticket support. Managed hosting makes the provider responsible for the whole software stack: provisioning, patching, security hardening, monitoring, backups you can actually restore, a staging environment, SSL and DNS management, performance tuning and incident response. Shared hosting sells you space; managed hosting sells you the maintenance.

Where should a Jamaican business host its website?

For a Jamaican or wider Caribbean audience, a North American region such as the eastern United States or central Canada performs well and is where reliable capacity sits. Add a content delivery network with regional edge presence and sensible caching, which usually matters more than the server's location. If you hold personal data, confirm in writing which country the data sits in, because that is a compliance question as well as a performance one.

Why do so many WordPress sites in the Caribbean get hacked?

Because they are left unmaintained on cheap shared plans. The pattern is consistent: no owner after launch, plugins unpatched for a year or more, abandoned plugins still active, an administrator account with a reused password and no second factor, and no off-server backup to restore from. Attacks are automated and indiscriminate, so being small or local offers no protection at all.

What should I ask a hosting provider before signing?

Ask where the data physically sits, who has access to it, what the backup retention is and when a restore was last tested, what the response time to an incident is outside business hours, exactly which components they patch and which you patch, whether a staging environment is included, whether you can export everything if you leave, and who controls the domain and DNS. Vague answers are themselves an answer.

Can a website be migrated to a new host without downtime?

Yes, if it is sequenced correctly. Inventory everything, lower the DNS time-to-live a day ahead, build and fully test the new environment on a temporary address, freeze content and take a final synchronisation, then cut DNS over during a quiet window while the old server stays live. Painful migrations almost always come from changing DNS before the new environment has been tested.

Talk it through with someone who does this

If this raised a question about your own situation, book a short conversation. The 30 minute introductory conversation carries no charge and no obligation.

Book a meeting Request an assessment

Share this guide
Next step

Ready to move from reading to doing?

Book a consultation or request a Digital Ecosystem Assessment and we will help you decide the right starting point.