What to Expect When You Onboard a Managed IT Provider

Switching IT providers ranks somewhere between “move the office” and “replace the accounting system” on the business disruption scale. You’re handing control of critical infrastructure to people who don’t yet know your environment, your workflows, or which server the CEO considers personally sacred. Done well, the transition takes a few weeks and your staff barely notices. Done poorly, it drags on for months and creates exactly the kind of outages you hired an MSP to prevent.

This post walks through what a managed IT onboarding actually looks like: the timeline, the SLA structure you should expect, how response times work in practice, and what 24/7 monitoring means when it’s more than a line item on a proposal.

The First Two Weeks: Discovery and Documentation

Every competent managed IT provider starts with a discovery phase before they touch anything in production. This is where they inventory your environment: how many endpoints, what servers, which cloud services, what line-of-business applications, how the network is segmented, and where the documentation gaps are.

For a 50-person company, expect this to take one to two weeks. Larger or more complex environments run longer. During discovery, the new provider should be documenting everything they find in a configuration management database (CMDB) or equivalent system. Network diagrams, IP schemes, admin credentials, vendor contacts, licensing details, and backup configurations all get cataloged.

Two things to watch for during this phase. First, your new provider should be asking your outgoing provider (or your internal team) for a formal handoff of credentials, documentation, and active issues. If they skip this step and just start scanning your network, they’ll miss context that takes months to rediscover. Second, they should be identifying risks during discovery, not waiting until onboarding is “complete.” If they find that your backups haven’t been running or your firewall firmware is three years behind, you should hear about it during week one, not quarter two.

SLAs: What the Numbers Should Look Like

Service Level Agreements define the response and resolution commitments your provider makes. Every MSP structures these slightly differently, but the core tiers are consistent across the industry. Here’s what a reasonable SLA framework looks like for an SMB:

• Critical (P1): Complete service outage, security incident, or data loss event. Response within 15 minutes. Work begins immediately and continues until resolved.
• High (P2): Major system degraded but not down. Multiple users affected. Response within 30 minutes. Resolution target within 4 hours.
• Medium (P3): Single user or non-critical system affected. Response within 1 to 2 hours. Resolution within 8 business hours.
• Low (P4): Requests, questions, or planned changes. Response within 4 business hours. Scheduled based on priority.

The numbers above are standard. If an MSP won’t commit to a 15-minute response on critical issues, they either don’t staff for it or they’re being honest that their team can’t sustain it. Either way, that’s a signal.

More important than the targets themselves is how your provider measures and reports on them. Ask for monthly SLA compliance reports that show actual response times versus targets, broken down by priority level. If they can’t produce this data, they aren’t tracking it, and the SLA is just words on a contract. We covered what to ask for in an MSP evaluation in depth, including how to distinguish real SLAs from marketing ones.

What “Response Time” Actually Means

This is where misunderstandings happen. Some providers define “response” as an automated ticket acknowledgment. You submit a request, the system sends a confirmation email, and the clock stops. That’s not a response. That’s a receipt.

A meaningful response means a qualified technician has reviewed the issue, assessed priority, and started working on it or communicated a plan. For critical issues, “started working on it” should be literal: someone is logged into your environment investigating within 15 minutes, not scheduling a call for tomorrow morning.

Ask your provider specifically: when does the response timer stop? If their answer involves the word “acknowledgment,” push for clarity on when a human actually begins work. The distinction between “ticket acknowledged in 3 minutes” and “engineer investigating in 3 minutes” is the difference between a metric that looks good on paper and one that affects how fast your problem gets solved.

Resolution times are equally important and harder to guarantee. Critical issues should have “continuous effort until resolved” commitments rather than fixed resolution windows, because a ransomware incident and a failed switch require very different timelines. For P2 and P3 issues, 4-hour and 8-hour resolution targets are reasonable starting points, with clear escalation procedures when those targets are at risk.

24/7 Monitoring: Separating Real from Decorative

Almost every MSP claims 24/7 monitoring. The actual implementation varies enormously. Here’s how to tell the difference between a provider with genuine around-the-clock coverage and one using it as a checkbox.

Real 24/7 monitoring means staffed analysts reviewing alerts in real time, around the clock, including weekends and holidays. When a critical alert fires at 2 AM on a Saturday, someone sees it within minutes and takes action. That action might be automated remediation for known issues or manual investigation for anomalies, but someone is watching.

Decorative 24/7 monitoring means automated tools generate alerts that queue up until business hours. The monitoring platform runs 24/7, but nobody is watching the alerts outside of Monday through Friday, 8 to 5. A server going offline at 11 PM gets noticed at 8 AM the next day. That’s monitoring software running around the clock, not 24/7 monitoring and response.

The practical test is simple. Ask your provider: if a production server goes offline at 3 AM on Sunday, what happens? Who sees the alert, how quickly do they see it, and what authority do they have to act? If the answer involves “on-call rotation” with pager alerts that wake an engineer up, that’s legitimate but different from a staffed NOC or SOC. Both can work. The important thing is that you know which model you’re buying.

For businesses with compliance requirements under HIPAA, CMMC, or PCI DSS, the distinction matters for auditors too. “We have 24/7 monitoring” needs to be substantiated with evidence of staffing, alerting workflows, and incident response logs. If your provider can’t show those to an auditor, the claim doesn’t hold up.

The 30/60/90-Day Onboarding Timeline

A realistic onboarding timeline for a 50 to 150 person company looks like this:

Days 1 through 14: Discovery and baseline. The provider inventories your environment, documents configurations, deploys their monitoring and management agents, and establishes baselines for normal network behavior. You should have a dedicated onboarding manager coordinating this, not just a technician running scripts.

Days 15 through 30: Stabilization. Monitoring is active and generating alerts. The first few weeks produce a lot of noise as the system learns what’s normal in your environment. Your provider should be tuning alert thresholds, suppressing known false positives, and resolving any urgent issues discovered during assessment. Help desk support is fully operational, and your staff should know how to submit tickets.

Days 31 through 60: Optimization. With a month of data, your provider can identify recurring issues, recommend infrastructure improvements, and start proactive maintenance like patch management, firmware updates, and backup verification. This is also when your vCIO or account manager should present a technology roadmap based on what they’ve learned about your environment.

Days 61 through 90: Steady state. Monitoring is tuned, support processes are established, and your provider knows your environment well enough to handle issues with context. You should be receiving regular reporting on SLA performance, ticket volumes, and security posture. If your provider hasn’t reached steady state by day 90, either the environment is exceptionally complex or the onboarding process has problems.

Red Flags During Onboarding

Some warning signs that your onboarding isn’t going well:

No discovery phase. If a provider deploys agents and declares you “onboarded” without documenting your environment, they’re managing blind. They’ll waste time on every ticket because they don’t have context.

SLAs that start on day one. A provider that guarantees SLA compliance from the first day either has unrealistic expectations or plans to count the discovery period as an exception. SLAs should have a defined ramp-up period, typically 30 days, before full enforcement begins.

No single point of contact. You should have a named onboarding manager who coordinates the transition, tracks open items, and serves as your escalation path. If you’re submitting tickets to a general queue during onboarding, nobody owns the process.

Silence between milestones. Good providers send weekly status updates during onboarding: what was completed, what’s in progress, what needs your input. If you go two weeks without hearing from them, the onboarding has stalled and they haven’t told you.

No security assessment included. Onboarding should include at least a baseline security risk assessment. A provider that inventories your hardware but doesn’t evaluate your firewall rules, MFA coverage, or backup integrity is leaving your biggest risks unexamined.

What to Prepare Before Your Provider Starts

You can shorten the onboarding timeline and reduce friction by having these ready before day one:

• Credential inventory. Admin credentials for all systems, cloud tenants, vendor portals, and network devices. If your departing provider holds some of these, get them transferred before the transition starts.
• Vendor contact list. ISP, phone system provider, line-of-business application vendors, printer service contracts. Your new MSP will need to coordinate with these vendors.
• Active issue list. Any ongoing problems, workarounds, or projects in progress. Context that only exists in your current provider’s heads needs to be documented and transferred.
• User roster. Current employees, their roles, what systems they access, and who your internal IT contacts are. This saves your new provider from asking “who is this person and what do they need access to?” fifty times during the first month.
• Compliance requirements. If you operate under HIPAA, CMMC, PCI DSS, or other frameworks, share your most recent audit results and any open findings. This shapes how your provider configures monitoring and access controls from day one.