In this article
Your shop opens. Payments are arriving, but two orders have not reached the fulfilment queue. The server dashboard is green. The hosting company says the machine is running; your developer says the database needs checking. Meanwhile, a customer wants their order. This hypothetical incident exposes the question that matters before buying managed hosting: who owns the investigation when the infrastructure is healthy but the business process is not? Start there. Then compare the price. A package name will not answer the customer.
A green server dashboard cannot tell you where the order went
In that hypothetical incident, several different failures could produce the same customer complaint. The application might have failed to create an order after receiving a payment notification. A background worker might have stopped processing a queue. The database might have rejected a write. Each possibility needs different evidence and potentially a different person to fix it. Rebooting the server is not a diagnosis.
Ask the supplier to walk through that incident before you sign. Would support check the application logs, database connections and worker process, or only confirm that the virtual machine responds? Can the team restart a failed service? Can it change application code? Would it contact your developer with findings, or close the ticket once the server passed its checks? Those are concrete boundaries to put in the proposal.
For an online shop, also name the payment gateway, order system and dispatch integration. For an ERP application, name the scheduled imports, document storage and external connections that staff need. Hosting support may cover some of those dependencies and exclude others. Keep an owner and an escalation route for each excluded component.
The useful deliverable is a responsibility map: symptom, first responder, evidence they inspect and next escalation. If a proposal cannot explain who handles the missing-order incident, it is not ready for a meaningful price comparison.
Compare the bill and the work left on your desk
Here is an explicitly hypothetical comparison using invented monthly budget units. These figures demonstrate a calculation; they are not Enigma prices, competitor prices or a client result. Proposal A charges 60 units for the agreed infrastructure and backups. Proposal B charges 110 for those items plus a specified set of routine operational tasks. Both leave application development with your team. First confirm that the underlying capacity, storage and backup arrangements are comparable.
For planning, assume your internal time is worth 20 units per hour. If A leaves four hours of routine work each month and B leaves one, A's planning total is 60 plus 80, or 140. B's is 110 plus 20, or 130. On those assumptions, B's higher supplier invoice buys back enough time to justify the difference. That is a conditional planning comparison, not a promise of cash savings or a measured outcome.
Now change the assumption. If A needs only one internal hour, its total becomes 80 and it is the cheaper arrangement. The extra managed fee is 50 units; at the assumed internal rate, it must remove more than two and a half hours of equivalent work to improve this comparison. Use your own rate and observed workload instead of borrowing the example's numbers.
Write down exactly which tasks are expected to disappear. Patching, checking backups and investigating alerts are different from correcting application bugs. Do not count developer work as outsourced unless the proposal actually includes it. Also price restoration, support outside normal hours, licences, data transfer and migration separately wherever they are excluded. Otherwise, the spreadsheet is comparing two different purchases.
Ask for a restore rehearsal, not a backup badge
A successful backup job shows that a copy was made. It does not establish that the right person can recover a usable application when you need it. Ask for a restore rehearsal in an isolated environment. Agree the scope with the application maintainer first, particularly where the system stores personal information or connects to payment and messaging services.
Use a representative workflow for the check. For a shop, create an appropriate test order and identify where its records and uploaded files live. Restore the relevant database and files, confirm the application can start, and check that the order is available. Keep test connections from sending real customer emails, accepting live payments or writing back into production. A restored database that the application cannot use is an unfinished recovery test.
Then examine the recovery gap. If the chosen backup was taken before a recent order, what happens to information written afterwards? Is it recoverable from another source, or does someone need to reconcile it manually? Ask the question in the context of your actual application. Do not assume a backup schedule delivers a particular recovery outcome without testing the design.
Record who carried out the rehearsal, what was restored, what was checked and what remained unresolved. Retain the evidence privately with the operating documentation. Repeat the check when important dependencies change. This gives the next support conversation something more useful than a row of green ticks.
Five things to get in writing before you buy
First, agree the support window and first response. A response target concerns when somebody replies or starts work; it does not automatically promise when an application will be restored. Ask how an urgent incident is reported, which contact route is monitored and what escalation is available outside the stated support hours.
Second, name the change owners. Who approves an operating-system update, a database change or a production restart? Who checks the application afterwards? Ask what happens if an update creates a compatibility problem and whether rollback work is included. Unclear approval rules can turn a routine change into a surprisingly long meeting.
Third, document access and recovery. Keep authorised access to the domain, DNS, backups and the accounts needed to operate the service. Confirm where backups are held, who can restore them and how recovery decisions are authorised. Avoid an arrangement in which a single unavailable person is the only route to the business's data.
Fourth, agree how the relationship ends. Ask how you obtain your data, files and relevant configuration, what assistance costs and how long the transition can take. Fifth, list application exclusions explicitly. Use the missing-order scenario from the opening paragraph to check that those exclusions have an owner.
Apply all five questions to Enigma Host too. Bring your current stack, the systems connected to it and one incident that would interrupt trading or operations. Ask for a proposal that assigns those responsibilities. If your existing team already covers them reliably, staying with your current arrangement may be the sensible decision.
Further reading
Your next step
Before comparing another hosting plan, write down one business-critical failure and ask each supplier to explain its response. Then align the included work, calculate the time left with your team and arrange a restore rehearsal. Those three checks reveal more than the managed label. For an Enigma Host discussion, send the application stack, current support arrangement and that failure scenario. The next useful step is a scoped proposal you can compare, with clear exclusions and a named owner for the work that remains.