In-House, MSP or Microsoft Partner: Who Should Run Your Azure?
In-house team, MSP or Microsoft partner? Compare the three ways to run Azure on cost, depth and continuity, and see the hybrid model most mid-sized firms choose.
Techrupt Team7 min read
Most mid-sized organizations end up with a hybrid rather than a single choice. A small internal team owns business context and day-to-day decisions, a Microsoft Solutions Partner designs the platform and leads migrations, and managed services cover monitoring, patching and after-hours response where the internal team is thin. The reason is that the three options do different jobs. In-house brings context, a generalist MSP brings operational coverage and a partner brings architecture depth, and few mid-sized organizations can afford to go without any of the three.
A fully in-house team makes sense once Azure is central to your product and busy enough to keep several specialists occupied all year. A generalist MSP on its own works for small, stable estates and runs out of depth when architecture, security or migration decisions arrive. The choice is less about which model is cheapest and more about which gaps you can afford.
Running Azure in-house
In-house means employees who run Azure as part of their job, usually a cloud or platform engineer inside a broader IT team. It is the right primary model when Azure is core to how you make money. If you ship software on Azure every week, the context your engineers carry about your product, data and customers is worth more than any external specialist’s breadth. Once Azure is central to the product, changes weekly and justifies more than one dedicated specialist, internal context outweighs external breadth and partners shift to occasional reviews.
The cost is harder to see than a salary line. We are not going to quote salary figures here. If you need a benchmark, Canada’s Job Bank wage data publishes ranges by occupation and region, and it is worth checking the BC figures for the roles you have in mind. The cost drivers to plan for are:
- Coverage. One cloud engineer is not a team. Vacation, sick days and after-hours incidents all need a second person or an external backstop.
- Breadth. Azure spans networking, identity, security, containers, data and cost management. Few individuals are strong in all of them.
- Currency. Microsoft’s own guidance on preparing people for the cloud calls for continuous learning time, a sandbox environment and a skills plan. That time comes out of delivery capacity.
- Key-person risk. When the one person who built the environment leaves, the undocumented knowledge leaves with them.
- Hiring time. Recruiting experienced cloud engineers can take months, and the project does not wait.
Whether a hire is cheaper than a partner depends on how steady the work is. A hire is efficient when there is a full year of Azure work and a plan for coverage and training. A partner is usually more efficient for concentrated design or migration work that would leave a new hire underused afterwards. None of this argues against hiring. It argues for hiring deliberately, with a plan for the gaps a small team cannot cover.
Handing it to a generalist MSP
A generalist MSP (managed service provider) runs IT operations across many clients: helpdesk, endpoints, Microsoft 365 administration, patching, backup checks and monitoring. A good one brings process, coverage and predictable cost. Ticket queues, patch cycles, backup verification, user administration and after-hours monitoring are the operational work many organizations should not run themselves. Our earlier post on choosing a managed service provider covers how to evaluate that side of the market.
The limits appear when the work shifts from operating to designing. In the environments we assess after a generalist MSP has run Azure for a few years, the pattern is consistent: tickets get closed, but the platform drifts. Changes are made by hand in the portal rather than through infrastructure as code, network rules accumulate without a design, and technicians hold broad standing access because it is convenient. None of that is negligence. It is what happens when a team optimized for ticket volume is asked to own architecture.
If your MSP runs Azure today, ask three questions. Is the environment defined in code in a repository you own? Who reviewed the network and identity design, and when? Could they walk your auditor through why each privileged role assignment exists? If the answers are weak, bring in architecture help while keeping the MSP for day-to-day operations.
Working with a Microsoft partner
A Microsoft Solutions Partner with Azure designations focuses on design and change: landing zones, network and identity architecture, migrations, modernization and security reviews. It brings architecture depth and delivery pattern recognition. The designations themselves are verifiable: Microsoft awards them against a scored set of certifications, customer growth and deployments, and our buyer’s guide on choosing an Azure partner in Vancouver explains how to check them.
The value shows up in time-bound, high-consequence work. Building a landing zone, planning migration waves, moving legacy applications onto containers or setting up virtual desktops are jobs most organizations do once or twice, and a partner has done them many times. In our own engagements that has meant moving WorkSafeBC’s legacy workloads to Azure Kubernetes Service, and delivering Azure Virtual Desktop and Windows 365 for more than 100 remote staff at Meridian University, alongside a 40% cloud cost saving there.
The weakness of the partner model is continuity. Projects end. If the partner builds the platform and leaves without transferring knowledge, you have replaced one dependency with another.
Side by side
The lines between these models blur in practice. Some MSPs hold Azure designations and some partners, including us, offer managed services. Judge the provider by what its people have delivered, not by the label.
| Factor | In-house team | Generalist MSP | Microsoft Solutions Partner | Hybrid |
|---|---|---|---|---|
| Best at | Business context and continuous change | Routine operations and support coverage | Architecture, migrations and security design | Matching each job to the right owner |
| Azure architecture depth | Depends on who you hire | Usually limited | High, and verifiable through designations | High where it matters |
| Coverage hours | Business hours unless you staff on-call | Often extended or 24x7 by contract | Project hours, plus managed service if offered | Defined by contract across parties |
| Cost shape | Fixed salaries, benefits and training | Predictable monthly fee | Project or hourly fees | Smaller fixed core plus variable expertise |
| Continuity risk | Key-person dependency | Staff rotation across clients | Engagement ends | Lower if documentation is enforced |
| Lock-in risk | Low | Medium if the MSP holds the only access | Medium if code stays with the partner | Low when you own code and access |
| Fits when | Azure is core to the product | The estate is small and stable | You face a major design or migration | You are mid-sized and growing on Azure |
The hybrid model
The hybrid works when each party owns a clear slice of the work and the internal team keeps the decisions.
Your internal team owns business priorities, approval of access and changes, cost accountability, and the relationship with application owners. Even one capable person in this role changes the outcome, because someone inside the organization understands the platform.
The partner owns platform design, the infrastructure as code baseline, migration waves and a periodic architecture review. Microsoft’s guidance on DevOps team topologies describes this as an enabling team, and notes that time-bound engagements prevent dependency and build internal capability.
Managed services own monitoring, patching, backup checks and after-hours response. This can be a separate MSP or the partner itself. One firm doing both simplifies accountability, as long as the contract keeps the two scopes separate so you can change one without losing the other. At Techrupt we structure ongoing support as blocks of hours on either a month-to-month plan, with no commitment and unused hours rolling over, or an annual plan at discounted rates with equal monthly payments and the option to borrow hours from future months. Details are on our managed IT services page.
Keeping ownership whoever runs the platform
Microsoft’s shared responsibility model is clear that your data, accounts and access management remain your responsibility regardless of who operates the platform. Build your contracts around that.
- Code in your repository. Landing zones, policies and pipelines live in your GitHub or Azure DevOps organization from day one.
- Access through your identity platform. External engineers use named accounts in your Microsoft Entra ID with time-bound elevation, and you can revoke them in minutes.
- Pairing on real work. An internal engineer works alongside the partner on each migration wave instead of receiving a handover document at the end.
- Written decisions. Architecture decision records and runbooks explain why the platform looks the way it does.
- An exit clause. Contracts define handover deliverables and notice periods before anyone needs them.
If an internal engineer has worked alongside the partner on each change and everything lives in your repository, you can continue without them. That is what keeps every option open.
How to decide
A few questions usually settle it:
- Is Azure core to how you make money, and busy enough to keep more than one specialist occupied all year? If yes, build in-house and use a partner for periodic reviews.
- Is the estate small and stable, with no major design or migration work ahead? A generalist MSP can carry it, provided the environment is in code you own.
- Is a landing zone, migration or security redesign coming? Bring in a partner for that work, with pairing and handover written into the contract.
- Who covers nights, vacations and the day your one cloud engineer resigns? If nobody, you need managed services alongside whoever else you choose.
Our Azure consulting in Vancouver page explains how we split design work from ongoing operations. If you want a second opinion on where your own lines should fall, book a consultation and we will map which parts of your platform belong in-house and which are better shared.
