Infrastructure engineering vs managed services.

One is a project with a defined end; the other is a continuous operating relationship. Infrastructure engineering is the work of designing an estate and then building it — the target architecture, the servers and environments set up and deployed, the configuration and hardening, the HA/DR that proves it stands up — scoped, delivered and handed over. Managed services is what happens after handover: running that estate day to day — patching, monitoring, a service desk, ticket queues, incident response, uptime commitments. The two are not competitors and not substitutes for each other; almost every estate needs both, in sequence. Infrastructure engineering builds the thing and hands it over documented; an MSP — the client’s own team, or one appointed afterwards — then runs it. Buying ongoing operations when what is actually missing is a build, or buying a build and expecting it to include day-to-day support, is where budgets end up spent on the wrong shape of work. Here is the line, and what sits on each side of it.

What the two are actually buying you

Infrastructure engineering answers a question: what should this estate look like, and can we build and prove it stands up under failure and growth? The output is working systems — servers and environments actually set up, deployed, configured and hardened — plus the documents behind them, delivered against a written statement of work with a defined start and end. Managed services answer a different question: given an estate that is already built, how does it keep running tomorrow, and who is accountable when something breaks at three in the morning? The output is a continuous operating relationship, priced against ongoing coverage rather than a fixed scope. Neither is a smaller or larger version of the other — they are different transactions, bought for different reasons, at different points in an estate’s life.

What infrastructure engineering delivers

An infrastructure engagement at 1722 is scoped from a written statement of work and produces built systems and named artefacts, not a slide deck of opinion:

• Current-state baseline — the systems, dependencies and single points of failure that actually exist, as distinct from what documentation claims exists.
• Target-state architecture and ADRs — a reference design for where the estate is moving, sized against forecast growth, with the reasoning behind every choice recorded so it survives staff turnover.
• Set-up and deployed infrastructure — servers and environments built, configured and hardened against the design. Not a diagram of the work — the work itself.
• HA/DR design and runbooks — RTO and RPO targets, a standby pattern (pilot-light, warm or hot), active-active or active-passive topology where relevant, and recovery procedures tested against those targets.
• Capacity and migration plan — the scaling headroom the design needs, and, where a migration is in scope, the sequenced steps and rollback path to get there.
• Handover pack — documentation and training so the client’s own team, or their MSP, can run the estate independently from day one.

Everything on that list — the built systems and the documents describing them — belongs to the client outright at the end of the engagement, usable with any team, on any timeline, whether or not 1722 is involved again.

What a managed service provider delivers

An MSP’s value is a different kind of reliability: it runs an estate that already exists, day after day. That means patching and OS administration, continuous monitoring and alerting, a ticketing and service desk function, incident response, and — usually the commercial centre of the contract — service-level agreements defining uptime and response times. None of that is engineering work in the sense of designing or building the estate; it operates against a build that is already in place. A capable MSP runs a good build well and can flag operational risk as it appears, but its contract is not written to redesign or rebuild the underlying architecture — that is a separate piece of work, scoped separately, on its own cycle.

Where the line sits, and why it matters

Infrastructure engineering has a defined end: design, build, deploy, prove, hand over. There is no ongoing management contract attached to a 1722 engagement, no service desk and no uptime commitment, because that is deliberately not the work being sold — it is a different job, done by a different kind of relationship afterwards. This is not a limitation to work around; it is what keeps the build accountable to the design rather than to a recurring invoice. An engineer whose fee depends on how much operational coverage gets sold afterwards has a reason to build toward more coverage, not less. 1722 sells no infrastructure product, hardware or licence, takes no vendor or MSP commission, and has nothing to gain from the shape of the operational contract that follows the build. Technology choices are scored against the client’s requirements and total cost of ownership, not against anyone’s margin.

When to buy which — or both

Three situations, and they call for different starting points:

• The estate hasn’t been designed or built yet. If there is no target architecture, no HA/DR posture, or the servers and environments themselves still need setting up, deploying and hardening, an MSP contract cannot supply that — it can only run whatever it is handed. Start with the engineering.
• The build is sound but operations are stretched. If the infrastructure is designed, built and documented, and the gap is day-to-day coverage — patching cadence, alert response, a helpdesk function — that is squarely an MSP conversation, not an engineering one.
• Neither exists yet. Most growing estates need both, in sequence: the design and build first, so the operational contract that follows has an actual system to run against, proven on paper and in practice, rather than inherited from whoever built the estate originally.

Can the same firm do both?

Some integrators sell the build and the ongoing operations as one bundled relationship, and there is an obvious appeal to a single point of contact. The trade-off is independence: a firm that also wants the managed-services contract has a commercial reason to shape the build toward more billable operations, not fewer. 1722’s infrastructure work is engineering with a defined end — the design, the build, the hardening, the handover — and the client’s own team or an MSP of their choosing then keeps the estate running against it. Handover to a new or existing MSP is part of the engagement, not an upsell, and there is no lock-in into an ongoing contract afterwards.

The short version: buy infrastructure engineering to get the estate designed, built and proven. Buy managed services to keep a built estate running day to day. Confusing the two costs a budget cycle; keeping them separate is what makes each one accountable.