Microsoft-First Managed IT Services

What does 'managed' actually cover compared with break-fix?

The difference is who carries the risk of things going wrong. Under break-fix you pay per incident, which means your provider only earns when something has already failed, and the work that prevents failure (patching, monitoring, backup verification, capacity checks, lifecycle planning) has no natural home.

Under a managed agreement the provider is paid a fixed fee to keep the estate healthy, so unglamorous preventative work becomes their cost of doing business rather than a billable extra. That incentive flip is the substance of the model; the tooling and the service desk follow from it.

What varies between providers is where the boundary falls between included work and project work. Migrations, office moves, new site builds and major upgrades are almost always scoped separately, and any provider claiming otherwise is either pricing that risk into your monthly fee or planning to argue about it later.

What actually happens, and how often?

Most managed IT is sold on adjectives. Proactive, responsive, enterprise-grade. None of those are checkable, so here is the rhythm the service actually runs to, which is.

Patching and firmware are deliberately on different clocks, and it is worth understanding why. Security patches for Windows and third-party software cannot wait for a quarter: Cyber Essentials expects critical and high-severity updates inside fourteen days, and that work runs continuously on the ring model above. Firmware for firewalls, switches and infrastructure is the opposite case, where the update itself carries a real risk of taking something down, so it belongs in a planned window with change control around it.

What does proactive monitoring actually detect?

Proactive monitoring catches the class of problems that degrade before they fail.

None of those are outages yet. All of them become outages if nobody looks.

The value is therefore in what happens to the alert, not in the alert existing. A monitoring platform that emails a shared mailbox nobody reads is theatre. What makes it worth having is a defined owner for each alert type, a triage step that separates noise from signal, and a record of what was done, so that a recurring warning gets fixed at the cause rather than acknowledged every night for six months.

Why do patching rings matter, and what happens without them?

Patching rings exist because the two obvious strategies are both wrong. Patch everything immediately and a bad update takes out the whole estate at once; defer patching until someone has time and you accumulate exactly the exposure that most ransomware relies on.

A ring model splits devices into staged groups (typically a small pilot group of IT and tolerant users, then a broader group, then the rest, then the sensitive machines that need change windows) with a deferral period between each. A problematic update surfaces in the pilot group where the blast radius is small, and everything behind it can be paused.

Two things make or break the model. The first is that rings must be populated by risk profile, not alphabetically: the finance workstation running the practice management client and the theatre PC driving a piece of medical hardware do not belong in the same wave as a general office laptop.

The second is that third-party software needs the same treatment as Windows itself, because browsers, PDF readers, Java runtimes and remote access tools are consistently among the most exploited applications in the estate and are the ones most often left to update themselves, or not.

What should you check before signing any managed IT contract?

Start with the boundary, not the price. Ask precisely what is included and what becomes chargeable project work, because that line is where most disputes live. Then check what 'unlimited support' means in the small print, whether targets are for response or for resolution, what the out-of-hours arrangement genuinely covers versus what triggers an escalation charge, and how many hours of on-site attendance are included if any. A rate card for out-of-scope work should be in the contract from the start rather than produced after you need it.

Then check ownership and exit, which buyers routinely miss. You should own your Microsoft tenant and your domain registration, hold your own break-glass Global Administrator credentials that the provider does not control, and have licences purchased in your name where the agreement allows it.

Ask what happens to documentation, passwords, monitoring agents and configuration at the end of the term, whether offboarding assistance is included or billed, and what security accreditations the provider itself holds. A supplier with administrative control of your identity platform is part of your attack surface, and should be assessed as one.

Co-managed or fully outsourced: which model fits?

Fully outsourced fits when there is no internal IT function, or when the one person you have is spending their week on password resets instead of the work you actually hired them for.

Co-managed fits when you already have internal capability worth keeping and want to extend it rather than replace it: the internal team keeps the business-context work, the applications nobody else understands and the relationships with the rest of the organisation, while the provider supplies the things that are uneconomic to build in-house: out-of-hours cover, enterprise-grade tooling, specialist depth in areas you touch once a year, and holiday and sickness resilience.

Co-managed only works if the split is written down. The common failure is an ambiguous boundary where both parties assume the other is watching backups, patching the servers or reviewing the alert queue, and the answer turns out to be nobody.

Agree which systems belong to which party, who holds which administrative roles, who is first responder for each alert type, where tickets are raised and how they are escalated between teams. Done properly it is the strongest model available to a mid-sized organisation; done vaguely it produces two teams and one gap.

Does it matter whether the service desk is UK-based?

For some organisations it is a preference; for others it is a contractual requirement. If you work in healthcare, in central or local government, in defence or in a regulated supply chain, your own obligations may specify where data is processed and who can access it, and support staff with administrative access are accessing data.

NHS Data Security and Protection Toolkit commitments, public-sector procurement conditions and client security questionnaires all routinely ask where support is delivered from. If you cannot answer, you may not be able to bid.

Beyond compliance, the practical arguments are working hours and shared context. A desk in your own time zone means the person who took the call at nine can still be handling it at four, rather than a handover across shifts on a problem that needed continuity.

What matters most, though, is not geography but whether the same engineers see the same estate often enough to know it: a UK desk with total churn is not better than a well-run offshore one.

Looking for an IT support company near me: does location still matter?

Less than the phrase implies, and not in the way you would expect. Most managed IT work now happens inside your Microsoft tenant rather than in your building, so the engineer fixing a Conditional Access policy or a broken mail flow is doing identical work whether they sit ten miles away or two hundred.

What genuinely changes with distance is the small proportion of work that needs somebody physically present: a failed switch, a network fault nobody can see remotely, an office move.

So the question worth putting to any IT support company is not where its office is, it is what happens when a job needs hands on site, and whether the people answering the phone are the same people who know your estate.

A local address attached to a service desk somewhere else buys you nothing. We are straight about our own geography: our engineers are based in Brough in East Yorkshire, we cover Yorkshire and the Humber on site as a matter of course, and we work with businesses across the rest of the UK remotely.

Where proximity does earn its keep is the first ninety days. Onboarding goes faster when somebody can spend a day walking the estate rather than inferring it from a remote scan, and that is the point at which we would rather be in the room.

What does asset and lifecycle management actually involve?

It starts with an accurate inventory, and most organisations do not have one. A usable asset record covers every device and its owner, purchase and warranty dates, operating system build and support end date, firmware level, encryption status, installed software, and licence entitlements, and it is generated from your management tooling rather than kept in a spreadsheet, because spreadsheets are out of date the day after they are written. Without that record you cannot answer basic questions, such as how many machines will fall out of support before the next Windows end-of-life date.

Lifecycle management is the discipline of acting on the inventory. That means a refresh plan that spreads replacement cost across years instead of concentrating it into one painful capital request; a build standard so new devices arrive configured rather than hand-assembled; and a defined end-of-life route covering secure data destruction, certificates of erasure for anything holding personal data, and WEEE-compliant disposal. Devices out of vendor support are the awkward part, because unsupported hardware and operating systems fail Cyber Essentials and are frequently excluded from cyber insurance.