The 200% Growth Breaking Point
MSP relationships often fail to scale beyond 200% growth without contract restructuring. CIO Magazine research documents the pattern: the contract designed for 50 users doesn’t work at 150 users. The relationship that served a startup fails the growing company.
Growth is success. Growth also breaks things, including MSP relationships that weren’t designed to scale.
The Per-User Model Cliff
Per-user pricing seems scalable. It isn’t, beyond certain thresholds:
| Growth Stage | Per-User Impact | Hidden Scaling Issues |
|---|---|---|
| 1-50 users | Baseline works | None |
| 50-100 users | Linear growth | Support capacity may lag |
| 100-200 users | Strain appears | Infrastructure assumptions break |
| 200+ users | Model may fail | Fundamental restructuring needed |
The per-user model assumes linear scaling. IT infrastructure scales in steps, not lines.
The Infrastructure Step Function
Infrastructure scales in discrete steps, not continuously:
| Infrastructure Element | Scaling Pattern |
|---|---|
| Domain controllers | Steps at ~500 users |
| File servers | Steps at capacity limits |
| Network equipment | Steps at port counts |
| Security tools | Steps at license tiers |
| Backup infrastructure | Steps at data volume |
The MSP contract priced for continuous scaling meets infrastructure reality that demands step investments.
The Support Capacity Lag
MSP support capacity trails client growth:
| Client Growth Rate | Support Capacity Risk |
|---|---|
| Under 10% annually | Generally absorbed |
| 10-25% annually | Requires planning |
| 25-50% annually | Requires proactive scaling |
| Over 50% annually | Crisis likely without preparation |
The MSP that added your account at 50 users may not have capacity for your account at 150 users without explicitly scaling.
The Contract Misalignment
Growth creates contract misalignment:
Scope creep. Needs expand beyond original scope definition.
Pricing mismatch. Volume discounts that made sense at small scale don’t at large scale.
Service level inadequacy. SLAs designed for smaller operation don’t fit larger operation.
Geographic expansion. New locations not covered by original agreement.
Technology evolution. Growth enables technology not contemplated originally.
The contract that worked stops working. Renegotiation becomes necessary.
The Dedicated Resource Threshold
At certain scale, dedicated resources become appropriate:
| Scale | Typical Model | Alternative |
|---|---|---|
| Under 50 users | Shared technician pool | N/A |
| 50-150 users | Named technician, shared pool backup | Consider dedicated |
| 150-300 users | Dedicated technician | Consider on-site |
| 300+ users | On-site presence likely | Internal IT viable |
Transition from shared to dedicated changes relationship economics and service model.
The Growth Planning Gap
Most MSP relationships lack growth planning:
Absent: No discussion of how relationship scales.
Reactive: Scaling addressed when problems emerge.
Annual: Scaling reviewed at contract renewal.
Proactive: Quarterly scaling assessment and planning.
Proactive planning prevents growth from breaking the relationship.
The Geographic Expansion Challenge
Growth often includes geographic expansion:
| Expansion Type | MSP Capability Requirement |
|---|---|
| Same metro area | Existing capability likely |
| Same region | May require extended coverage |
| National expansion | May exceed MSP footprint |
| International | Likely requires MSP change or partnership |
The MSP that served single-location startup may not serve multi-location enterprise.
The Technology Evolution Coincidence
Growth coincides with technology evolution:
Startup stage: Basic infrastructure, simple needs.
Growth stage: Collaboration tools, security requirements, compliance needs.
Scale stage: Enterprise applications, integration complexity, advanced security.
Enterprise stage: Custom solutions, specialized requirements.
The MSP that supported startup technology may lack enterprise technology capability.
The Acquisition Integration Load
Growth through acquisition creates sudden scaling:
Headcount jump. Users added in single event, not gradual growth.
System integration. Merging separate IT environments.
Standardization work. Bringing acquired company to standards.
Support spike. Temporary elevated support needs during integration.
MSP capacity must absorb acquisition integration load on top of normal operations.
The Scaling Conversation
Growth requires proactive scaling conversation:
Quarterly growth review. Where are we? Where are we heading?
Trigger identification. What growth milestones require action?
Capacity assessment. Does MSP have capacity for projected growth?
Investment planning. What infrastructure investments does growth require?
Contract alignment. Does current contract fit projected scale?
The conversation should happen before growth creates crisis.
The Internal IT Transition Point
At sufficient scale, internal IT may become viable:
| Factor | Favors MSP | Favors Internal |
|---|---|---|
| Scale | Smaller | Larger (300+ users) |
| Complexity | Standard needs | Specialized requirements |
| Industry | General | Regulated, specialized |
| Geography | Concentrated | Dispersed |
| Budget | Constrained | Sufficient for team |
Transition isn’t binary. Co-managed models bridge between full MSP and full internal.
The MSP Graduation
Some organizations “graduate” from their MSP:
Positive graduation: Growth enabled new options, successful transition.
Negative graduation: MSP couldn’t scale, forced transition.
Partial graduation: Internal IT for strategy, MSP for operations.
Graduation is natural evolution, not failure. The MSP that helped you grow served its purpose even if you outgrow them.
Building Scalable MSP Relationships
Relationships that scale with growth:
Discuss growth explicitly. Include growth trajectory in initial discussions.
Build flexibility. Contract terms that accommodate growth.
Plan infrastructure. Anticipate infrastructure scaling needs.
Assess MSP capacity. Understand MSP’s ability to scale with you.
Review regularly. Quarterly assessment of alignment.
Prepare transitions. Exit planning even in healthy relationships.
The relationship that serves growth requires deliberate design, not hopeful assumption.
Sources
- Growth scaling thresholds: CIO Magazine enterprise IT research
- MSP scaling patterns: Managed services industry analysis
- Infrastructure scaling steps: IT infrastructure planning research