Lemington Consulting

Under a break/fix arrangement you call someone when something stops working, and you pay for the time it takes to put it right. Under managed services, a provider takes ongoing responsibility for keeping your systems running - monitoring, patching, backups, security and support - for a predictable recurring fee.

The practical difference is where the incentives sit. Break/fix pays a provider more when things break. Managed services pays the same whether they break or not, so preventing problems is in everybody's interest.

The other difference is visibility. Break/fix is reactive by definition - you find out about a failing disk or an expiring certificate when it causes an outage. Managed services exists largely to find those things first.

Coverage varies between providers, so it is worth reading the agreement rather than the brochure. Most include some combination of:

• Remote monitoring of servers, workstations and network devices
• Operating system and application patching on a defined schedule
• Managed antivirus and endpoint protection
• Backup management and restore testing
• Help desk support for end users
• Vendor coordination - dealing with your line-of-business software suppliers
• Periodic reporting and a technology review

The questions that separate agreements are usually about the edges: what counts as in-scope work versus a chargeable project, whether after-hours support is included, whether on-site visits are covered, and what happens when a problem turns out to belong to a third-party vendor.

[CONFIRM: state what a Lemington agreement includes and, just as usefully, what it does not.]

Most providers price one of three ways: per user, per device, or as a flat monthly fee for an agreed scope.

Per user tends to suit organizations where people work across several devices - a laptop, a phone, a tablet - because you are not paying separately for each one. Per device suits environments with a lot of shared or unattended equipment, such as production floors or point-of-sale terminals. Flat fee works when the environment is stable and well understood.

What matters more than the model is what sits outside it. A low headline rate with a long list of exclusions can cost more over a year than a higher rate that genuinely covers the work. When comparing quotes, compare the exclusions.

[CONFIRM: describe how Lemington prices - model, what drives the number, and whether there is a minimum.]

Co-managed I.T. means an outside provider works alongside your existing team rather than replacing it. It is the arrangement that fits most organizations that already have someone internal.

The usual split: your internal person knows the business, the applications and the people, and handles day-to-day requests. The provider brings the specialist depth and the after-hours coverage - security, infrastructure, migrations, and being available when your one internal person is on holiday.

It also addresses a risk that is easy to overlook: if all your institutional knowledge lives with one employee, you have a single point of failure that no backup system covers.

Fully outsourcing tends to make sense for smaller organizations with no internal I.T. at all. Co-managed tends to make sense once you have someone, because replacing them is rarely the goal - supporting them is.

RMM is the tooling that lets a provider see the state of your systems continuously and act on them without visiting. An agent on each server and workstation reports back on disk space, memory, service failures, patch status, antivirus health, backup results and hardware warnings.

Its value is in what it catches before you notice. A disk filling steadily, a backup job that has been failing quietly for a fortnight, a server rebooting nightly for no obvious reason - all of these are visible in monitoring long before they become an outage.

It is also what makes fixed-fee support workable. A provider can only price predictably if problems are found early, and it is monitoring that makes that possible.

See also: Remote Monitoring and Management.

Data is copied from your servers and workstations, encrypted, and sent to off-site storage on a schedule. "Managed" is the important word: somebody is checking that the jobs actually ran, investigating the ones that did not, and periodically proving that a restore works.

That last part is where most backup arrangements quietly fail. Backup software reports success far more reliably than it delivers a usable restore, and the gap between the two is generally discovered at the worst possible moment.

A sound arrangement usually keeps more than one copy in more than one place - a local copy for fast restores of individual files, and an off-site or cloud copy for the situation where the building itself is the problem.

See also: Managed Cloud Backup and Disaster Recovery.

Backup is a copy of your data. Disaster recovery is a plan for continuing to operate when something significant fails. Having the first does not give you the second.

A useful test: if your main server failed this afternoon, how long before people could work again? If the answer depends on sourcing hardware, rebuilding an operating system and restoring several hundred gigabytes over an internet connection, you have backups but not a recovery capability.

Disaster recovery planning starts with two numbers. Your recovery point objective is how much data you can afford to lose, measured in time. Your recovery time objective is how long you can afford to be down. Those two numbers determine what the solution has to look like, and most organizations have never written them down.

They also determine cost. Recovering in a day is inexpensive. Recovering in fifteen minutes is not. Deciding which you actually need is the useful conversation.

Patching is scheduled rather than automatic-and-hopeful. Updates are applied on a defined cadence, with a window agreed in advance so reboots do not land in the middle of your working day, and with the ability to hold a specific update back when a vendor ships one that breaks a line-of-business application.

Security in a managed arrangement is layered rather than a single product: endpoint protection, patching discipline, controlled administrative access, email filtering, and backups that are isolated enough to survive an incident that reaches the network.

That last point matters more than it used to. Ransomware routinely targets backup systems specifically, because encrypting the data is only leverage if the restore path is gone too.

See also: I.T. Security, Antivirus and Malware Protection.

The first phase is discovery rather than change: documenting what you have, what it does, who depends on it, and where the undocumented knowledge sits. It is common for this stage alone to surface things nobody knew about - an unmonitored server, an expired warranty, a backup that has not run since a change months earlier.

Monitoring agents are deployed next, which is low-impact and mostly invisible to users. Remediation of whatever discovery turned up follows, prioritized by risk.

The genuinely disruptive part is usually not technical. It is transferring administrative credentials and vendor relationships from an incumbent who may not be enthusiastic about the change. That is worth planning for explicitly rather than assuming goodwill.

[CONFIRM: state Lemington's typical onboarding timeline and what is expected of the client during it.]

Regular support hours are 8:00 AM to 8:00 PM Eastern Time, Monday through Friday.

Outside those hours on weekdays, support is still available. Weekend support is provided in the event of an emergency, and in practice we have done a great deal of weekend work over the years - when a production system is down on a Saturday, that is not something that waits until Monday morning.

We deliberately do not describe this as 24/7, because that implies a staffed overnight desk we do not operate. What it is in practice: a long weekday window, availability outside it, and a track record of turning out at weekends when the situation genuinely calls for it.

If continuous round-the-clock coverage is a firm requirement for your environment, that is worth discussing directly rather than assuming a standard arrangement covers it.

A fair question, and one worth asking any provider. The failure mode of fixed-fee managed services is that a quiet month looks identical to a neglected one from the client side.

What answers it is reporting that shows activity rather than just uptime: tickets opened and closed, patches applied and any deliberately held back, backup jobs run and restores tested, security alerts investigated, and anything found that needs a decision from you.

Just as important is a periodic review that looks forward rather than back - equipment approaching end of life, licenses due for renewal, capacity that will become a constraint, and risks that have not been addressed yet. That conversation is where managed services stops being a support contract and starts being useful.

[CONFIRM: describe Lemington's reporting - what is provided and how often - and the review cadence.]

Yes. Database platforms are frequently left out of general managed services agreements, which is how organizations end up with a well-patched network and a SQL Server nobody has looked at in three years.

Database management covers different ground from server management: performance tuning, index and statistics maintenance, backup and restore strategy specific to the database engine, high availability configuration, and capacity planning as data grows.

It is worth checking explicitly whether your provider covers this, because "we manage your servers" and "we manage your databases" are not the same commitment, and the difference usually only surfaces when something is slow or a restore is needed.

See also: SQL Server Frequently Asked Questions and SQL Server Managed Services.